Hey Jeff ----- Original Message ----- From: "Jeff Schnitzer" <[EMAIL PROTECTED]> > 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. Agreed they are quite different. Though they both try to solve similar problems like distributing your business logic, clustering or load balancing. Some are better or worse at these kinds of things. e.g. MOMs are usually much better at fault tolerance & real load balancing than EJBs and Servlet engines are usually more scalable than EJB servers (in my experience at least). > The former are communication protocols, and the latter are (primarily) > programming APIs. They are both technologies that have their own APIs. For example with web technologies we can use the Servlets API or JavaMail or even the URL class. With MOM we can use JMS and with SOAP we can use JAXM or JAX-RPC. So the web/MOM/SOAP technologies have APIs too. > 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. Just like JAX-RPC can have any protocol underneath. I like the looks of JAXM and JAX-RPC, neither are based on RMI or EJB at all but can be used to implement asynchronous SOAP messaging or remote invocation respectively. Its just a shame JAXM doesn't work with JMS yet. So JAX-RPC is probably the closest thing around to the .NET remote invocation protocols. Has nothing at all to do with EJBs though. . > I would compare EJB to the programming API for your SOAP or MOM > implementation. EJB is *totally* different from MOM. Though I agree some SOAP frameworks are EJB-like or EJB-biased. > 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. I'm arguing against 'distributed object models' really. Whether its DCOM, CORBA, EJB or a SOAP framework that tries to implement 'distributed objects'. I think the distributed object paradigm of stubs/skeletons & distributed garbage collection doesn't work that well. I prefer to build distributed systems using more messaging focussed techniques like web technologies, HTTP/email/news/Servlets, SOAP messaging and MOM/JMS. James _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
