SOA/ESB Level Set
Building on my SOA Elevator Speech, I have created a set of level setting diagrams for discussing the use of an Enterprise Service Bus.
This figure shows the basis of an application developed using SOA principles and an ESB.
Specific services are plugged into the bus, making them available to any application.
The service bus is responsible for routing messages to and from each service, eliminating the problems associated with "point-to-point" programming. Many ESBs are built on top of reliable messaging technologies. Messages are often XML based, but some ESBs allow for multiple protocols and formats.
Applications are composed by developing driver programs that orchestrate the available services. Languages such as BPEL are tailored for writing these "driver" programs.
Any number of "driver" programs can be written to utilize the services on the bus.
|If the application requires a user interface it is generally bolted on to the driver program.|
|Any user interface technology can be used; Rich Interfaces using Swing, Browser Interfaces using JSF and/or AJAX.|
|If the application requires an external interface to the world beyond the service bus, those interfaces are also generally bolted on to the driver program.|
|Although it is certainly possible to expose all of the services to the outside world, that is usually not desirable. Generally only "composite services" that represent a service offered to a business partner will be exposed. Before exposing any service to the outside world, security issues must be addressed.|
|Legacy programs are added to the mix by creating custom â€œservice adaptorsâ€ between the legacy code and the service bus.|
The success of integrating any legacy asset into the mix is related to the difficulty of crafting an adaptor (a.k.a. connector) for that asset. If the adaptor is fairly straight-forward, successful integration is more likely. If the adaptor is convoluted, only minimal success is likely.
Although reuse of legacy assets is touted as a major SOA selling point, in reality many legacy assets will require refactoring to be of much use. The real payoff is adopting a style of programming that will make new services much easier to reuse later.
The services that are plugged into the bus should be loosely coupled. Invoking one service should ideally have no side effect on other services.
Care must be taken if the services directly access a shared database.
If services share records in a common database, they are coupled in a manor that may not be obvious to the author of the driver program.
"Hidden" coupling in an underlying database can be a real problem. When possible, services should be stateless and operate only on the documents that are passed to them.
|To avoid hidden database coupling, some vendors recommend plugging a data service into the service bus.|
|The primary concern with the data access service approach is the performance issue associated with accessing all data through the bus.|
I think that this is a fairly good "level set" to start from before discussing the "real" issues that come up when choosing an ESB or when developing applications on top of one.
Please let me know what else you think I should add...