Re: N-tier development and modeling

        Hi,

  Thinking about this in the background as well ;) I've also wondered
whether simple object-proxies could do the trick for a first step toward
a distributed data layer (which I now think should ultimately be built
on top of EC, but I may change my mind in a few hours:).  And very,
very interestingly now comes Erny w/ something like a proof of concept
implementation on its side! That's very promising.

BTW is anyone here familiar w/ zodb's zeo? It's probably worth looking
at it as well.


John: I'm afraid i do not have the time to dig in cimarron's source code
now, so I think I'll wait for your short example :)

Erny: is your current impl. read-only on the client side or is it RW?
Which architecture are you using? Maybe GlobalIDs along with a map (one
client->one ec) to identify objects, and pickling (or alike) to transmit
an object's data?


-- Sébastien.


Ernesto Revilla <[email protected]> wrote:
> Hi,
> 
> although this message does not respond exactly to the questions exposed here, I just wanted to comment what we do.
> 
> As with pyro, we designed our own protocol on top of  XMLRPC, that is, objects and other data (None, DateTime) may be transmitted from server to client for whichever purpose. The client has a collection of 'dump' objects, in our words ObjectProxies, and nearly every call is a client-server-client transaction. Business logic resides on the server. The database can reside on another machine, of course. This is not very distributed, but it's a 3-tier architecture. We are still developing, so actually we are not in production phase. (In the future we may switch to pyro and/or Corba).
> 
> On the other hand, modeling is able to run at once different models on differen servers, and with the future optimistic locks, the same model could run on several machines.
> 
> In each way, if you work in a distributed environment, the implementation of an object will run on one or more 'server' machines, and the 'clients' will hold some proxies to these objects. All method calls not treated locally, will be send to the server. If you do not want to call the remote object, whenever an attribute is accessed, you can implement a proxy initialization which requests and stores locally all object attributes, or define a method in your framework (as we did), which requests a collection of attribute values for some objects (as a batch).
> 
> 
> Best regsards
> Erny
> 
> ----- Original Message ----- 
> From: "John Lenton" <[email protected]>
> To: "Modeling users' mailing list" <[email protected]>
> Sent: Monday, March 15, 2004 2:00 PM
> Subject: Re: [Modeling-users] N-tier development and modeling
> 
> 
> > Sender: John Lenton <[email protected]>
> > 
> > On Sun, Mar 14, 2004 at 02:37:06PM +0100, Sebastien Bigaret wrote:
> > > I must say all this is really interesting. I unfortunately do not have
> > > the time to investigate such things deeper, but i'm really interested in
> > > a distributed layer. Had a very quick look at pyro, seems compact and
> > > clean. If any of you experiment in this direction I'd like to hear from
> > > the details, problems etc. As far as I can understand things, it seems
> > > that Tom and John are speaking about similar things, if not the same.
> > > 
> > >   BTW about weakrefs and pickle, I can effectively confirm that weakrefs
> > >   are used, mainly in objects (which hold a weakref to their EC) and in
> > >   to-many faults (AccessArrayFaultHandler) which for technical reasons
> > >   hold weakref of the object referencing them.
> > 
> > I've been thinking about this a bit (`in background', if you will),
> > and now I am of the opinion that actually using pyro on
> > editingcontexts and modeling objects is the wrong way to do this; I
> > think proxy classes (via overriding CustomObject?) is probably a saner
> > way to go. You probably don't want to shuttle your modeling objects
> > anyway: what you're wanting to distribute is the data, i.e. the result
> > of e.g. getFirstName, and possibly (although I doubt it) the effect of
> > setFirstName. Not the object itself; that would imply you are
> > distributing your business logic. I'll try to set up an example using
> > cimarron, so you can see what I mean.
> > 
> > > John: after a quick search I was not able to find any english-written
> > > resources about papo and cimarron, is this available somewhere?
> > 
> > papo is https://papo.vialibre.org.ar, but as you noted it's in
> > spanish. cimarron you can find in papo's savannah cvs; I'm afraid it's
> > lacking documentation and examples, and probably isn't much use
> > without a bit of handholding. However, it being a framework, we've
> > tried to keep it in english, so at least running pydoc on the files in
> > Generic/ should provide some insight. Consider it 'pre-alpha', because
> > it is.
> > 
> > -- 
> > John Lenton ([email protected]) -- Random fortune:
> > "In the long run, every program becomes rococo, and then rubble."
> > -- Alan Perlis



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click