Re: [Zope-dev] help me convert from j2ee to zope
On Sat, Jan 24, 2004 at 04:28:24PM +0100, Clemens Robbenhaar wrote:
I am not certain if this is the right mailing list here, because zope-dev is for the development _of_ Zope, not the development of products _with_ Zope.
It's not. The thread has moved to zope@zope.org.
Usually You should have some persistent object around by the Zope framework when handling request. If doing an XML-RPC call You are already talking to some persistent object given to You by the ZPublisher. I am not sure what is the appropriate equivalent of a session bean in J2EE if looking at Zope.
Not knowing much about Zope, I would assume that a session bean is similar to a non-persistent Zope product, while an entity bean is similar to a persistent Zope product.
From what I have read about Zope, J2EE and Zope offer very similar services to developers. Straight from the Oreilly EJB book, EJB offers: concurrency, transactions, persistence, distributed objects (RPC), naming, and role based security. From what I have read Zope offers these same services to products.
At first glance it seems like I should be able to just re-implement my EJBs as Zope products and it would work out quite well. Although the Zope developers have said otherwise so I'm not sure. Also I have noticed other similarities (keep in mind I am a Zope novice, so don't take this as fact): JSP == ZPT Servlets == script (python) objects I can only see 2 BIG differences in Zope and J2EE... 1. Java vs Python (I like Python better) 2. Zope is much nicer and easier to develop in than J2EE. It seems like the Zope designers actually tried to make things easy for developers, where the J2EE designers did not. (Or if they did, failed miserably) My only real reservation is that Zope seems very stuck on making everything a web interface. Personally I don't like web interfaces for most things. I would like to write my programs so that they use the XML-RPC publishing and integrate my client programs with user programs such as eclipse and openoffice.org. For example, one thing I am working on is a requirements management system that stores the data in an application server (hopefully Zope) but the users write their requirements documents in openoffice and openoffice interacts with the app server to store the requirements. I want the main user interface to be openoffice for that, not the web. The web interface would probably just be a read-only view for people who won't download openoffice. Is something like that reasonable in Zope? Because I do think the services mentioned above like transactions and security will be very useful in a product like this.
Another source of inspiration is to install products which seem to do something similar what You want and try to figure out how they did it. (I personally prefer Silva for rather obvious reasons ;)
That's the route I'm going, but it does take time to figure out how other people's code works, especially when I'm still learning the Zope framework. -- Ryan Boder http://www.bitwiser.org/icanoop
On Sat, Jan 24, 2004 at 09:11:29PM -0500, Ryan Boder wrote:
On Sat, Jan 24, 2004 at 04:28:24PM +0100, Clemens Robbenhaar wrote:
Usually You should have some persistent object around by the Zope framework when handling request. If doing an XML-RPC call You are already talking to some persistent object given to You by the ZPublisher. I am not sure what is the appropriate equivalent of a session bean in J2EE if looking at Zope.
Not knowing much about Zope, I would assume that a session bean is similar to a non-persistent Zope product, while an entity bean is similar to a persistent Zope product.
I don't know beans about beans, but from the reading I have done, that sounds reasonable.
From what I have read about Zope, J2EE and Zope offer very similar services to developers. Straight from the Oreilly EJB book, EJB offers: concurrency, transactions, persistence,
yes, yes, and yes
distributed objects (RPC),
yes, in a couple of ways. ZEO allows the same zope app to run on multiple servers from a single persistence storage. Zope also supports XML-RPC.
naming,
i don't know what that means.
and role based security.
yes
From what I have read Zope offers these same services to products.
At first glance it seems like I should be able to just re-implement my EJBs as Zope products and it would work out quite well. Although the Zope developers have said otherwise so I'm not sure.
What did they say? So far you haven't said anything that makes me think Zope is not a good fit. But a quick translation from EJB to Zope may get you something that *works*, but it is likely to be poorly designed from a Zope point of view. Before I got my current job, the team "translated" a bunch of dynamic content and presentation from Weblogic to Zope. It is rather ugly and after 2 years we are still stuck with it due to time constraints. By comparison, another site which they built from scratch in Zope before I was hired, is much nicer to work with. So, you may want to learn a bit about zope and re-think your architecture before you come up with something maintainable.
Also I have noticed other similarities (keep in mind I am a Zope novice, so don't take this as fact): JSP == ZPT
aside from a totally different language design, yes, they serve more or less the same purposes.
Servlets == script (python) objects
hmm, I don't know enough about servlets to judge. Script (python) is poorly named. They're callable objects, kind of like functions, whose code is stored in the zodb and is editable through the web. There are many security restrictions on what Scripts can and cannot do: many modules cannot be imported, you cannot define a persistent class in a Script, etc. Treat them as context-sensitive functions, good for quickly implementing small bits of logic.
I can only see 2 BIG differences in Zope and J2EE...
1. Java vs Python (I like Python better)
yes, you are one of us :-)
My only real reservation is that Zope seems very stuck on making everything a web interface. Personally I don't like web interfaces for most things. I would like to write my programs so that they use the XML-RPC publishing and integrate my client programs with user programs such as eclipse and openoffice.org. For example, one thing I am working on is a requirements management system that stores the data in an application server (hopefully Zope) but the users write their requirements documents in openoffice and openoffice interacts with the app server to store the requirements. I want the main user interface to be openoffice for that, not the web.
You certainly *can* do that, either using XML-RPC or a "REST" style: http://webservices.xml.com/pub/a/ws/2002/02/06/rest.html -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's FLYING COMPLETELY UN-GAY GANGSTER! (random hero from isometric.spaceninja.com)
On Sun, Jan 25, 2004 at 04:07:50PM -0500, Paul Winkler wrote:
naming,
i don't know what that means.
By naming I just mean that both J2EE and Zope offer a mechanism to lookup and access other objects based on a name. In J2EE the JNDI (Java Naming and Directory Interface) is used. In Zope the traverse methods with the path from root are used. -- Ryan Boder http://www.bitwiser.org/icanoop
Having been forced to use EJB's on a project or three ( Weblogic, Websphere, JBoss) and having chosen to use Zope where I have had the choice, let me add my 2c worth. a) Run from EJB's as fast as you can - Zope is the only current alternative with any "out of the box" functionality - actually Zope has far far more than any other alternative. Python is far more expressive/productive than Java ( I make my living programming Java ) and you can leverage both using Jython for rapid prototyping using Java classes from the Jython prompt. If you meet an EJB on the road kill it. b) As far as Session Beans are concerned one difference is that Session Beans carry a transactional context that for the life of the Session Session beans are pooled by the container and can be stateful or stateless. If you use stateful session beans, you have to do lots of low level nonsense to manage paged results of SQL queries in J2EE, ZSQL methods do all this for you rather nicely. On the other hand EJB containers transparently "passivate" quiescent sessions and re-activate them as needed, maintaining session state. This is a second order optimization that may mean nothing in practice. ZODB has transactions and you'll need to manage them in ways analogous to session beans - you'll have to get "inside" Zope (AFAIK) for that - I don't believe the transaction boundaries are that visible at the higher level programming interfaces. ( I may be wrong here and just missing something) c) Session beans have a transaction attribute (declarative) that the container uses to determine what happens when you call a session bean method from another one and one or both are involved in a transaction. Should the call result in a new separate transaction, or should the called method be included in the callers transaction etc.... are determined by these attributes. Zope doesn't have this level of granular control but the reality of J2EE is that the power of this metaphor is rarely used in practice as it is too hard to keep all these transactions consistent in a large app - so mostly default settings or a small subset of the available settings are used > 90% of the time. In Zope the transaction interactions will have to be designed and programmatically managed by you rather than declared and then left to the container. Depending on the complexity of your app's transactions this may be the largest pain point. That's my 2c worth - for my 4c worth send me another email :-) Nitin Borwankar Paul Winkler wrote:
On Sat, Jan 24, 2004 at 09:11:29PM -0500, Ryan Boder wrote:
On Sat, Jan 24, 2004 at 04:28:24PM +0100, Clemens Robbenhaar wrote:
Usually You should have some persistent object around by the Zope framework when handling request. If doing an XML-RPC call You are already talking to some persistent object given to You by the ZPublisher. I am not sure what is the appropriate equivalent of a session bean in J2EE if looking at Zope.
Not knowing much about Zope, I would assume that a session bean is similar to a non-persistent Zope product, while an entity bean is similar to a persistent Zope product.
I don't know beans about beans, but from the reading I have done, that sounds reasonable.
From what I have read about Zope, J2EE and Zope offer very similar services to developers. Straight from the Oreilly EJB book, EJB offers: concurrency, transactions, persistence,
yes, yes, and yes
distributed objects (RPC),
yes, in a couple of ways. ZEO allows the same zope app to run on multiple servers from a single persistence storage. Zope also supports XML-RPC.
naming,
i don't know what that means.
and role based security.
yes
From what I have read Zope offers these same services to products.
At first glance it seems like I should be able to just re-implement my EJBs as Zope products and it would work out quite well. Although the Zope developers have said otherwise so I'm not sure.
What did they say? So far you haven't said anything that makes me think Zope is not a good fit.
But a quick translation from EJB to Zope may get you something that *works*, but it is likely to be poorly designed from a Zope point of view. Before I got my current job, the team "translated" a bunch of dynamic content and presentation from Weblogic to Zope. It is rather ugly and after 2 years we are still stuck with it due to time constraints. By comparison, another site which they built from scratch in Zope before I was hired, is much nicer to work with.
So, you may want to learn a bit about zope and re-think your architecture before you come up with something maintainable.
Also I have noticed other similarities (keep in mind I am a Zope novice, so don't take this as fact): JSP == ZPT
aside from a totally different language design, yes, they serve more or less the same purposes.
Servlets == script (python) objects
hmm, I don't know enough about servlets to judge.
Script (python) is poorly named. They're callable objects, kind of like functions, whose code is stored in the zodb and is editable through the web. There are many security restrictions on what Scripts can and cannot do: many modules cannot be imported, you cannot define a persistent class in a Script, etc.
Treat them as context-sensitive functions, good for quickly implementing small bits of logic.
I can only see 2 BIG differences in Zope and J2EE...
1. Java vs Python (I like Python better)
yes, you are one of us :-)
My only real reservation is that Zope seems very stuck on making everything a web interface. Personally I don't like web interfaces for most things. I would like to write my programs so that they use the XML-RPC publishing and integrate my client programs with user programs such as eclipse and openoffice.org. For example, one thing I am working on is a requirements management system that stores the data in an application server (hopefully Zope) but the users write their requirements documents in openoffice and openoffice interacts with the app server to store the requirements. I want the main user interface to be openoffice for that, not the web.
You certainly *can* do that, either using XML-RPC or a "REST" style: http://webservices.xml.com/pub/a/ws/2002/02/06/rest.html
Ryan Boder wrote:
My only real reservation is that Zope seems very stuck on making everything a web interface. Personally I don't like web interfaces for most things. I would like to write my programs so that they use the XML-RPC publishing and integrate my client programs with user programs such as eclipse and openoffice.org.
Zope talks XML-RPC pretty easily... That said, from your J2EE-based background, have you looked at Twisted at all? cheers, Chris
participants (4)
-
Chris Withers -
Nitin Borwankar -
Paul Winkler -
Ryan Boder