modeling-users

[Modeling-users] N-tier development and modeling

[Tom H. <hal...@dm...>]

Greetings to all,

   It is my hope to draw from the experience and expertise of those among 
you who are more familiar with Modeling than I.

   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.

   The problem we are having is that of maintaining state between the server 
and the client. For example, if we fetch a set of Person objects to be 
displayed on the client, and then want to perform a delete on one particular 
Person object, how do we know which Person to delete? Modeling seems to work 
wonderfully up to where there is no RPC necessary, but once we add a split 
over the RPC interface, Modeling seems to lack a natural way to refer to 
objects across that divide.

   One thought we had is to set the primary (and foreign?) keys as class 
properties, such that we can refer to them across RPCs. This is somewhat of 
a hybrid of Modeling and the old-fashioned "use the primary key to get what 
we want" method.

   Any thoughts on this matter would be greatly appreciated! Thanks so much 
for your time.

Yours,
   Tom

___________________________________________________________
Tom Hallman                             DiscipleMakers, Inc
hal...@dm...                 http://www.dm.org/~hallmant
531 Brittany Dr * State College * PA * 16803 * 814-861-4591
Go therefore and make disciples of all nations (Matt 28:19)

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

[Sebastien B. <sbi...@us...>]

        Hi Tom and all,

Tom Hallman <hal...@dm...> wrote:
> Greetings to all,
>=20
>    It is my hope to draw from the experience and expertise of those among=
 you
> who are more familiar with Modeling than I.
>=20
>    Here is the situation: my colleagues and I are attempting to put toget=
her a
> framework using an N-tier methodology, with the client software interfaci=
ng to
> the server/database backend via remote procedure calls (RPC). For us, Mod=
eling
> 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.

Nice!

>    The problem we are having is that of maintaining state between the ser=
ver
> and the client. For example, if we fetch a set of Person objects to be
> displayed on the client, and then want to perform a delete on one particu=
lar
> Person object, how do we know which Person to delete? Modeling seems to w=
ork
> wonderfully up to where there is no RPC necessary, but once we add a split
> over the RPC interface, Modeling seems to lack a natural way to refer to
> objects across that divide.
>=20
>    One thought we had is to set the primary (and foreign?) keys as class
> properties, such that we can refer to them across RPCs. This is somewhat =
of a
> hybrid of Modeling and the old-fashioned "use the primary key to get what=
 we
> want" method.
>=20
>    Any thoughts on this matter would be greatly appreciated! Thanks so mu=
ch
> for your time.

Working with PKs and FKs would work, but it is definitely not the
cleaniest way to identify objects wrt the framwork.  There is a
dedicated component for that purpose: the objects' GlobalID (it can be
accessed through obj.globalID() or by asking the EC for the
globalIDForObject()); a GlobalID is a unique identifier for an object/a
row inside a framework.

  Two different kinds of GlobalIDs exist:

- KeyGlobalIDs identify objects that exists in the database, and
  uniquely identify such an object in whatever EditingContext.

- TemporaryGlobalID uniquely identifies a new object that is not saved
  in the database yet.  Because the objects is not saved, such an
  globalID can identify the object only in its referring EC, or in one
  of its children.

Both can be easily marshalled/unmarshalled, e.g. transformed to strings
and back to GlobalIDs; for example, a KeyGlobalID can be rebuilt from
its entityName() (string) and its keyValues() (dictionary).

  Last, given that you have a gid, you get the corresponding object in a
  EC simply by calling: obj=3Dec.faultForGlobalID(gid, ec)

Does this fulfill your needs?

I still have a question: will you also have an EC on the remote-side?
I'm asking this, because if this is the case the synchronization of the
client's EC and the server's one could be more complicated then simply
identifying objects by their globalIDs and passing some of their changed
attributes. And since I'm currently working on synchronization between
ECs and optimistic locking (working well, I think a first draft wil be
available this week-end), maybe I could also begin to think of such a
"remote" synchronization, esp. if you have a use-case and can consider
testing it in your own app.

-- S=E9bastien.

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

[Federico H. <fh...@vi...>]

On Thu, 2004-03-04 at 18:06, Tom Hallman wrote:
>    Here is the situation: my colleagues and I are attempting to put toget=
her=20
> a framework using an N-tier methodology, with the client software=20
> interfacing to the server/database backend via remote procedure calls (RP=
C).=20
> For us, Modeling will serve as a large part of that backend, with an API=20
> written overtop. The client will make calls to this API, and all will be =
grand.

Maybe I'm missing someting here... =BFbut 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?

	Fede

--=20
GnuPG Public Key: gpg --keyserver wwwkeys.eu.pgp.net --recv-key BD02C6E0
Key Fingerprint: 04F4 08C5 14B7 2C3D DB21  ACF8 6CF5 0B0C BD02 C6E0

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

[Marcos D. <md...@vi...>]

User-Agent: Mutt/1.3.28i

On Sun, Mar 07, 2004 at 09:51:08PM +0000, Federico Heinz wrote:
> 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...

    ... just like pyro?

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

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

[Federico H. <fh...@vi...>]

On Tue, 2004-03-09 at 19:35, Matthew Patton wrote:
> 	Tom Hallman and I work together, so I speak for both of
> us.  Numerous comments below:

Matt,

I think I understood what you were saying, but obviously you didn't
quite understand my response, which is my fault, of course. You will
find numerous references to NeXTstep and OpenStep in the Modeling
mailing list, as many of us come from that background, and Modeling
itself is a loose reimplementation of EOF (a technology first released
as part of NeXTstep) in Python.

Now, the code that you included would work quite differently in the
NeXTstep environment, for instead of doing the CORBA thing, we'd just
ask a server for a remote editing context. The local process would get a
proxy object, that works like it's local, but in fact forwards all
requests to a real editing context that lives in the server. We'd then
query the database using this editing context, instantiating objects in
the server, for which the Distributed Objects mechanism would create
proxies in the local address space. The whole IPC thing then happens
behind the scenes (aside from a few memory deallocation issues, the
programmer thinks he's dealing with local objects --- we can later argue
whether this is good or not).

My point was that, given that Modeling is an EOF reimplementation, it
might be rewarding to explore the possibilities of using something that
replicates the Distributed Objects functionality to achieve your goals.
Marcos pointed out in the list that Pyro might be such a beast...

Regards,

	Fede

--=20
GnuPG Public Key: gpg --keyserver wwwkeys.eu.pgp.net --recv-key BD02C6E0
Key Fingerprint: 04F4 08C5 14B7 2C3D DB21  ACF8 6CF5 0B0C BD02 C6E0