On 7/9/07, Rob wrote: > My question was rhetorical (my non-verbal cues obviously not present) > but you raise an interesting point. > > What do you feel is the "right" way for services to interact, if not > via the functions provided by the typical ESB? How does one address > the semantic, syntactic, and other differences that services within > different ownership domains often exhibit? > > -Rob
Mediation is the "right" way to resolve semantic, syntax, protocol, and other differences between service endpoints -- but: 1- an ESB is not necessarily the best solution to perform mediation. For one thing, most ESBs aren't capable of performing security mediation (enabling seamless federation across security domains). For another thing, many ESBs tend to be a bit "heavy" (e.g., deployed in an app server). For a third thing, very few ESBs give you the ability to configure the mediation using declarative policies -- there's always a little programming involved. And fourth, ESBs don't provide as much instrumentation as you'd like for management and root cause analysis, and they're not really good at managing SLAs. As a general rule, I prefer to use WSM or XML gateways over ESBs for mediation and policy enforcement. (See later in this message for a disclaimer regarding ESBs that aren't like "most ESBs".) 2- (and this point goes back to integration vs disintegration) If you are truly refactoring your systems rather than just integrating application silos, then you shouldn't need to do a whole lot of semantic, syntactic, or protocol mediation. You will need to do security mediation and policy enforcement, but you shouldn't need to do a whole bunch of message and protocol transformations. Again -- WSM and XML gateways are better at doing security mediation and policy enforcement than ESBs. and Hitoshi wrote: > > Anne, isn't this more of a problem of how users use the ESB rather than > functionalities provided by ESB? > I do agree that some commercial "ESB" are actually EAI tools but many > OSS ESB aren't. > > H.Ozawa Some ESBs are quite different from other ESBs (Artix and Synapse come to mind), but for most ESBs it's not just how people are using them -- it's part of their basic design to focus more on format and protocol mediation (integration issues) rather than security mediation and policy enforcement (management issues). Given the vastly larger market out there for ESBs than for WSM and XML gateways, my assumption is that people are much more interested in integration capabilities than management capabilities. You may recall my taxonomy for SOA functional infrastructure components: - Service platforms: systems that host service agents and manage the service lifecycle - Mediation systems: systems that mediate interactions - Management systems: systems that administer, monitor, and control services, intermediaries, and other infrastructure components - Registry: provides a system of record for exchange of information among infrastructure components For the most part I categorize an ESB as a "platform" rather than as a "mediation system". From my perspective, if you have to do format and protocol transformations, that should be hidden behind the outward-facing interface. People also often use ESBs to virtualize a service interface, support dynamic routing and binding. What that means is that regardless of where the service agent is deployed, from the consumer's perspective, the ESB projects the service's interface, and therefore, logically, it hosts the service. Granted, ESBs also provide topics and queues, and they manage event sources and sinks, and some might argue that these capabilities fall into the mediation space. But really, we're just talking about different types of message exchange patterns (MEPs), which I categorize as a function of a platform rather than a mediation system. (I recognize that my perspective of mediation doesn't jive with the more popular notion of mediation, but I try to look farther out to where SOA will go, rather than just where we are today --- which is still much more focused on integration than disintegration.) Anne > > Anne Thomas Manes wrote: > > Not as far as I can tell. Which is the primary reasons that I'm not a > > fan of > > positioning an ESB as the crux of a SOA infrastructure. An ESB is a > > useful > > tool for encapsulating legacy functionality and exposing it as a service, > > but it's primary purpose is integration rather than disintegration. An > > ESB > > is rarely used to reduce redundancy of data and functionality. > > > > Anne > > > > On 7/9/07, Rob Eamon <[EMAIL PROTECTED]> wrote: > >> > >> Is there an ESB that isn't about "integration?" > >> > >> -Rob > >> > >> --- In > >> > [email protected]<service-orientated-architecture%40yahoogroups.com>, > > >> > >> "Suhayl > >> Masud" <[EMAIL PROTECTED]> wrote: > >> > > >> > Hi Jeff- > >> > > >> > You are not alone. I agree with you. > >> > > >> > A large number of the "ESB"s out there are all about "integration" > >> > and about "logically centralized" operations. > >> > > >> > I think that we should talk more about distribution. About > >> autonomy. > >> > About peer-to-peer rather than a centralized model. And about > >> > flexibility over efficiency. > >> > > >> > But it is a tough sell :). > >> > > >> > --cheers > >> > Suhayl > >> > >> > >> > > > > > > >
