[Zope] Python and EJB (J2EE)

Fri, 24 Nov 2000 10:55:38 -0800

i've been playing around with servlets (tomcat, jserv, orionserver.com)
and generally been pretty happy with them. development cycle is a lot
slower than zope. i did some prelim work on hooking up jserv to zope but
gave up cause the performance generally sucked (jserv is still using
apj1.1 which doesn't have persistent connections) and figured there were
easier ways to get the two talking besides directly ala distributed
protocols or shared backend resource like a rdbms.

j2ee is more than just ejbs, its a whole slew of technologies like
(jdbc, jndi (directories), jms (messaging), jts (client transactions),
jaxl?(xml)...). one advantage of using java for a project thats going to
be talking several of these protocols is the fact that there is a
standard supported library for it as opposed to python's bazaar style of
development and support (not to mention documentation). integration of
this stuff in python generally requires evalutation on a per
protocol/library basis because in some cases the library just isn't
robust enough to handle the work (python's soap support comes to mind).  

as for component technologies, i really feel this comes out more as a
programming paradigm in python rather than a forced technology. 

as for distributed technologies, while xml-rpc is useful and simple its
not useful (IMO) for enterprise programming, its too basic. it requires
alot of custom app programming to transfer meaningful exceptions. some
protocols/libraries that i would like to see in python would be soap,
wddx (bindings for http&soap), uddi. i've never used com/dcom so i've
nothing to say about them. python does have great corba support
(omniorb, fnorb) and some is working on integrating zope as a corba
system (hopefully they'll write up a howto/ release some code), and pyro
can cut it for simple distributed systems.

so what would you like to see in a python component container?

kapil

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 )