Re: [Modeling-users] N-tier development and modeling

[Matthew P. <pa...@dm...>]

Hi,
        Tom Hallman and I work together, so I speak for both of
us.  Numerous comments below:

On Sun, 7 Mar 2004, Federico Heinz wrote:

> On Thu, 2004-03-04 at 18:06, Tom Hallman wrote:
> >    Here is the situation: my colleagues and I are attempting to put
together
> > a framework using an N-tier methodology, with the client software
> > interfacing to the server/database backend via remote procedure calls
(RPC).
> > For us, Modeling will serve as a large part of that backend, with an
API
> > written overtop. The client will make calls to this API, and all will
be
grand.
>
> Maybe I'm missing someting here... ?but are you sure that this ought to
> be solved in Modeling itself? I can't help but refer to Modeling's
> ancestor: EOF within OpenStep. In OpenStep, you would use EOF to get
> object/relational persistence, and if you wanted to do n-tier deplyment
> you'd resort to Distributed Objects, which were orthogonal to EOF (i.e.
> any app could use either one, or both, or none).
>
> So maybe what you are looking for is not a Modeling extension, but a
> network-transparent message passing system for Python, which can be used
> together with Modeling?
>

If I understand you correctly, I think you are talking about a similar
solution as the one Tom is proposing originally.  To rephrase our idea, it
is to have to main components: a server and and a client, where the server
provides core data-accessing and data-manipulating functions, and the
client handles the interface to the user and the appropriate calling of
the functions on the server.  For example, if a person had entered their
contact information through a web form, the client code to take that code
and save it to the server would be (rough sketch, sorry I don't know
python or modeling intimately yet):

  # None of the following objects are explicitly related to Modeling

  # Set the form data
  address = Address()
  address.setCity(formData["city"])
  address.setState(formData["state"])
    # etc.

  person = Person()
  person.setAddress(address)
  address.setPerson(person)

  # Initialize connection to the application server (this would be done
  # once somewhere at the beginning of the client's initialization)
  appServer = new AppServer(host="http://www.myappserver.com",
                            protocol=XML_RPC,
                            auth=userObj)

  # Call add on the object PersonContainer, with person as the argument
  # This is a "business logic" method, and may be the sort of transparent
  # message-passing interface you were mentioning
  appServer.PersonContainer.add(person)


On the server side (this would be served up with Zope)

class PersonContainer(ContainerBase):
  def add(self, person):
    """ This method would likely be abstracted, but I wrote it out for
        the example.  Here is where the Modeling code comes in.
        One note: this person object *IS* a modeling-derived enterprise
        object.  The translation from a generic object on the client side
        to a modeling object on the server side is a function of the
        framework we are developing.
    """

    self.ec.insert(person)
    self.ec.saveChanges()


I hope this example is helpful and makes sense.  It is our hope that by
separating out these common "business methods", that we can write numerous
different kinds of clients (web client for a public interface, gtk client
for an administrative interface) that will all utilize the same set of
business methods.  Also, we can have the Application Server serve as a
common point for numerous kinds of clients to go to in order to access a
number of different data sources (LDAP servers, global
configuration files, and of, course, Modeling-accessed DB's).
        I would be interested in any comments you all have as to how we
are going about doing this n-tiered approach and utilizing Modeling.  As
far as we can tell, the only part of Modeling we lose is its faulting
capabilities on the client side.  But the net gain of not having to write
any SQL, not having to care what kind of DB we are accessing, not having
to worry about locking or transactions are all enormous benefits that
Modeling gives us.

                                                Thanks,
                                                Matt