> From: James Strachan [mailto:[EMAIL PROTECTED]] > > (*) One thing I've noticed with SOAP is that developers from the different > camps (web/MOM, CORBA/EJB) seem to see SOAP as different things. The > web/MOM > guys tend to think of SOAP as a universal message format so the same > structured message can pass across many transports http/email/news/MOM to > connect anything to anything in a language, platform and transport neutral > way which is kinda cool. CORBA/EJB guys seem to view SOAP as, well its > CORBA > but using XML rather than IIOP and go off building stubs/proxies/IDL > compilers etc just like with EJB/CORBA.
I don't think web/MOM/SOAP and CORBA/EJB are comparable technologies. The former are communication protocols, and the latter are (primarily) programming APIs. To emphasize this point, in the .NET universe, the remote invocation protocols are pluggable... you can write to their distributed object model API and use SOAP, DCE-RPC, IIOP, JRMP, SMTP, or just about anything else you can dream up. For that matter, there is no reason why you couldn't create an EJB container which used HTTP/SOAP as the transport protocol. I would compare EJB to the programming API for your SOAP or MOM implementation. Theoretically EJB (or any distributed object model) provides a high-level abstraction so you don't need to fuss with the complexity of all the protocols and mechanisms underneath. Of course, the tradeoff is flexibility and performance. The problem with EJB, IMHO, is that it has merely replaced the complexity of the underlying system with the even greater complexity of the EJB system, and still significantly inhibits your ability to write well-performing applications. Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
