All, I have been tracking this discussion for a while and need to point out some major facts about EJB's that seem to have been missed. Yes, EJB's are componentized and run in a container but that's not all. 1) EJB's are TRANSACTIONAL components (MTS components are also transactional) That is, the code in the EJB usually is part of some transaction. That's what all the excitement around EJB's is about. 2) The TRANSACTIONAL properties of a deployed EJB can be specified at DEPLOYMENT time. Thus the same chunk of code inside an EJB may be used by one customer as a NON-TRANSACTIONAL chunk of code while another uses it in a way that forces a TRANSACTION to begin when the code executes, while still another includes this chunk of code with some others in an all enveloping transaction whose scope is determined by the client program. All this can be specified in a deployment-descriptor - an XML "properties" file. This gives tremendous flexibility and further leverages the componentized code. 3) EJB's can participate in DISTRIBUTED TRANSACTIONS (MTS components can do the same) Thus multiple database servers at different sites on the net can participate in a single transaction. This implicitly involves TWO-PHASE COMMIT and XA/TX interfaces. In plain words, if one database engine in a distributed transaction decides to rollback, all other engines must rollback as well. This requires communication of transaction state out-of-band of the usual transaction state communication and is not done by the programmer, rather has to be supplied by the DB vendor. This requires specific support in the database interfaces and requires a specific entity called a transaction co-ordinator which keeps track of all this. JDBC 2.0 database drivers have support for distributed transactions. Hence EJB's can potentially participate in DISTRIBUTED TRANSACTIONS. 4) ENTITY EJB's allow programmatic access to database rows The ENTITY EJB mirrors (somewhat) a row in a database, with EJB attributes mapping to row columns. Thus accessing/writing data in the database can be done by get/set on the EJB attributes. ENTITY EJB's have far too many wrinkles to be able to talk about them meaningfully here. Suffice it to say that they exist and are useful (to some). EJB's make all this possible because the EJB standard specifies contracts between various players - component creator, container vendor, component user ... and SUN has periodic bake-off's to validate interoperability of components and containers. So component/container paradigm is important, but what makes EJB's fly is the transactional stuff. While Zope has tremendous power as a component container, IMHO the contracts between players are not specified and do not follow any standards. The "Zope product" is perhaps the first implicit "contract" definition. We need more of these for transactional components. However I think before that Zope will need to evolve to include the next level of sophistication in DB transaction management, especially two-phase commit, XA/TX ..., support for existing transaction co-ordinators, and/or provide one. We await that eagerly. Nitin Borwankar, Borwankar Research Inc. nitin@borwankar.com Ender wrote:
Hung Jung Lu wrote:
From: Ender <kthangavelu@earthlink.net> ...
Thanks for the comments. I'll reply other points in a few more days.
cool, i've been waiting for this discussion:)
as for distributed technologies, while xml-rpc is useful and simple its not useful (IMO) for enterprise programming, its too basic.
This maybe true. However, HTML is also basic and simple, but exactly because of its simplicity, it became widely accepted and used. On the opposite end is CORBA: because it's so complicated, there is no vendor out there that can possibly implement all its features. Trading powerful features for a wider acceptance at times does work.
don't forget marketing, behold windows.
CORBA is complicated but its also more widely deployed in the enterprise because this problem domain needs the additional feature set.
my comments regarding xml-rpc are targeted towards enterprise implementations. if all you need is simple rpc, than xml-rpc will provide 80% functionality of soap at 20% of the complexity (not my numbers) and i recommend to anyone to use xml-rpc. but if you need actual cross-platform object access/transport, than it just won't cut it and then you need the additional functonality of soap.
also back to the marketing hype, if something isn't supported than it tends to wither away into a niche. while xml-rpc is used in the trenches for lots of stuff, SOAP is supported by lots of major software developers (ibm and ms come to mind) and it will become the future standard supported by interoable products (in many ways it already has).
SOAP is showing symptoms of becoming complicated. And that's a bad sign. See Fredrik Lundh's implementation comment for Python SOAP at http://www.pythonware.com/products/soap/profile.htm
Profile Posted Jun 08, 2000
SOAP 1.1 is a highly modular and rather complicated standard. Supporting every little nook and cranny is huge task, and since the specification is still a moving target, we've decided to do this implementation step by step.
OK. Even the guru describes SOAP as "rather complicated", what then for the novices?
implementing a standard and using a standard are different things. do you need to understand how a db works to query it?
do you really need to understand how xmlrpc works when you do something like this?
(pseudo-code) xmlrpcServer('http://yourzopeserver.com') print xmlrpcServer.objectIds()
i think that as long as the library implementors create a clean interface to the system than the novice should be able to use the system without as a blackbox.
I personally went through the SOAP protocol spec today and I had to agree it's "rather complicated". SOAP is going down the path of CORBA all over again. It's becoming COAP (Complicated Object Access Protocol). If not because Microsoft is behind it, I'd dump SOAP right away. Due to its simplicity, I'd say XML-RPC is here to stay, SOAP or no SOAP. It's unfortunate that the twin brothers have to fare good-bye, but at the same time I am glad that XML-RPC split off to remain simple. Future servers will have to handle both: more work, but that's fate.
i agree with /F description of SOAP, but i have a different guru.
Dave Winer is the/a writer of the specs for of XML-RPC and SOAP. a bit dated link.
http://davenet.userland.com/1999/09/12/anEndToTheUberoperatingSystem
I agree that there is a place for both protocols, (right tool for the right job), and that zope should support both. although how is another can of worms, since i don't think people want the same xml-rpc style automatic opening of your entire site that currently happens with zope.
incidentally some other useful links
# distributed lightweight protocols lwprotocols.org
# alternative python soap-rpc lib http://casbah.org/~kmacleod/orchard/
Cheers
Kapil
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )