[Zope] Python and EJB (J2EE)

Fri, 24 Nov 2000 15:52:30 -0500

Good topic. I was hoping someone would come around to this. Perhaps,
there should be a thread of discussion on this.

I dont' know what is there to compare. EJB has been around awhile and
J2EE is yet another jargon to throw people off. Here is what we have
experienced; 1. Anything that needs to be done on J2EE takes twice as
long and of course, costs more. 2. Of "Java" programmers (there are
many, 2M strong as a Java wannabe proclaims), only handful of
programmers can really do anything. 3. Corporations are still very much
enamored with Sun and Java with an idea "Sun is big and we can't go
wrong with it. Zope and Python, I am clueless."  4. My close friend
specifies Java language and he won't have anything to do with Java
application. There is a theory that in Amercia, we make most of our
money with hypes as if it is a bad thing when things work.

Nevertherless, I think there needs to be a study of point-by-point
comparison between EJB and Zope. Don't look at it from Zope/Python POV
but from Java the Hut POV. Python folks don't really know what resuable
codes and libraries they all have and their developments have been
organic. I admit I don't know this for sure. I am being a devil's
advocate. Some hot developers throw some stuff and we marvel at them.

I think for Zope/Python to become enterprise, it needs to have quite a
few things and I like to know if its community is ready for the mundane.

Here are some topics;
1. Message queue
2. implementation of protocols such as SOAP, BXXP
3. better documentations for different levels of readership (decision
maker, developer, systems architect, etc)
4. promotions, workshops and training
5. learning to play golf and smoke cigar...

:-)

Hung Jung Lu wrote:
> 
> 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
> 
> _______________________________________________
> 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 )