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/0dec1f578f18f116802568a... 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