A while back I talked about the different ESB models (http://service-architecture.blogspot.com/2007/01/business-service-bus-definition.html) (BSB, ISB, DSB) and of course the fact that Enterprise is a classic IT lie (http://service-architecture.blogspot.com/2006/08/biggest-lie-in-it-enterprise.html)
I agree with Anne that all ESBs aren't the same, but I would say that there isn't (yet) something that is really simple enough to really help the disintegration question at the business level. Steve On 10/07/07, Rob Eamon < [EMAIL PROTECTED]> wrote: > > > > > > > Good points. I hope I didn't come across as defending ESBs. I agree > that they are not sufficient by themselves just as WSM and XML > gateways are not sufficient by themselves. > > Your points about the limitations of "most ESBs" seem like reasonable > evaluation points to consider to be weighed against the positives. > One side trip: programming vs declarative policies arguments always > seem to assume "programming bad, policy definition/configuration > good." This isn't always the case. Defining declarative policies can > be just as complex as programming (one could argue that defining > declarative policies is a form of programming) and can be just as > damaging when errors are made. > > "...then you shouldn't need to do a whole lot of semantic, syntactic, > or protocol mediation." > > I think we agree in principle on this, but we might disagree on how > much of this type of mediation will be needed in practice--now and in > the future. > > -Rob > > --- In [email protected], "Anne Thomas > Manes" <[EMAIL PROTECTED]> wrote: > > > > 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. > >
