I agree with Stefan. It is true that we quite always don't have the luxury of homogeneous sytems but to me, SOA is about making heterogeneous systems communicate in a standard way.
So interoperability is a requirement for a SOA. It means that SOA is intrusive in many aspects, it is required to use a standard protocol and adapt all the applications to that one. Without this standard protocol, I have the impression the architecture looks like EAI back 5 years ago. Every system is using its own protocol/message representation and it's up to an intermediary system to do the mediation (Will this brokering intermediary platform remain manageable over time? And who will pay for its maintenance?) I think a universal API is a good thing if you want to abstract your code from the protocol used. There are already many abstraction layers available, some WS-stacks already have the capacity to be configured to support another protocol. But it does not remove the need to standardise on one protocol in a SOA. A related blog: http://blogs.ittoolbox.com/eai/applications/archives/soa-universal-protocol-or-universal-api-7405 Kind regards. Robin --- In [email protected], Stefan Tilkov <[EMAIL PROTECTED]> wrote: > > On Aug 23, 2006, at 6:51 PM, Anne Thomas Manes wrote: > > > +1. > > But many times you don't have the luxury of homogeneous systems. > > > > Anne > > > Anne, you are right, of course, but I wonder if even then an ESB is > the right concept. > > For example, in a company there may be CICS/COBOL, CORBA/C++, EJB, > and .NET services. In this example, I can either > > (1) select an ESB that supports all of these > (2) for each technology, select some product that service-enables it > > Stefan 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/
