I disagree a bit on not defining it, we should be able to define what it does and doesn't do. Put it this way, JMS defines what I expect a messaging product to support, add in a page more and its a full spec for a queue based product. I'm not sure why an ESB isn't as simple to define as that. Sure lots of people lob in bits that I don't want, but actually the bit I've wanted for a long long time now (even in the EAI days) is something very very simple. The basic problem I had in the EAI days was as follows
1) MQSeries & TIBCO Rendevous messaging rock, connect anything to anything, configure and you are done 2) Then add in an overly complex product that does 20x more than I want. 3) Watch infrastructure turn into yet another enterprise application 4) relegate to legacy If we can get something simpler at level 2 (MQSeries for SOA as it were) then just because people add in miles more to their product doesn't mean I want to use it. Simple is easy to define, its marketing that makes the products complex. On 28 Mar 2007 09:32:06 -0700, Todd Biske <[EMAIL PROTECTED]> wrote:
The problem I have with all of this is that it just seems like we're putting the cart before the horse. The vendors and some analysts (not all, especially ones who participate on this list) are telling the potential customers, "You need an ESB." What customers should be saying is, "I need these capabilities, and I want this group to be responsible for them." The latter is key, because it helps differentiate between activities that are may still be considered programming efforts, such as orchestration/choreography, from those that are configuration efforts, such as routing. Every organization will have a different set of capabilities that are important, and different operational models. Take that information and now go talk to your vendors to decide whether you need an application server, a message bus, an EAI tool, an ESB, a WSM product, a network appliance, pixie dust, a roving band of trolls, or whatever it takes. Unfortunately, that doesn't bode well for vendor marketing. The definition of what an ESB does will be ever-changing, just as the definition of what an application server does has been ever-changing. It's a fruitless exercise to try to nail it down. -tb On Mar 28, 2007, at 10:55 AM, Steve Jones wrote: 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/> > > >
