[Zope] Python and EJB (J2EE)

[Hung Jung Lu]

Python and EJB (J2EE)
=====================

Searching through comp.lang.python newsgroup archive 
(python-list@python.org) and the zope@zope.org mailing list, I have not been 
able to find much about EJB (Enterprise Java Bean) and Python/Zope 
comparisons. (J2EE is Java Two Enterprise Edition, basically another jargon 
for any architecture based on EJBs.)

I believe this field deserves to be explored a little bit more. If Python is 
going to be more used in the corporate environment, it has to be made 
stronger. This message is kind of unorganized, but I would like to have 
comments/feedback from other people.

The following message shows that I am not the only one interested:

>ruben <ruben@techfactor.com> 11/08/2000 in comp.lang.python:
>
>Coming from a Java background and recently using Python for application 
>development, I have a question. Is there an equivalent to Enterprise 
>JavaBeans in Python?  If so, please point me to some resources!!!

Similarly Joe Grace <occam@serv.net> has posted an explanation on J2EE in 
the Zope mailing list:

http://zope.nipltd.com/public/lists/zope-archive.nsf/0dec1f578f18f116802568ab003585d2/86cffddc1a8a73b980256865006d44a2?OpenDocument

I am starting to look into Java EJB, and I must say that despite all the 
hype, it is totally horrible. I can understand the goals of EJB, but I 
wonder whether something simpler and cleaner might be better. EJBs, 
especially entity beans, have largely failed and have disappointed many Java 
developers, or so it seems from the comments I have received from other 
people.

First off: what is an EJB? There are plenty of books out there, there are 
plenty of websites out there, but you'll probably be hard-pressed to find 
someone that has actually worked with EJBs. I've never liked the names "Java 
Beans" and "Enterprise Java Beans". These are marketing names. We need some 
more generic names. "Java Beans" are an attempt by Sun to implement 
component programmming. That is, the idea is to have component classes on a 
single machine (virtual machine in the case of Java) that can be shared/used 
by different programs. In this sense, "Java Beans" are much like DLLs, Unix 
shared libraries, Python modules, or Microsoft's COM, ActiveX stuff. "Java 
Beans" are designed to be shared within one single machine. "Enterprise Java 
Beans" are much more complex than "Java Beans", and they are aimed at 
distributed computing: EJBs are designed as classes/components to be shared 
by multiple machines. In this sense, they are more like CORBA, or 
Microsoft's DCOM. Therefore:

(1) Java Beans <--- local components, run on the same machine
(2) Enterprise Java Beans <--- distributed components, distributed 
computing, multiple machines, potentially located in different geographic 
locations. These components often have instance pools running in multiple 
threads, and often are transactional.

-------------

What about Python? Or Zope? Simple distributed computing is not too hard to 
implement. CGIs in fact are a way of distributed computing. Python does have 
DCOM (Mark Hammond) and CORBA. But I don't think DCOM/CORBA are the way to 
go. In Python/Zope world, I guess Fredrik Lundh's XML-RPC is the closest 
starting point for distributed computing, and eventually for something 
similar to EJB container. (See http://www.zope.org/Members/Amos/XML-RPC for 
XML-RPC in Zope and http://www.pythonware.com/products/xmlrpc/ for XML-RPC 
in Python.) There is also (See SOAP 
http://static.userland.com/xmlRpcCom/soap/SOAPv11.htm ), which is an 
extended version of XML-RPC.

For more information on XML-RPC, visit http://www.xmlrpc.com/ .

Zope can be used as equivalent to EJB container. But Zope is a general 
webserver with a lot of features that a simple server don't need.

-------------

EJBs are there because of a few good reasons:

(1) Multi-threaded, workload distribution, instance pooling
(2) Security
(3) Transactional
(4) Managed persistence (for "entity beans" in the EJB jargon)

These are all important requirements for the corporate world. Can Python do 
all these things? The answer right now is no. There is nothing really 
equivalent to EJB in the Python world.

-------------

Security: Python is great for rapid development. The 
reflection/introspection power of Python is wonderful. I particularly like 
the absence of the "private" keyword. In C++ and Java, corporate security is 
implemented at the language level, which makes these language quite 
annoying, in my opinion. That being said, corporates DO need security 
mechanisms. If Python were to be used in corporate environment, there MUST 
be a security interface layer. We don't want any employee to be able to peek 
into the president's salary, for instance. That is, absolute data hiding at 
a higher level is necessary. As Java/C++ have shown, data hiding at the 
language level not only is an illusion, but ties up programmers hands too 
much. So, it's best to leave the language itself free, and implement the 
data hiding with a higher-level mecahnism. Distributed computing is good for 
that. For Python, that also means that in remote procedure calls, only data 
should be passed, not objects. We want a better separation of data from 
code. Fredrik Lundh's XML-RPC seems to do well in this separation.

Incidentally, this means that in the corporate world, primitive types 
(numbers and strings, basically) are still going to be primitive types for 
the foreseeable future. Therefore, a language like Ruby that treats 
primitive types like objects actually are in disadvantage, I think.

-------------

Can we develop Python into something equivalent to EJB? I don't know, but 
that'll be so nice. :) Also, I'd like to see it happen without repeating the 
mistakes of CORBA/EJB: they were too ambitious, too complicated. Simple 
things (like the basic HTML) actually can gain much wider acceptance.

-------------

If Python were to become used in the corporate environment, something must 
be done to make it work in distributed computing.

(1) XML-RPC is a good starting point. I think it's very important to keep 
things simple.

(2) Data/Code separation: I think it's important to have something that 
extracts the primitive data members for passing them in the remote call 
argument, like Fredrik Lundh's xmlrpclib module.

(3) Utilities to help mapping objects into database persistence.

(4) Distributed transaction: two-phase commit is crucial. The distributed 
final "commit" action must be achieved in matter of milliseconds or even 
microseconds. There seem to be some standard ways of two-phase commit used 
by databases out there (XA?). So, if we want some distributed computing that 
is fully transactional, the standard two-phase commit scheme must be 
implemented.

-------------

I guess what I am aiming at is an open-source Python Distributed Components 
Server, which would be equivalent to an EJB Container.

I guess anyone with experience in corporte programming environment would 
agree that distributed components is the way to go, and that XML-RPC is the 
way to go. Right now the overhead is heavy (it takes from milliseconds to 
fraction of a second for the XML-RPC overhead), but with some performance 
boosting in the XML part (using C, I guess), it may not be too bad. If the 
overhead is small, people might even use distributed architecture for single 
machine solutions.

Allie Rogers from Triple Point Technology (http://www.tpt.com/) has an 
article in www.xml-rpc.com ( 
http://www.xmlrpc.com/discuss/msgReader$1073?mode=day ) that validate my 
points: xml-rpc can replace and is replacing DCOM, J2EE/EJB and CORBA. But 
it seems that he'd like to move into SOAP instead of the simpler XML-RPC. (I 
can't say much because I don't know anything about SOAP.)

-------------

Anyway, I am rambling. I just think that we as a community ought to push for 
a light-weight open-source Python Distributed Components Server... maybe 
even more than one version of servers, but at least one. This is the key to 
opening the corporate door to Python applications. And forgive me for my 
exaggeration, this might also provide the key to outdate all other languages 
like Java, Perl, etc, and put Python in its deserved place. :)

Any feedback/comment/direction/pointers will be appreciated.

regards,

Hung Jung

_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com