Following up from an earlier post on the different types of ESB I've noticed that lots of the vendors (IBM, Oracle, BEA to name but three) are talking about the way you can plug-and-play the products in their stack thanks to their ESB functionality. This is also the sort of gap that JBI tries to address, in that its not really an ESB that is about end-user services calling each other, its about having end-user services able to call other end-user services residing in different "capabilities". From the SOA Reference model, which defines a service as a way to access capabilities this means that considering a BPEL engine as a service is all well and good, but I'd argue that while from a PRODUCT perspective it provides that service from a development perspective its just a set of capabilities which a service can take advantage of, for instance by using it to execute a BPEL process.
So while its a good thing that vendors are using the power of their bus to enable product replacement and better integration, certainly the goal of JBI, this shouldn't be confused architecturally with the Integration and Business Bus problems talked about earlier. In reality these "capability busses" sit inside an SOA application and provide the glue between different tiers, e.g. Business Service to Process Service, and like all good joins if they are done well you shouldn't care about it.
So now we are up to there different Enterprise Service Bus types, the Integration, Business and now Capability Bus, all with a different architectural purpose even if they can actually be the same product. Its important to keep these things separate because they have different intentions and goals, if you start confusing the metaphors and approaches you are liable to end up with a very confused mess.
No comments:
Post a Comment