Ender pretty much summed everything I could say about J2EE and Zope. but I can tell you why we chose EJB/BEA at our company rather than something like ZOPE/OpenMerchant/PHP/etc. 1. we are consulting firm and we need to be able to leave a client. ZOPE could (at the time, and I believe still can) can get pretty hairy and there just are not that many people who can grok high brow ZOPE. There are plenty JAVA programmers, with years of experience. The J2EE standard is just a set of API's Sun has set up for java programmers to work with. The underlying implementation of the API and brand name is why you chose WBELOGIC over WEBSPHERE, or vice versa. 2. as others said in the previous posts: MessageQueueing, JDBC (this is significant, I still cant get the DCOracle to work), Transactions, Documentation (javadoc of j2ee), Distributed Objects (EJB's - entity beans have their place, but session beans usually most common approach to business logic), Persistence (entity beans are rarely used, ASAIS) and a Security model (pretty complex and confusing -- but acquisition and security can get pretty hairy as well). 3. ZOPE has quite a lot of flexibility, but as far as implementing a exchange or large transaction heavy site, I just wouldnt do it. I am pro-ZOPE all the way, but there has been very little (?) experience with building distributed systems w/ ZOPE and the community experience (I would imagine) leans more to Content heavy - simple transaction based websites. 4. Integration. it would be nice to have ZOPE integrate w/ J2EE (via J2EE connectors?). What I see as ZOPE's huge win is content management. ZOPE is a inclusive system that integrates poorly w/ external systems (IMHO). you must hack up wget w/ custom scripts of rolling back. (you can not push a button and say 'all marketing information is approved' - then it goes to the staging server, then what happens if you have created another version, and have packed the ZODB?) there is no way of reverting back to a historical version if you pack the database. The PTK works fine for ZOPE.ORG, but how many businesses run their shop like zope.org? I havent seen many paradigm except ZOPE.ORG or memepool.com that could work like the PTK is targeting (autonomous people posting content, how do people share documents/content?). 5. Experience. not many people have had much experience (except DC) integrating ZOPE w/ large systems (anyone?). The reason why lots of these questions are coming up is because, a larger group of people are doing more with ZOPE. using it in situations where people have not even thought about putting it. I am fascinated by the system, but once you try to plop things on the filesystem and let ZOPE work in the background (role of CMS, not webserver) things start coming apart at the seams, the idea of versioning and rendering stuff out to the filesystem(how?) and then pushing it around the testing->staging->production environments-- there is no 'best practices' regarding using ZOPE as a seperate external tool (forget this all inclusive stuff - thats why Vignette is getting a bad reputation). most of ZOPEs ideas are interesting. and ZOPE wins in a lot of areas: ease of use, pre-built web interface, zClasses (great idea), ZODB (cool, but gets in the way sometimes, when you just want a filesystem), Security model (already there, on the web interface, a great easy-win), XML-RPC, and 3rd party products (LocalFS comes to mind)! I just would like to know how people used it when its a external tool, and trying to integrate it w/ JSP/ASP/PHP/ETC. ~runyaga
alan runyan wrote:
Ender pretty much summed everything I could say about J2EE and Zope. but I can tell you why we chose EJB/BEA at our company rather than something like ZOPE/OpenMerchant/PHP/etc.
1. we are consulting firm and we need to be able to leave a client. ZOPE could (at the time, and I believe still can) can get pretty hairy and there just are not that many people who can grok high brow ZOPE. There are plenty JAVA programmers, with years of experience. The J2EE standard is just a set of API's Sun has set up for java programmers to work with. The underlying implementation of the API and brand name is why you chose WBELOGIC over WEBSPHERE, or vice versa.
2. as others said in the previous posts: MessageQueueing, JDBC (this is significant, I still cant get the DCOracle to work), Transactions, Documentation (javadoc of j2ee), Distributed Objects (EJB's - entity beans have their place, but session beans usually most common approach to business logic), Persistence (entity beans are rarely used, ASAIS) and a Security model (pretty complex and confusing -- but acquisition and security can get pretty hairy as well).
zope doesn't have a native message queueing system, but if you after something along the lines of MOM or JMS, you could interface to xmlblaster.org (either corba, or xml-rpc). regarding db access, this is one of my sour points with zope right now , (and no i have gotten a working DCOracle yet either), although the python dbi interface does mitigate somewhat programming portability somewhat the implementation of adaptors in zope is limited by zope's rbms access system to enforce penalties on adaptors and libraries which are not fully thread-safe. DCOracle is the only maintained level 3 adaptor for zope right now and its a bitch to compile (why? i've never had any problems compiling perl-oracle, aolserver/tcl->oracle, java->oracle, where i need to track down all the shared libs in use).
3. ZOPE has quite a lot of flexibility, but as far as implementing a exchange or large transaction heavy site, I just wouldnt do it. I am pro-ZOPE all the way, but there has been very little (?) experience with building distributed systems w/ ZOPE and the community experience (I would imagine) leans more to Content heavy - simple transaction based websites.
Transactions - Zope's transaction system is pretty good IMO, and it does support integration of external transaction aware systems. i agree with chalu kim that whats needed are more examples of this type of integration. i'm trying to work on some docs to hopefully flesh some of this out, but i tend to be more productive writing code than docs:). do you have an example of a large transaction heavy site?
4. Integration. it would be nice to have ZOPE integrate w/ J2EE (via J2EE connectors?). What I see as ZOPE's huge win is content management. ZOPE is a inclusive system that integrates poorly w/ external systems (IMHO). you must hack up wget w/ custom scripts of rolling back. (you can not push a button and say 'all marketing information is approved' - then it goes to the staging server, then what happens if you have created another version, and have packed the ZODB?) there is no way of reverting back to a historical version if you pack the database. The PTK works fine for ZOPE.ORG, but how many businesses run their shop like zope.org? I havent seen many paradigm except ZOPE.ORG or memepool.com that could work like the PTK is targeting (autonomous people posting content, how do people share documents/content?).
i disagree pretty strongly on integration, i feel the opposite, in fact, one of zope's strengths is its integration ability. ldap, rdbms, xml-rpc, smtp, pop, imap and whatever else you might care to roll in. i think the issue your tackling here is integration with developer tools, to provide cvs and the standard dev, test, prod environments, and a real ide. zope's support here is sketchy and its very dependent to how you develop a site. there is a separation here of where your code lies and where your data lies. if you have fs code and db data than you can use whatever traditonal tools that you're used to. if you're using ttw development, zcvsmixin might provide some of the support you need (although i don't recall that it did it meanigful diffs since its based on export/import). the mounted db product can provide some support for moving data from dev, test, prod environments. there was also a product (i haven't looked at it) that hooked up two zope servers via xml-rpc that might be useful for migrating content, esp if you can tie togther a seamless export/import system. the whole ide issue is up in the air till (IMO) till ActiveState releases the python-XPCOM bindings and then hopefully some work can get started on getting ZopeStudio back on track.
5. Experience. not many people have had much experience (except DC) integrating ZOPE w/ large systems (anyone?). The reason why lots of these questions are coming up is because, a larger group of people are doing more with ZOPE. using it in situations where people have not even thought about putting it. I am fascinated by the system, but once you try to plop things on the filesystem and let ZOPE work in the background (role of CMS, not webserver) things start coming apart at the seams, the idea of versioning and rendering stuff out to the filesystem(how?) and then pushing it around the testing->staging->production environments-- there is no 'best practices' regarding using ZOPE as a seperate external tool (forget this all inclusive stuff - thats why Vignette is getting a bad reputation).
the number of people with such experience is growing, and it will only grow as zope becomes more widely used (this is also one of the reasons DC and hadzur(?sp) made zope opensource), and as this happens you get more people capable of managing someone else zope's developed site or developing a kickass zope site. btw. there is a good thread on zope-zeo about zope dev with regards to best practices and dev/test/prod environments. vignette- not to mention its also hugely expensive and lots of functionality bound up in expensive add on packages.
most of ZOPEs ideas are interesting. and ZOPE wins in a lot of areas: ease of use, pre-built web interface, zClasses (great idea), ZODB (cool, but gets in the way sometimes, when you just want a filesystem), Security model (already there, on the web interface, a great easy-win), XML-RPC, and 3rd party products (LocalFS comes to mind)! I just would like to know how people used it when its a external tool, and trying to integrate it w/ JSP/ASP/PHP/ETC.
you want examples of front end integration, but than you lose most of the support for your examples of zope's benefits. kapil
alan runyan wrote:
Ender pretty much summed everything I could say about J2EE and Zope. but I can tell you why we chose EJB/BEA at our company rather than something like ZOPE/OpenMerchant/PHP/etc.
1. we are consulting firm and we need to be able to leave a client. ZOPE could (at the time, and I believe still can) can get pretty hairy and there just are not that many people who can grok high brow ZOPE. There are plenty JAVA programmers, with years of experience. The J2EE standard is just a set of API's Sun has set up for java programmers to work with. The underlying implementation of the API and brand name is why you chose WBELOGIC over WEBSPHERE, or vice versa.
Yes, a good counter point. There will be more people grokking (be one with for those not familiar with). Someone needs to plot out how people can grok and what is required. We provide Java consulting for this reason and I agree with your choice of WebLogic. We are looking at Enhydra as an alternative. Hopefully they will get content management framework done.
2. as others said in the previous posts: MessageQueueing, JDBC (this is significant, I still cant get the DCOracle to work), Transactions, Documentation (javadoc of j2ee), Distributed Objects (EJB's - entity beans have their place, but session beans usually most common approach to business logic), Persistence (entity beans are rarely used, ASAIS) and a Security model (pretty complex and confusing -- but acquisition and security can get pretty hairy as well).
DCOracle was the easy part since DC did most of the work. On the other hand, MySQL was not straightforward. DCOracle is not fully implemented OCI-wise last time we used. I am sorry you did not have easy time. We have played with JDBC and it is nice. But it is much quicker in Zope to do things. Zope/Python needs good documentation and lots of it. There is lot more than 6 months ago. You realize Zope is on the move. Just think of all the tree killed to print "Deprecated" of Java document. Java security went through several versions. Security is like a hairly animal. You are never quite happy with it and always find something wrong with it. All that signed vs unsigned and sandboxing, I have not seen their full use until now. Problem of the commonest denominator...
3. ZOPE has quite a lot of flexibility, but as far as implementing a exchange or large transaction heavy site, I just wouldnt do it. I am pro-ZOPE all the way, but there has been very little (?) experience with building distributed systems w/ ZOPE and the community experience (I would imagine) leans more to Content heavy - simple transaction based websites.
Can you share what those distributed systems are?
4. Integration. it would be nice to have ZOPE integrate w/ J2EE (via J2EE connectors?). What I see as ZOPE's huge win is content management. ZOPE is a inclusive system that integrates poorly w/ external systems (IMHO). you must hack up wget w/ custom scripts of rolling back. (you can not push a button and say 'all marketing information is approved' - then it goes to the staging server, then what happens if you have created another version, and have packed the ZODB?) there is no way of reverting back to a historical version if you pack the database. The PTK works fine for ZOPE.ORG, but how many businesses run their shop like zope.org? I havent seen many paradigm except ZOPE.ORG or memepool.com that could work like the PTK is targeting (autonomous people posting content, how do people share documents/content?).
There is CVS integration to create real versioning and there is also dumper to interface with local file system. There are general trends to make these things useful. Let's not confuse Zope as DC. PTK is DC's approximation of content management. There are people who start grokking and make a few good examples of content stream lining. Specialist and workflow generalized on their way... I think we stand a good chance to solve real problems. As example, look at ZPatterns which is a framework born from Java land and moved over to Zope to provide glue layers between applications and domain. Distributed computing might be even better with Python. We just need to do more examples. Have a close look and it is quite practical and good.
5. Experience. not many people have had much experience (except DC) integrating ZOPE w/ large systems (anyone?). The reason why lots of these questions are coming up is because, a larger group of people are doing more with ZOPE. using it in situations where people have not even thought about putting it. I am fascinated by the system, but once you try to plop things on the filesystem and let ZOPE work in the background (role of CMS, not webserver) things start coming apart at the seams, the idea of versioning and rendering stuff out to the filesystem(how?) and then pushing it around the testing->staging->production environments-- there is no 'best practices' regarding using ZOPE as a seperate external tool (forget this all inclusive stuff - thats why Vignette is getting a bad reputation).
We for one are getting to do large systems to gain what it takes and what problems we run into. DC is not the only one in town. They will be more and there are bunch more than four months ago. Look at ZSP section. Staging is always a noble thought but in practice, it rarely gets used. So if you know anybody using the idea to its full potential, I like to know.
most of ZOPEs ideas are interesting. and ZOPE wins in a lot of areas: ease of use, pre-built web interface, zClasses (great idea), ZODB (cool, but gets in the way sometimes, when you just want a filesystem), Security model (already there, on the web interface, a great easy-win), XML-RPC, and 3rd party products (LocalFS comes to mind)! I just would like to know how people used it when its a external tool, and trying to integrate it w/ JSP/ASP/PHP/ETC.
They will come along if not already. We also have a Linux server running all of them (on dual CPUs) putting these things together.
~runyaga
_______________________________________________ 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 )
alan runyan <runyaga@myrealbox.com> said:
[...]. There are plenty JAVA programmers, with years of experience.
... for some value of 'experience'...
[...] (forget this all inclusive stuff - thats why Vignette is getting a bad reputation).
Java, on the other hand, has had five years of the biggest industry investment of "not-all-inclusive", and yet has to come up with a development environment that matches Smalltalk-80 (there's one, but that is not usable in the projects you sketch because it just started supporting J2SE). Zope is already way beyond that and has actually added new concepts. Zope needs a /lot/ of work, especially in the direction of supporting software development inside the system (rather than content and a bit of SSI, where it excels now), but it is much more promising and interesting than this whole Mainframes'r'Us J2EE stuff. -- Cees de Groot http://www.cdegroot.com <cg@cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B
participants (4)
-
alan runyan -
cg＠cdegroot.com -
Chalu Kim -
Ender