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 com
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] zope.org down?
I haven't been able to connect for the last hour or so, either. Nitin ___ 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] Proposal for mail-in to Zope
Along these lines, if we have an "rfc822" object, what operations would we want to perform on it ? What other objects would be useful ? A "folder" object ? A "part" object for handling "multipart" MIME objects Possible actions === * save/fetch a message object to/from "folder" for messages in ZODB * dissemble a multipart MIME message into "part" objects in memory * write a "part" to/from a file * write a "Multipart" object to a "multifile" * "send a message" into the ZODB "folder" from the outside * "send a message" from the ZODB "folder" to the outside * search for message by attributes These operations would be methods on the "rfc822" object, "part" object and ZODB "folder" object, invoked appropriately ( locally or via remote calls ). Nitin Borwankar, [EMAIL PROTECTED] Chris McDonough wrote: I'm interested in this, although I have a lot on my plate right now and can't help in development. I see objects in Zope being able to handle a call to one of their methods that passes off a chunk of email text and stuffs it in an attribute for later display or catalog. I think you should probably start by designing the interface to these kinds of objects and worry about exactly how you're going to call the methods that make up the interface later... -Original Message- From: Simon Coles [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 31, 2000 11:54 AM To: [EMAIL PROTECTED] Subject: [Zope] Proposal for mail-in to Zope Hi, We (NIP - in the form of Chris Withers, Stephen Harrison, and Simon Coles) have put some thought into the question of how to get emails into Zope, and have come up with a design which we thought we'd pass by the list before we start doing something. The problem we are trying to solve is basically being to email "[EMAIL PROTECTED]" and that email ends up in the Zope ZODB processed in whatever way is appropriate. We aren't worried about sending email, that's done well at the moment. We also wanted to keep things as simple and quick as possible :-) This means trying to avoid getting involved with mail systems as much as we can. Most MTAs can be setup to pass an email to the stdin of a program. Sendmail will do this, and Exim (http://www.exim.org/) will also pay attention to what that program returns and queue the message for re-try later if it fails. So using Exim, we don't have to get into any messy stuff about queuing mails if the Zope server is down. Some alternatives we considered and didn't go for: - write something in Zope to listen for SMTP connections, effectively large portions of an MTA. This would be cool but painful. - pull mail from a POP or IMAP server. This had the downside that it introduced polling into the system (slow) and also required something to happen on a schedule, which doesn't happen in Zope yet. So: - Within Exim, use the "pipe" transport to get email for a particular host sent to a program on the standard input. If the program called returns certain codes then Exim will queue the message and try again. - This program takes the email message and puts it into Zope, probably by calling a DTML Method or something. This would probably be configured by objects in the Zope ZODB which say effectively "When you get email for this address, then call this Method". - The DTML Method is responsible for doing the right things to get the email message into the ZODB in whatever form is appropriate. We haven't yet figured out how to make sure the above mail handling program can find all the relevant configuration documents. Is there some way of efficiently finding all instances of a particular ZClass? (Chris W. still isn't sure that's how the configuration will work but that's the plan for the moment, so any thoughts would be appreciated) What we'll do is a first version that hard codes everything in the above script and prove the principle of the thing, and then move onto the configuration. Does this sound like what people need? Any thoughts, comments, warnings? I don't know yet what kind of schedule we'll be able to do this on but drop me a mail and when there's something to play with we'll let you know. Simon -- - My opinions are my own, NIP's opinions are theirs -- Simon J. Coles Email: [EMAIL PROTECTED] New Information Paradigms Work Phone: +44 1344 753703 http://www.nipltd.com/ Work Fax: +44 1344 753742 === Life is too precious to take seriously === __
[Zope] Python development team moves to BeOpen.com
This was on Slashdot earlier today. See original letter below Nitin Borwankar [EMAIL PROTECTED] http://www.pythonlabs.com/letter.html ___ 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 )
