Re: What's up?
On Wednesday 04 February 2004 11:18 am, Matthew Patton wrote:
> I considered switching to GNUe, but hesitated because of the
> amount of work necessary to make the project usable. In my searching, I
> came across Apple's WebObjects (http://www.apple.com/webobjects/). Its
> proprietary, so actually using it as a tool is out, but I read through
> their docs for the Enterprise Object Framework (EOF,
> http://developer.apple.com/documentation/WebObjects/Enterprise_Objects/inde
>x.html) and was thorougly impressed. I gleaned a great deal of insight into
> how one designs a well-abstracted framework that separates how the data is
> used (the objects) from how the data is stored (the rows in the relational
> DB). It is the best, most well-designed Enterprise Object Framework (or
> Object/Relational Mapper) that I have seen.
Thanks for the Apple WebObjects/EOF references. They should be very useful in
evaluating parts of the current app-server work of the GNUe project. If it
turns out that GNUe is not salvagable, this will help in evaluating /
developing alternatives as well.
> I was very pleased to discover that there is already an Open
> Source (GPL) port of WebObjects' EOF to Python, called Modeling.
> (http://modeling.sourceforge.net) It doesn't have all of the fancy
> features that Apple's EOF has, but it has many of them and is nevertheless
> in a very usable state (several production apps have been written in it),
> and it seems well-maintained and well-documented (caveat: it really helps
> to have read Apple's docs before reading Modeling's docs).
This project looks interesting although it seems somewhat limited in
functionality at this point compared to Apple's "complete" EOF framework. As
example, in the area of concurrency, it has no sessioning or 'notification'
system yet. See section 1.6 of the Modeling user guide. It does serve as a
basic O-R bridge ("Business Objects"), but I would point out that this is
only one layer of the "middleware" software stack. In comparison, GNUe is
attempting to build the whole stack. But perhaps Modeling could be used in
conjunction with other Python classes to provide the same thing that GNUe is
aiming for..
I guess this whole "Enterprise" / n-tier thing is sort of a cutting edge area
in software development. Lots of people have their own ideas what it all
means, implementations vary, and the terminology is sloppy. Frankly, it's
pretty frustrating overall. I guess in my view, given current understanding,
this is what the ideal software stack looks like:
1.) Client software: Either human interface software (web application server
(PHP,Perl,Zope), DHTML + JS XML-RPC, standard GUI, handhelds (Palm,PocketPC))
or a web services client.
2.) Remote Protocol Interface (XML-RPC, SOAP, CORBA, RMI, etc.): provides a
means for clients to call business methods.
3.) Authentication / Session Interface
4.) Business methods (or 'procedures'): interact with the business objects to
do real-world tasks. (Example: Add_Person)
5.) Business objects: O-R bridge, transactions, caching, integrity and
consistancy
6.) Data interface: abstraction of database or other backends
7.) Backends: database servers, LDAP, email, etc.
* Note: 2 and 3 may be partly inter-related.
What you describe, using Modeling + Zope, sounds to me like removing layers 2
through 4. This is still too limited in scope, in my opinion, because you
are using a native interface (Python) between the two and this prevents any
other clients from ever being written. So, in the end, it's really not much
better in terms of flexibility than 2-tier except that now you are using
objects internally.
ps.) If anyone else can shine some light on this confusing topic, please do.
(:
Chris Gebhardt
Reply to: