Re: [Zope] Python and EJB (J2EE)
All, I have been tracking this discussion for a while and need to point out some major facts about EJB's that seem to have been missed. Yes, EJB's are componentized and run in a container but that's not all. 1) EJB's are TRANSACTIONAL components (MTS components are also transactional) That is, the code in the EJB usually is part of some transaction. That's what all the excitement around EJB's is about. 2) The TRANSACTIONAL properties of a deployed EJB can be specified at DEPLOYMENT time. Thus the same chunk of code inside an EJB may be used by one customer as a NON-TRANSACTIONAL chunk of code while another uses it in a way that forces a TRANSACTION to begin when the code executes, while still another includes this chunk of code with some others in an all enveloping transaction whose scope is determined by the client program. All this can be specified in a deployment-descriptor - an XML "properties" file. This gives tremendous flexibility and further leverages the componentized code. 3) EJB's can participate in DISTRIBUTED TRANSACTIONS (MTS components can do the same) Thus multiple database servers at different sites on the net can participate in a single transaction. This implicitly involves TWO-PHASE COMMIT and XA/TX interfaces. In plain words, if one database engine in a distributed transaction decides to rollback, all other engines must rollback as well. This requires communication of transaction state out-of-band of the usual transaction state communication and is not done by the programmer, rather has to be supplied by the DB vendor. This requires specific support in the database interfaces and requires a specific entity called a transaction co-ordinator which keeps track of all this. JDBC 2.0 database drivers have support for distributed transactions. Hence EJB's can potentially participate in DISTRIBUTED TRANSACTIONS. 4) ENTITY EJB's allow programmatic access to database rows The ENTITY EJB mirrors (somewhat) a row in a database, with EJB attributes mapping to row columns. Thus accessing/writing data in the database can be done by get/set on the EJB attributes. ENTITY EJB's have far too many wrinkles to be able to talk about them meaningfully here. Suffice it to say that they exist and are useful (to some). EJB's make all this possible because the EJB standard specifies contracts between various players - component creator, container vendor, component user ... and SUN has periodic bake-off's to validate interoperability of components and containers. So component/container paradigm is important, but what makes EJB's fly is the transactional stuff. While Zope has tremendous power as a component container, IMHO the contracts between players are not specified and do not follow any standards. The "Zope product" is perhaps the first implicit "contract" definition. We need more of these for transactional components. However I think before that Zope will need to evolve to include the next level of sophistication in DB transaction management, especially two-phase commit, XA/TX ..., support for existing transaction co-ordinators, and/or provide one. We await that eagerly. Nitin Borwankar, Borwankar Research Inc. [EMAIL PROTECTED] Ender wrote: Hung Jung Lu wrote: From: Ender [EMAIL PROTECTED] ... Thanks for the comments. I'll reply other points in a few more days. cool, i've been waiting for this discussion:) as for distributed technologies, while xml-rpc is useful and simple its not useful (IMO) for enterprise programming, its too basic. This maybe true. However, HTML is also basic and simple, but exactly because of its simplicity, it became widely accepted and used. On the opposite end is CORBA: because it's so complicated, there is no vendor out there that can possibly implement all its features. Trading powerful features for a wider acceptance at times does work. don't forget marketing, behold windows. CORBA is complicated but its also more widely deployed in the enterprise because this problem domain needs the additional feature set. my comments regarding xml-rpc are targeted towards enterprise implementations. if all you need is simple rpc, than xml-rpc will provide 80% functionality of soap at 20% of the complexity (not my numbers) and i recommend to anyone to use xml-rpc. but if you need actual cross-platform object access/transport, than it just won't cut it and then you need the additional functonality of soap. also back to the marketing hype, if something isn't supported than it tends to wither away into a niche. while xml-rpc is used in the trenches for lots of stuff, SOAP is supported by lots of major software developers (ibm and ms come to mind) and it will become the future standard supported by interoable products (in many ways it already has). SOAP is showing symptoms of becoming complicated. And that's a bad sign. See Fredrik Lundh's implementation comment for Python SOAP at
Re: [Zope] Python and EJB (J2EE)
1) EJB's are TRANSACTIONAL components (MTS components are also transactional) Thanks for your comments. Transaction certainly is one of the important features of EJB. But my personal opinion is that instance pooling (multi-threading) is even more important. If you have to implement a components server from scratch, and you can only do so much, which feature would you implement first? Transaction? Or Multithreading? I think the answer is Multithreading. All this can be specified in a deployment-descriptor - an XML "properties" file. Yeap. :) XML "properties" file is the way to go. For many things. Thus multiple database servers at different sites on the net can participate in a single transaction. This implicitly involves TWO-PHASE COMMIT and XA/TX interfaces. In plain words, if one database engine in a distributed transaction decides to rollback, all other engines must rollback as well. Two-phase commit is crucial. That's why I explicity mentioned it in my original message: the final commit must be done in matter of milliseconds, if not microseconds. Let's face it, the commit action takes time. There is never a 100% sure trasaction. NEVER EVER, since the transaction can fail exactly when you are performing the commit action. So the next best thing to do is to commit in two phases: (1)prepare to commit: which can take a few seconds to prepare everything up to the point of hanging all the transaction changes on one single index field (a few bytes), (2) Final commit: modify those few bytes, which on a single machine means of the order of nano-seconds, and on distributed transaction, microseconds to milliseconds. Milliseconds certainly is still not very comforting, but it beats a commit action that takes 30 or 40 seconds that is totally unacceptable in business. Hence EJB's can potentially participate in DISTRIBUTED TRANSACTIONS. Yes, totally agree with you. 4) ENTITY EJB's allow programmatic access to database rows That's the object mapper. I am not sure, though, whether it's the best approach to put the object mapper as part of the Components Server. The fact that even SUN's own people recommend against using entity beans tells me a lot. Object mapper can be used as an independent utility, outside the Components Server. We need more of these for transactional components. However I think before that Zope will need to evolve to include the next level of sophistication in DB transaction management, especially two-phase commit, XA/TX ..., support for existing transaction co-ordinators, and/or provide one. I've mentioned two-phase commit to Digicool people. Not sure whether it's already inside Zope or not, but it seems not. Zope's TM (Transaction Machinery) does not seem to be two-phase. See the TM.py file itself: it only has def _finish(self): self.db.commit() That is, I don't see the equivalent of prepare_to_commit(). If you know where to get more info on XA/TX, could you provide some pointers? thanks, Hung Jung _ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com ___ Zope maillist - [EMAIL PROTECTED] 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 )
Re: [Zope] Python and EJB (J2EE)
If you know where to get more info on XA/TX, could you provide some pointers? Search for XA on Amazon - you can buy a copy of the Spec. It takes a while to ship 2-3 weeks I think. Also look at the specs for the JTA, Java Transaction API. There are some references there. Nitin. thanks, Hung Jung _ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com ___ Zope maillist - [EMAIL PROTECTED] 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 )
Re: [Zope] Python and EJB (J2EE)
I've mentioned two-phase commit to Digicool people. Not sure whether it's already inside Zope or not, but it seems not. Zope's TM (Transaction Machinery) does not seem to be two-phase. See the TM.py file itself: it only has def _finish(self): self.db.commit() That is, I don't see the equivalent of prepare_to_commit(). I'm not sure Zope source is the place to look for this, perhaps ZEO source may be more appropriate. Nitin. If you know where to get more info on XA/TX, could you provide some pointers? thanks, Hung Jung _ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com ___ Zope maillist - [EMAIL PROTECTED] 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 ) ___ Zope maillist - [EMAIL PROTECTED] 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 )
Re: [Zope] Python and EJB (J2EE)
Nitin Borwankar wrote: I've mentioned two-phase commit to Digicool people. Not sure whether it's already inside Zope or not, but it seems not. Zope's TM (Transaction Machinery) does not seem to be two-phase. See the TM.py file itself: it only has def _finish(self): self.db.commit() That is, I don't see the equivalent of prepare_to_commit(). I'm not sure Zope source is the place to look for this, perhaps ZEO source may be more appropriate. Nitin. this has been enlightening, i'm still coming up to speed on all the ejb stuff. zope does implement a two-phase commit and it is integrated with the transaction machinery. to see a good mix in that shows more of the transaction methods take a look at ZPatterns/Transaction.py although its not recommended for use (its deprecated in the current ZPatterns to look at you'll have to check out an older version). you can see how things get called by looking in ZopeHOME/lib/python/ZODB/Transaction.py to see the internals of a transaction mechanics. and you can see how the zodb manages these semantics for objects living in the ZODB here. zHOME/lib/python/ZODB/Connection.py kapil ___ Zope maillist - [EMAIL PROTECTED] 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 )
Re: [Zope] Python and EJB (J2EE)
assuming no errors, in which case you'll get rollback method calls, or subtransactions. a call to tpc_begin signals the begin of the two-phase commit. than comes a call to commit, next tpc_vote, and finally tpc_finish. kapil Ender wrote: Nitin Borwankar wrote: I've mentioned two-phase commit to Digicool people. Not sure whether it's already inside Zope or not, but it seems not. Zope's TM (Transaction Machinery) does not seem to be two-phase. See the TM.py file itself: it only has def _finish(self): self.db.commit() That is, I don't see the equivalent of prepare_to_commit(). I'm not sure Zope source is the place to look for this, perhaps ZEO source may be more appropriate. Nitin. this has been enlightening, i'm still coming up to speed on all the ejb stuff. zope does implement a two-phase commit and it is integrated with the transaction machinery. to see a good mix in that shows more of the transaction methods take a look at ZPatterns/Transaction.py although its not recommended for use (its deprecated in the current ZPatterns to look at you'll have to check out an older version). you can see how things get called by looking in ZopeHOME/lib/python/ZODB/Transaction.py to see the internals of a transaction mechanics. and you can see how the zodb manages these semantics for objects living in the ZODB here. zHOME/lib/python/ZODB/Connection.py kapil ___ Zope maillist - [EMAIL PROTECTED] 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 ) ___ Zope maillist - [EMAIL PROTECTED] 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 )
Re: [Zope] Python and EJB (J2EE)
From: Ender [EMAIL PROTECTED] ... Thanks for the comments. I'll reply other points in a few more days. as for distributed technologies, while xml-rpc is useful and simple its not useful (IMO) for enterprise programming, its too basic. This maybe true. However, HTML is also basic and simple, but exactly because of its simplicity, it became widely accepted and used. On the opposite end is CORBA: because it's so complicated, there is no vendor out there that can possibly implement all its features. Trading powerful features for a wider acceptance at times does work. SOAP is showing symptoms of becoming complicated. And that's a bad sign. See Fredrik Lundh's implementation comment for Python SOAP at http://www.pythonware.com/products/soap/profile.htm Profile Posted Jun 08, 2000 SOAP 1.1 is a highly modular and rather complicated standard. Supporting every little nook and cranny is huge task, and since the specification is still a moving target, we've decided to do this implementation step by step. OK. Even the guru describes SOAP as "rather complicated", what then for the novices? I personally went through the SOAP protocol spec today and I had to agree it's "rather complicated". SOAP is going down the path of CORBA all over again. It's becoming COAP (Complicated Object Access Protocol). If not because Microsoft is behind it, I'd dump SOAP right away. Due to its simplicity, I'd say XML-RPC is here to stay, SOAP or no SOAP. It's unfortunate that the twin brothers have to fare good-bye, but at the same time I am glad that XML-RPC split off to remain simple. Future servers will have to handle both: more work, but that's fate. More on the other points later. regards, Hung Jung _ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com ___ Zope maillist - [EMAIL PROTECTED] 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 )
Re: [Zope] Python and EJB (J2EE)
Hung Jung Lu wrote:
From: Ender [EMAIL PROTECTED]
...
Thanks for the comments. I'll reply other points in a few more days.
cool, i've been waiting for this discussion:)
as for distributed technologies, while xml-rpc is useful and simple its
not useful (IMO) for enterprise programming, its too basic.
This maybe true. However, HTML is also basic and simple, but exactly because
of its simplicity, it became widely accepted and used. On the opposite end
is CORBA: because it's so complicated, there is no vendor out there that can
possibly implement all its features. Trading powerful features for a wider
acceptance at times does work.
don't forget marketing, behold windows.
CORBA is complicated but its also more widely deployed in the enterprise
because this problem domain needs the additional feature set.
my comments regarding xml-rpc are targeted towards enterprise
implementations. if all you need is simple rpc, than xml-rpc will
provide 80% functionality of soap at 20% of the complexity (not my
numbers) and i recommend to anyone to use xml-rpc. but if you need
actual cross-platform object access/transport, than it just won't cut it
and then you need the additional functonality of soap.
also back to the marketing hype, if something isn't supported than it
tends to wither away into a niche. while xml-rpc is used in the trenches
for lots of stuff, SOAP is supported by lots of major software
developers (ibm and ms come to mind) and it will become the future
standard supported by interoable products (in many ways it already has).
SOAP is showing symptoms of becoming complicated. And that's a bad sign. See
Fredrik Lundh's implementation comment for Python SOAP at
http://www.pythonware.com/products/soap/profile.htm
Profile
Posted Jun 08, 2000
SOAP 1.1 is a highly modular and rather complicated standard. Supporting
every little nook and cranny is huge task, and since the specification is
still a moving target, we've decided to do this implementation step by
step.
OK. Even the guru describes SOAP as "rather complicated", what then for the
novices?
implementing a standard and using a standard are different things. do
you need to understand how a db works to query it?
do you really need to understand how xmlrpc works when you do something
like this?
(pseudo-code)
xmlrpcServer('http://yourzopeserver.com')
print xmlrpcServer.objectIds()
i think that as long as the library implementors create a clean
interface to the system than the novice should be able to use the system
without as a blackbox.
I personally went through the SOAP protocol spec today and I had to
agree it's "rather complicated". SOAP is going down the path of CORBA all
over again. It's becoming COAP (Complicated Object Access Protocol). If not
because Microsoft is behind it, I'd dump SOAP right away. Due to its
simplicity, I'd say XML-RPC is here to stay, SOAP or no SOAP. It's
unfortunate that the twin brothers have to fare good-bye, but at the same
time I am glad that XML-RPC split off to remain simple. Future servers will
have to handle both: more work, but that's fate.
i agree with /F description of SOAP, but i have a different guru.
Dave Winer is the/a writer of the specs for of XML-RPC and SOAP. a bit
dated link.
http://davenet.userland.com/1999/09/12/anEndToTheUberoperatingSystem
I agree that there is a place for both protocols, (right tool for the
right job), and that zope should support both. although how is another
can of worms, since i don't think people want the same xml-rpc style
automatic opening of your entire site that currently happens with zope.
incidentally some other useful links
# distributed lightweight protocols
lwprotocols.org
# alternative python soap-rpc lib
http://casbah.org/~kmacleod/orchard/
Cheers
Kapil
___
Zope maillist - [EMAIL PROTECTED]
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 )
[Zope] Python and EJB (J2EE)
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: 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
Re: [Zope] Python and EJB (J2EE)
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 ([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: 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
Re: [Zope] Python and EJB (J2EE)
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 httpsoap), 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 ([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: 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
