1 Reply Latest reply on Feb 16, 2006 6:50 AM by marklittle

One bus to rule them all?

marklittle Feb 13, 2006 10:14 AM

The concept of a single bus (product) that rules the enterprise is wrong and counter to both Web Services and SOA. In fact this was one of the biggest problems with the old style of EAI, which resulted in a lot of legacy systems as vendors moved from one implementation (product) to another, unable to leverage their current investments. We need to acknowledge that there will be other ESBs with which we will be interacting, potentially at all levels: federating of the ESB infrastructure should be assumed from the start. A single bus does not scale and may become a bottleneck; as in hardware, multiple buses should be defined for different purposes and priorities.

1. Re: One bus to rule them all?

marklittle Feb 16, 2006 6:50 AM (in response to marklittle)

SOA does not imply a specific carrier protocol and neither does it imply RPC semantics; in fact, loose coupling of services forces developers into an asynchronous message passing pattern. Actually true asynchrony is often not necessary: synchronous one-way (void returns) RPCs can be used and often are in Web Services.

Therefore, multiple protocols should be supported simultaneously. In most cases, clients will know the communication protocol to use when interacting with a service; however, in some situations this may not be the case, and the communication stack may need to be assembled dynamically (via a hand-shake protocol, where the client stub may have to be dynamically constructed. Services may be available via multiple different protocols simultaneously, e.g., CORBA IIOP and JMS. A service repository (aka Name Service/Trading Service) will maintain service identities with their endpoint references and contract definitions (CORBA IDL, WSDL, etc.)
Actions