--- In [email protected], "Steve Jones" <[EMAIL PROTECTED]> wrote: > > I'm going with Michael and Jason on this one. An ESB needs to be a > _bus_ not a service development platform. As soon as an ESB > becomes a SDP it ceases to be a bus and becomes just another > application platform that you have to integrate with and which has > application platform release schedules and complexities. > > Keep the bus simple, keep it for mediation and don't put business > logic into the bus.
+1. Keep the roles of the different components well-defined and distinct. With that in mind, it seems perfectly acceptable to use components from the ESB vendor as a service development/hosting platform. As long as that is treated as Steve described, then that approach can be successful. The challenge here is folks tend to lump things under the vendor name. "Oh, that's implemented in webMethods." So even if I implement a service bus using one or two wM components (say, Integration Server and Broker) and implement a set of services in another component (say, Integration Server in a different role, or as models using Designer) they all tend to get lumped in the same bag. That's where confusion sets in. The "bus" role and the "service host" role are separate and distinct. So if one takes the approach of using various components in differing roles from a single vendor, be sure to stress the distinct roles and don't let anyone lump it all under the vendor name. -Rob
