 |
|
Enterprise Integration Patterns Gets 5 Stars
The customer reviews on Amazon give Enterprise Integration Patterns five stars.
Enterprise Integration Patterns is a book I co-authored; check out the reviews for yourself. For a couple of years now, the total has been stuck at 4.0-4.5 stars because of helpful reviews like "A Tactical Book" (which says: it's all about using messaging systems) and "Good for concepts but lacks practical usage" (which says: After reading this book I know concepts but still have to buy real Biztalk book.). I'm also amused by "interesting patterns with a little bit of hype", which warns, "One word of warning, it's a "Martin Fowler Signature Series Book", which means it's more interested in being on the bleeding edge as opposed to being thorough." As Martin once commented to me: I feel sorry for anyone who considers this stuff bleeding edge.
Anyway, those reviews aside, there are now enough 5-star reviews to make the overall average round-up to 5.0. Not bad for a book that was published almost five years ago, an eternity for a computer book.
For some good developerWorks articles on this topic, see:
Technorati Tags: enterprise integration patterns, amazon, enterprise service bus, application integration |
|  Digg it |  Slashdot it |  Post to del.icio.us |
Categories
: [ soaesbws ]
Aug 29 2008, 05:00:00 PM EDT
Permalink
|
|
Intro to Cloud Computing
So what's this cloud computing thing all about? Sounds like SOA and ESBs to me.
David Chappell, frequent industry commentator and author of books like Understanding .NET (not to be confused with David Chappell, Sonic MQ and Oracle guy and author of Enterprise Service Bus, nor with Dave Chappelle, the guy with the self-titled TV show), has a new and rather interesting paper, "A Short Introduction to Cloud Platforms." There's a discussion of it, David Chappell: Introduction To Cloud Computing, on InfoQ.
I personally get cloud computing confused with grid computing. According to Wikipedia (chronicler of wikiality), grid computing (part of the onetime future of computing) is a cluster of resources that act together like one big resource, such that you don't care where in the grid your functionality gets performed. This sounds like, for example, a J2EE application deployed to a WAS ND cluster; the user doesn't know nor care which cluster member is performing his work. Cloud computing, says Wikipedia, occurs on the Internet (or some other type of network, I suppose) such that you don't even know where it's occurring. When you perform a search using Google, Amazon, Travelocity, etc., where is your search executing? Silicon Valley, New York City, or Bangalore--it doesn't matter. In fact, users in NYC are probably hitting different servers than those in Bangalore; those servers are running in a cloud. The data centers in Silicon Valley, New York City, and Bangalore should each be running a grid.
"What cloud computing really means" (InfoWorld) (part of Inside the emerging world of cloud computing) doesn't really answer its own question. Instead, it covers all the bases, saying cloud computing can mean: Software as a service (SaaS), utility computing, Web services in the cloud, platform as a service, managed service providers (MSPs), service commerce platforms, and Internet integration. Gee, clear as mud. (At least they didn't say it's Web 2.0 (which I say is MVC for the Web).)
Likewise, "Guide To Cloud Computing" (Information Week) doesn't really say what it is. But Amazon, Google, Salesforce, etc. are all doing it. An example that a lot of journalists are talking about is Amazon Web Services (AWS), which essentially lets you outsource computing jobs to them. Need some data crunched? Give it to Amazon and they'll get it done. Of course, there's a lot of constraints in how you package up your functionality to be performed, you need to have a lot of flexibility on when it gets done exactly, and you may need to worry about the security (esp. privacy) of your data.
Of course, I should also mention that IBM does cloud computing as well. See:
The Africa press release even has an IBM definition of cloud computing:
Cloud computing enables the delivery of personal and business services from remote, centralized servers (the "cloud") that share computing resources and bandwidth -- to any device, anywhere.
Back to David's paper. He divides an application platform into three parts (see Fig. 2): Foundation, such as the operating system, and I'd include middleware like a J2EE application server; Infrastructure Services, other capabilities and middleware that the app uses for persistence, security, messaging, etc.; and Application Services, which perform business functionality and ideally are wrapped up as SOA business services. The upshot (see Fig. 3) is that cloud computing makes infrastructure and application services available outside the enterprise, in the cloud. Cloud computing also enables the app itself to run in the cloud, so you just deploy your app to the cloud and access it from anywhere (again, like a world-wide WAS ND cluster).
To me, this approach isn't that astonishing; I guess someone just had to give it a name. I (and many others, I think) look at SOA as being an app that works as (what I call) a service coordinator consuming services, namely service providers. The key is that the providers for any given service may be inside the enterprise (what David calls on-premises) or may be outside the enterprise (what David calls the cloud). In fact, a single service may have both internal and external providers, and it seems to me that the cloud should include both, so that the app consuming the service doesn't need to know whether the provider is inside or outside the enterprise (or both). I think an important part of solving this problem, making services available to consumers without having to know where the providers are, is the enterprise service bus. This is one of the main points of my articles "Why do developers need an Enterprise Service Bus?" and "Simplify integration architectures with an Enterprise Service Bus" (the latter with James Snell).
So cloud computing is functionality being performed wherever is convenient, where the client application doesn't know nor care where the functionality actually lives. A great approach to make this happen, and to prepare for more of it in the future than may be practical for you today, is to use SOA and ESBs.
Technorati Tags: cloud computing, grid computing, service-oriented architecture, soa, enterprise service bus |
| Digg it | Slashdot it | Post to del.icio.us |
Categories
: [ soaesbws ]
Aug 22 2008, 04:00:00 PM EDT
Permalink
|
|
Reusable Data Access
Data access in an application is getting a lot more interesting.
In the good old days, you implemented an application, and it accessed its data from a database. At a really high-level, the architecture was simply two layers: The application and the database it used.
Typical application database stack
A more advanced variation was to have multiple applications sharing a single database (the Shared Database pattern).
In this architecture, the application knows what database stores its data, the schema the data is stored in, and is responsible for transforming the data into the format it needs. This creates a lot of work for the application and makes it very dependent on the details of the database. Worse, several applications using the same data may be repeating the same effort, not only writing duplicate code to access the data but also performing the same transformations redundantly.
In modern enterprises, this application-on-a-database approach is becoming increasingly quaint. If every application first has to write a lot of code just to access its data, then applications are much more difficult to write and get working correctly. What is needed is a separation of concerns, where:
- The application is able to assume that the information it needs is easy to access in one consistent format that's exactly what it needs
- An information access layer makes the database look the way the application expects, encapsulating the knowledge needed to access the data and transform it into the desired format
In our really high-level architecture, this separation of concerns creates a third layer between the application and the database, a layer we tend to call information.
Information layer
The information layer doesn't persist the data, the database still does that. The information layer rationalizes whatever is in the database, producing normalized, cleaned-up, customized data for the application.
The information layer encapsulates this data rationalization behavior so that it can be developed and maintained separately from the application. It also makes this rationalization behavior reusable by multiple applications. If your app needs certain data gathered and normalized a certain way, and another application already has that, then your app can reuse that. And if another app has already accessed this data, the data may be cached in the format your app needs so that it can just use it.
Furthermore, no complex enterprise stores its data in just a single database. An enterprise's data is spread across multiple databases, legacy systems, business partners, old archived data, unstructured data (such as much of the Internet), and so on. What may seem like one Customer record may actually come from multiple data sources. Often the same data is stored in multiple places; sometimes the redundant data conflicts with itself. Often data which an application needs to go together as a single record is stored in many different formats, none of which may be the format the application needs.
What this leads to is a three-layer architecture for the enterprise, the same application-information-database layers as before but now for a whole enterprise and not just a single application. The enterprise layers are:
- Applications -- The user applications used to perform various business tasks
- Information -- A cloud of data access that tries to make sense out of the enterprise's collective data
- Data Stores -- All the sources of data that contain the enterprise's collective data
Information integration
With this layer of integrated information, the question changes from how will your application access its data to how will your application use the information layer to access the information it needs and how will the information layer access the data. Data access in an application is getting a lot more interesting.
08/29/2008 update: Here's an article that discusses this idea in a lot of detail as a pattern: "Inside the Preferred Data Source Pattern."
Technorati Tags: information access, data access, data+encapsulation |
| Digg it | Slashdot it | Post to del.icio.us |
Categories
: [ iodiaas ]
Aug 21 2008, 11:00:00 AM EDT
Permalink
|
|
IBM Service Management Jams
IBM is scheduled to run a series of jams on service management.
I've already talked about the IBM Service Management World Tour. We now also have a product page for IBM Service Management Software and Services.
And we will also have the IBM Service Management Jams:
[A] new series of live webcasts customized for IBM Service Management practitioners, Business Partners and the business community. With these weekly webcasts, we’ll provide the very latest in thought leadership, solution deep dives and real-world experiences aimed at those managing IT, service delivery and operational infrastructures of all kinds – across every major industry. These live web events are free to everyone.
A few of the topics you can expect to see in the following weeks include:
- Where to start: the five key entry points for IBM Service Management solutions
- The new security mandate: protecting the "infinite perimeter"
- Customer experience management: the new frontier in intelligent customer care for telecommunications
- Improving the efficiency and flexibility of your disk storage infrastructure
The first one will be August 19 at 12 p.m. EDT. You need to register to attend.
Technorati Tags: it automation, service management, tivoli, ibm |
| Digg it | Slashdot it | Post to del.icio.us |
Categories
: [ wbpmwpswid ]
Aug 13 2008, 11:30:00 AM EDT
Permalink
|
|
Speaking at OOPSLA 2008
I'll be speaking at the OOPSLA 2008 conference.
| OOPSLA 2008 is the 23rd annual international conference on Object-Oriented Programming, Systems, Languages, and Applications, sponsored by the ACM (Association for Computing Machinery). It'll be held October 19-23 in Nashville, Tennessee, USA. OOPSLA is the place where many great techniques have gotten started, such as: Patterns, Aspect Oriented Programming, Extreme Programming XP, Unit testing, UML, Wikis, and Refactoring.
Registration for OOPSLA 2008 is now open.
I will be presenting a tutorial at OOPSLA: "Exploring IBM SOA Technology & Practice." The tutorial will be an update of my book by the same name: Exploring IBM SOA Technology & Practice (which is recommended by, among others, Don Ferguson). |  |
If you need even more reasons to attend, here are some other conference highlights that look promising:
So, lots to do. Please come join in.
Technorati Tags: oopsla, service-oriented architecture, soa, ibm |
| Digg it | Slashdot it | Post to del.icio.us |
Categories
: [ scasdo | soaesbws | wbpmwpswid ]
Aug 11 2008, 02:00:00 PM EDT
Permalink
|
|
IBM Buying ILOG
IBM has announced that it plans to acquire ILOG.
ILOG is a vendor for a leading business rules engine. It should compliment our SOA and ESB products like WPS and WESB very nicely.
More:
|
|
SOA and EDA: When vs. What
Learned a nice simple explanation of the relationship between SOA and EDA.
Actually, Kyle thinks I already came up with this. If I did, I've forgotten, but glad that it's circulated its way back around to me. If not, well, I wish I had.
I was spending some time with some colleagues learning more about WebSphere Business Events. Two interesting issues are how this product fits into the WebSphere Business Process Management portfolio of products, and more generally the relationship between service-oriented architecture (SOA) and event-driven architecture (EDA).
The explanation is this: EDA decides when, SOA decides what. Essentially, when an event handler decides to react to an event, in most all cases it should do so (ideally) but invoking a service (by which I mean a executable unit of an SOA). In this way, the service can be invoked either SOA-style by a service consumer that knows which service it wants to invoke; or EDA-style by an event emitter that has no idea what service to invoke, but the event triggers one or more handlers, each of which makes its own decision about what service to invoke.
So the service is the what: What you do to perform a task that someone's decided needs to be performed right now. EDA is one way to achieve the when: Deciding that now is a good time to perform the service. A traditional SOA service consumer is another way to achieve the when. It's all a matter of whether you want your code to say, "I know what I want to do, and I want to do it now, so I'm going to issue a request to do it now." -- that's a service consumer; or if you want your code in two more decoupled parts that say, "1) I know something happened, but not what to do about it, so I'll just announce it; and 2) I've received an announcement, I want to react to it, and I know what I want to do to react to it, so I'm going to issue a request to do it now." -- that's an event emitter and an event handler, where the handler also acts as a service consumer.
So, EDA and SOA: SOA determines what gets done, EDA is one way to determine when it gets done. Nice simple explanation.
Technorati Tags: service oriented architecture, soa, event driven architecture, eda |
| Digg it | Slashdot it | Post to del.icio.us |
Categories
: [ soaesbws ]
Jul 09 2008, 11:30:00 AM EDT
Permalink
|
|
SOA: Registering Service Consumers
It occurs to me that a service registry can be used not only to keep track of service providers, but of service consumers as well.
I've talked about what a service registry is (and how it's different from a repository) and IBM's main service registry product, WSRR. One need in SOA is: When a service consumer needs to invoke a service, it needs some way to find the endpoints for the providers that implement the service. This is where a service registry comes in. In short, when you deploy a service provider as an endpoint in a production environment, you ought to add the endpoint to the service registry. This way, a service consumer can use the registry to find the endpoint and invoke it. I prefer a deployment model with a single function to add the endpoint into production and register it, and a retirement function that also removes the endpoint from the registry, so that all providers in production are automatically listed in the register.
Another quandary in SOA is: Who's using this service? You've deployed a service, and now you're tired of maintaining it and thinking about getting rid of it (that is, shut down all of the providers in production). If so, what applications will that affect? For all you know, no one's using the service, so shutting it down will be no problem. But you'd like to verify who's using it (if anyone) and consider the impact before shutting it down. Today, the main way to do this is to look at all of your apps in production and go through them to see if they're using the service; not very efficient. Perhaps you can use the ESB; assuming it can identify the consumers invoking a service, it can keep track of that. Still, that only tells you who's used the service lately; an app that hasn't used it in a while may (or may not) still be planning to use it again. Most projects fall back on using human-readable documentation to try to keep track of what apps are using what services, which obviously is rather incomplete and error-prone.
It occurs to me that the register can be used to solve this problem as well. Not only should service providers be registered, service consumers ought to be registered as well. This way, the registry not only contains a list of providers of the service, but also all apps that are consumers of the service. Then when you're considering making changes to the service (such as getting rid of it), you know what apps are using it and can take them into account. Registering and de-registering consumer apps ought to be an automatic part of deploying and removing the app; if the needed (Web) services are represented in the app as J2EE resources references, for example, those resource refs can be registered with the registry.
To paraphrase the saying about orange juice: Service registry: it's not just for providers anymore, it's for consumers too.
Technorati Tags: service oriented architecture, soa, service registry |
| Digg it | Slashdot it | Post to del.icio.us |
Categories
: [ soaesbws ]
Jun 27 2008, 12:00:00 PM EDT
Permalink
|
|
Where the World Became Flat
I'm at the place where the world became flat.
In The World is Flat (a great book, BTW), Thomas Friedman opens by describing a golf game in Bangalore, India.
No one ever gave me directions like this on a golf course before: "Aim at either Microsoft or IBM." I was standing on the first tee at the KGA Golf Club in downtown Bangalore, in southern India, when my playing partner pointed at two shiny glass-and-steel buildings off in the distance, just behind the first green.
He's talking about the KGA Golf Course, which is just outside the hotel room I'm in right now at the Hotel Royal Orchid. To one side of the golf course is the five star hotel, and on the other side is the Embassy Golf Links, a large business park that contains the buildings described in the book. One of them, the EGL D block, is the IBM building described in the book and the one I've been working in this week.
No golf for me this week, but India is quite a trip (in more ways than one). More on that another time.
Technorati Tags: bangalore, india, the world is flat, thomas friedman, ibm |
| Digg it | Slashdot it | Post to del.icio.us |
Categories
: [ non-technical ]
Jun 12 2008, 01:36:35 PM EDT
Permalink
|
|
WebSphere Business Events
IBM has a new product: WebSphere Business Events.
WebSphere Business Events (press release) is a new member of the WebSphere Business Process Management set of products, our SOA and ESB products like WebSphere Process Server. WBE enables an application to detect events and react to them by performing actions. It can wait until multiple events occur before reacting, which it does by performing complex event processing (CEP). The fact that there are events to detect and the ability to react to those events assumes that the application has at least a simple event-driven architecture (EDA). As its name implies, WBE approaches events as being business events, which means that the events are meaningful to the enterprise's business domain, so it performs business event processing (BEP).
The WBE event processing engine runs in WebSphere Application Server (included as part of WBE) and therefore runs on most any platform WAS runs on (but not System z or iSeries). WBE also includes development tools and runtime displays.
There's also an InfoCenter, the WebSphere Business Events Information Center.
Technorati Tags: websphere business events, event-driven architecture, complex event processing, websphere |
| Digg it | Slashdot it | Post to del.icio.us |
Categories
: [ edacep | wbpmwpswid ]
Jun 05 2008, 03:16:06 PM EDT
Permalink
|
|
|
|
Bobby Woolf: WebSphere SOA and J2EE in Practice
