Board index » delphi » OPF, Caches and concurrency

OPF, Caches and concurrency


2004-07-01 02:08:59 AM
delphi108
Hi,
Sorry for the long post
I am begining to design a next proprotype of my opf and I have to make
a decision regarding its architecture.
The OPF has cahes for the clean objects and caches for the dirty objects
in a transaction.
We plan to separate a serve and a client. The server holds the OPF and
all the objects (something like an object enviroment) and the clients access
the objects remotelly. We want the clients to use the objects as if they
where local.... like..
Customer := RemoteFactory .CreateNewCustomer;
...
use customer as it is a local object
De design will address concurrency.
This are the posibilities I have in mind
a) Remote Proxys
Where every message to an objects (method invocation, property read,
etc) will be translated to a message through the net (LAN, less probable
internet).
The client only have this proxys and the factory to generate instances.
Right know we have a code generation that could generate the proxys
manually.
Adv) Proxys can be in any language, can generate then automatically,
light clients, can implement observers on objecs in server, etc
Disadv) Net Traffic.
( This is my personal and theorical favorite, but performance is very
important)
b) Copy of the object in the client
Under this schema, the server would only hold clean objects and clients
shoud have dirty ones. This wold require to add some functionallity to
clients and they wont be thin and they will be in delphi.
c) Hibrid Proxys
A remote proxys that holds all messages sent to an objects and send them
all toghether to the clients
d) No server, just tymestamps.
e) Servers exposes services but not objects. Server could export soap
function and procedures. Clients would call those functions insteas of
creating objects.
This are the designs in the top of the list.
I will really appreciate your comments and experience in the subject. If
some data is missing please ask.
Esteban Calabria
 
 

Re:OPF, Caches and concurrency

It seems my post is a complete failure
:(
"Hechicero" <XXXX@XXXXX.COM>escribi?en el mensaje
Quote
Hi,
Sorry for the long post
I am begining to design a next proprotype of my opf and I have to
make
a decision regarding its architecture.
The OPF has cahes for the clean objects and caches for the dirty
objects
in a transaction.
We plan to separate a serve and a client. The server holds the OPF and
all the objects (something like an object enviroment) and the clients
access
the objects remotelly. We want the clients to use the objects as if they
where local.... like..
Customer := RemoteFactory .CreateNewCustomer;
...
use customer as it is a local object

De design will address concurrency.
This are the posibilities I have in mind

a) Remote Proxys
Where every message to an objects (method invocation, property read,
etc) will be translated to a message through the net (LAN, less probable
internet).
The client only have this proxys and the factory to generate
instances.
Right know we have a code generation that could generate the proxys
manually.
Adv) Proxys can be in any language, can generate then automatically,
light clients, can implement observers on objecs in server, etc
Disadv) Net Traffic.
( This is my personal and theorical favorite, but performance is very
important)

b) Copy of the object in the client
Under this schema, the server would only hold clean objects and
clients
shoud have dirty ones. This wold require to add some functionallity to
clients and they wont be thin and they will be in delphi.

c) Hibrid Proxys
A remote proxys that holds all messages sent to an objects and send
them
all toghether to the clients

d) No server, just tymestamps.

e) Servers exposes services but not objects. Server could export soap
function and procedures. Clients would call those functions insteas of
creating objects.

This are the designs in the top of the list.
I will really appreciate your comments and experience in the subject. If
some data is missing please ask.

Esteban Calabria




 

Re:OPF, Caches and concurrency

"Hechicero" wrote
Quote
It seems my post is a complete failure
:(
Don't feel too bad--nobody gets an answer to every post.
I only have one comment:
Quote
>a) Remote Proxys
>Where every message to an objects (method invocation, property
read,
>etc) will be translated to a message through the net (LAN, less probable
>internet).
Performance killer--if each property get/set or method invokation on an
object is a server call, then just showing a customer and address on the
screen could mean 20-30 round trips--add an order with orderlines and
product details and you've got yourself a traffic nightmare. Take a look at
Martin Fowler's _Patterns of Enterprise Application Architecture_ where he
talks about fine and course grained interfaces.
bobD
 

Re:OPF, Caches and concurrency

Thanks bob,
I have the same feeling about the proxy.
"Bob Dawson" <XXXX@XXXXX.COM>escribi?en el mensaje
Quote
"Hechicero" wrote
>It seems my post is a complete failure
>:(

Don't feel too bad--nobody gets an answer to every post.
:)
Thanks. I am not feeling too bad.
Quote

I only have one comment:
>>a) Remote Proxys
>>Where every message to an objects (method invocation, property
read,
>>etc) will be translated to a message through the net (LAN, less
probable
>>internet).

Performance killer--if each property get/set or method invokation on an
object is a server call, then just showing a customer and address on the
screen could mean 20-30 round trips--add an order with orderlines and
product details and you've got yourself a traffic nightmare. Take a look
at
Martin Fowler's _Patterns of Enterprise Application Architecture_ where he
talks about fine and course grained interfaces.

bobD



 

Re:OPF, Caches and concurrency

In article <XXXX@XXXXX.COM>,
XXXX@XXXXX.COM says...
Hi Esteban :)
Remote proxies with a call for every property would be a *real*
performance killer. Binh Ly spoke a lot about DCOM, and it was the same
sort of deal.
Ideally, you want all the data you need for a single object (or even
multiple objects) to come over in a single 'call' to the server. This
means some kind of serialization of the object is required.
Now, you may have the additional complication of property data that's
"expensive" to retrieve. This means you might need more granularity.
Instead of saying "give me everything", you might want to say "give me:
<list of properties>", and maintain some indication of what has been
retrieved in your client-side object (through a bit set, or perhaps
individual boolean fields for the expensive-to-retrieve fields).
That makes the client side a little harder to generate, but it should
still be possible to generate.
Your client proxy should expose everything as individual
methods/properties (or a generic getter/setter) so that you can use it
as though it is local. The server side should expose a single call that
the client proxy can bundle up all its value requests into and receive
the values of all data.
...
There's nothing saying that other folks have to code in Delphi to get
the benefit of your objects. Your 'client proxies' can be bound up in a
program that runs on their machines, and *that* program exposes
interfaces for the users to call, OR you can have the 'client proxies'
run on another machine - same deal.
If they want to get past the multiple-call-overhead, then they can code
to the specification you create for your serialization, just like your
client proxies would. Their choice: convenience or speed :) They should
be able to put together an appropriate serialization-compehending base
class in their language of choice. Just make the serialization ...
sensible :)
-- Ritchie Annand
Senior Software Architect
www.malibugroup.com
nimble.nimblebrain.net
wiki.nimblebrain.net