[Zope] j2ee & zope

Chalu Kim chalu@egenius.com
Sat, 25 Nov 2000 15:14:39 -0500


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 )