I think these ESBs, MOMs and other attempts to produce universal integration solutions fail in the same vein as the old universal relation from the early database era. The basis for the platform should be both minimal and flexible.
--- In [email protected], "Logan, Patrick D" <[EMAIL PROTECTED]> wrote: > > From: "David A. Chappell" <[EMAIL PROTECTED]> > > > An ESB is no more lock-in than anything else you could choose to do. > > And that's the crux of the problem from the consumer's perspective. > > > ...in general the idea behind an ESB is that it provides an > > implementation of the most current (and not so current) standard > > interfaces and protocols. > > Given the myriad protocols, they still do not add up to an ESB. > > > It should... allow you to more easily connect, mediate, and control > > the interaction between a diverse set of applications and services > > across an *extended* enterprise. > > I should want to do this without betting the farm on a specific > vendor. > > > All of the touch points that you come in contact with when using an > > ESB should be standards based... The service interfaces should be > > described using WSDL, and available through a UDDI registry. The > > protocols should be based on web services, and other not-so-new > > protocols such as FTP and SMTP. > > Each ESB, from I can tell, is following its own architecture. The > touch points are semi-custom. Nothing appears to have advanced in 5+ > years of enterprise integration in terms of vendor lock-in. WS-splat > and other standards do not add up to an architecture. We can talk SOAP > but what do we talk *about*? I can't have the same conversation with > vendor A's ESB that I have with vendor B's ESB. > > > All of this is held together via a consistent environment where > > managed services enjoy complete location transparency, and invoke > > each other across well defined reliable, secure service invocation > > channels that your security folks have blessed for passing through > > your firewalls. > > I read the brochure. They all read the same. That's not the point. The > promise of all this is avoiding vendor lock-in. We're not there yet by > a long shot. > > > Now you could certainly try to do all of this yourself... pulling > > together a bunch of different implementations of pieces from various > > vendors how does that approach leave you any less locked in? > > Well *that* wouldn't leave me less locked in, would it? But that's not > the point because then I would be the one building the semi-custom ESB > rather than buying your semi-custom ESB. Two sides of the same coin. > > But if there were an architecture rather than a half-completed set of > confusing standards then we wouldn't be having this conversation. I > think JBI is an attempt at this. > > I know next to nothing about JBI, and maybe we could shoot all kinds > of holes in it. But that's the closest thing I can point to, closer > than one-off vendor-specific implementations. > > > A well defined vendor implementation that has documented interfaces > > and behaviors, or a "whatever" infrastructure that's based on a > > hodge-podge of things? > > I understand those are my choices *today*. Are you saying those are my > *ideal* choices as a consumer in the future? > > -Patrick > ------------------------ Yahoo! Groups Sponsor --------------------~--> Most low income households are not online. Help bridge the digital divide today! http://us.click.yahoo.com/cd_AJB/QnQLAA/TtwFAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
