[Zope] Python and EJB (J2EE)

Sun, 26 Nov 2000 12:28:43 -0800

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 )