>>On 28 Mar 2007 09:32:06 -0700, Todd Biske <[EMAIL PROTECTED]> wrote: >I need these capabilities, and I want this group to be responsible for them. +1. Very well said Todd. I would only add that, the key idea about SOA, from my perspective, is that the language of SOA and "Business Services" forms the conceptual framework that allows both IT and the business to express how these capabilities are provided. That is, BusinessServiceA affords these capabilities and the service is owned by this group, whereeas BusinessServiceA affords those capabilities and is owned by that group, etc.
Peter > > > > > > > > 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: > > > > Choreographer > > Mediator > > Rules Engine > > Service Registry > > Mark Richards of IBM has distilled the 10 core capabilities of an ESB as: > > > > Routing > > Message Transformation > > Message Enhancement > > Protocol Transformation > > Service Mapping > > Process Choreography > > Transaction Management > > Service Orchestration > > 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 > > 3150 139th Ave. SE > > Bldg. 3 #4320 > > Bellevue, WA 98005 USA > > We're hiring! Work: 425-679-3533 > > Mobile: 650-533-0691 > > Fax: 425-679-7240 > > Email: [EMAIL PROTECTED] > > Professional Profile > > > > > > > > See who we know in commonWant a signature like this? > > > > > > > > > > > >
