Python and EJB (J2EE)
Searching through comp.lang.python newsgroup archive
([EMAIL PROTECTED]) and the [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> has posted an explanation on J2EE in
the Zope mailing list:
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
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
(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
(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
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
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.
Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
Zope maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -