To me you've just said that ESB = Application Development. JBI does a good job of standardising how products are plugged together from an IT infrastructure perspective, but I wouldn't say its an ESB as its focus is on connecting engines and not on connecting services.
In my view the Bus should be just that, a bus. This means that it should do mediation (including security but excluding protocol) and not contain any business logic, hence the reason that choreography, rules, process and even registry are external elements to the bus. I know that some people are pushing the idea of the ESB as the "next" development platform, and indeed some of these products are good development products, but there is a really big difference between a bus architecture (proper bus, not hub and spoke pretending to be a bus) and an application development stack. The question really is whether the ESB is actually a bus (a connection approach) or an application platform. If its the later then it really isn't a bus its just an App Server with another name. On the IBM list I'd say that 1 (if not CBR), 2 and 9 belong in a bus the others belong in an App Server. On 28/03/07, Bill Barr <[EMAIL PROTECTED]> wrote:
I think that JSR 208 and the JBI specification does a reasonable enough job at providing a standard definition of an ESB. At it's heart, the ESB provides 4, core components: 1. Choreographer 2. Mediator 3. Rules Engine 4. Service Registry Mark Richards of IBM has distilled the 10 core capabilities of an ESB as: 1. Routing 2. Message Transformation 3. Message Enhancement 4. Protocol Transformation 5. Service Mapping 6. Process Choreography 7. Transaction Management 8. Service Orchestration 9. Security EAI is little more than peer-to-peer, real-time, ETL. At a minimum, an ESB removes the peer-to-peer connection thereby simplifying the management of all the connection points. Also, any enterprise is going to need at least 2 buses, maybe more; one for business messages and one for management messages. Those of you who live in older cities where wastewater and sewage share the same system know the downfalls of a uni-bus architecture every time there is a torrential downpour! Anyhow, an ESB-based SOA and a non-ESB-based SOA only differ in their messaging metaphors. Chappel explains this far more eloquently than I can but, with the former, every endpoint sends a message to the bus and with the latter, endpoints send messages to each other. *Bill Barr* Sr. Software Architect *Expedia* <http://www.expedia.com/>3150 139th Ave. SE Bldg. 3 #4320 <http://maps.google.com/maps?q=3150+139th+Ave.+SE%2CBldg.+4+%233093%2CBellevue%2CWA+98005%2CUSA&hl=en>Bellevue, WA 98005 USA We're hiring! <https://www.linkedin.com/e/jsc/Expedia/> *Work:*425-679-3533 *Mobile:* 650-533-0691 *Fax:* 425-679-7240 *Email:* [EMAIL PROTECTED] *Professional Profile <https://www.linkedin.com/e/fps/2997316/>* See who we know in common <https://www.linkedin.com/e/wwk/2997316/> Want a signature like this? <https://www.linkedin.com/e/sig/2997316/>
