Opentalk disconnections

Hi List,
    Im working on a server-client application, distributed with
opentalk, in which the "real" objects have to be in the server, accesing
from the clients with proxies. However clients can create theese
objects. The problem is that if the image shuts down abruptly (power
shutdown), i need to be sure that all the objects are always in the
server. Im looking for a way to ensure that kind of behavior with
opentalk. Any idea?

Emiliano.

Hi Emiliano:

 From the description, it sounds like you need a persistent object  
repository that has behavior.  I suggest you look at GemStone.  Since  
the advent of their GLASS initiative, getting GemStone has become a  
lot easier.

http://seaside.gemstone.com/
http://www.gemstone.com/

Good luck!

On Nov 12, 2007, at 8:20 AM, Emiliano Pérez wrote:

Thanks!!
Joseph Bacanskas [|]
--- I use Smalltalk.  My amp goes to eleven.

Thanks a lot for the tip.

I´ve dowloaded the evaluation copy, but i cannot seem to get it to work,
the key that is downloaded with the copy has expired on september 30th.
I been trying to reach gemstone by mail but i havent got any answer just
yet.
Does anybody knows another way to get a working evaluation copy/key?.

Thanks again, Emiliano.

ps: Sorry if this is an off-topic.

Joseph Bacanskas escribió:

Emiliano Pérez wrote:
> Hi List,
>    Im working on a server-client application, distributed with opentalk,
> in which the "real" objects have to be in the server, accesing from the
> clients with proxies. However clients can create theese objects. The
> problem is that if the image shuts down abruptly (power shutdown), i
> need to be sure that all the objects are always in the server. Im
> looking for a way to ensure that kind of behavior with opentalk. Any idea?

Is there a reason why the clients can't create new objects on the server and access them remotely as other pre-existing objects ?

If there is a need to create new objects locally on the client there is a number of replication strategies that could be implemented, but none is provided out of the box.

HTH,

Martin

Emiliano Pérez wrote:
The simplest way to create the object on the server is by sending #new (or whatever the appropriate instance creation message is) to the class residing in the server (instead the one on the client). Does that now work for you ?

Martin Kobetic escribió: Yes, currently i´m using specs (kind of object stubs) to create the
objects, passing them as values to the server and doing the creation
over there. This way i assure that the creation is always done in the
server and the clients always handle proxies. The model of the
application is very simple so, for now, i think opentalk will do the job.

Thanks, Emiliano.

On Nov 12, 2007, at 5:20 PM, Emiliano Pérez wrote:

> Hi List,
>    Im working on a server-client application, distributed with  
> opentalk, in which the "real" objects have to be in the server,  
> accesing from the clients with proxies. However clients can create  
> theese objects. The problem is that if the image shuts down  
> abruptly (power shutdown), i need to be sure that all the objects  
> are always in the server. Im looking for a way to ensure that kind  
> of behavior with opentalk. Any idea?
>

Here's a rough description of how we do it in our trading platform,  
we don't use Opentalk for client-server communication but that  
shouldn't matter much for this discussion.

First off client and server have separate model hierarchies, on the  
client side optimized for one-to-one mapping into the UI (mostly  
using aspect adaptors) - as such they all implement the behavior of  
Model. On the server side they are geared towards database  
persistency and implementing domain logic.

The client side model is manipulated by the server only, the server  
sends objects that convey a simple message (added order/removed order/
updated order/...) that will update the client's state. Through the  
dependency mechanisms (Model behavior and aspect adaptors) the UI  
gets updated automatically.

On top of this UI (that essentially reflects server state) we have a  
set of tools to create messages for the server, some of these are  
modal -like a simple dialog 'are yo sure you want to remove the  
selected orders', most are not -for example screens where new orders  
or updates are prepared. All of these tools have a 'submit' button,  
hitting it will send the appropriate message to the server (which  
will update its model and then send a message to the client to have  
it show the update in the main UI).

This should meet your main objective of having objects instantiated  
on the server side only.

As far as user experience goes it is near ideal, the application  
clearly communicates a separation between shared state (the main  
screens showing the server state) and the tools that show ephemeral  
local state - simply by the presence of a 'submit' button. Moreover  
the application doesn't lock up due to network latency because we  
need not wait for an answer, we know the main UI will update  
eventually. Network round-trip time is therefor not a very important  
factor in usability.


I am not well versed with Opentalk, but if you use it to implement  
the above scenario you could choose to use two remote objects, one  
models the flow from client to server and the other models the UI  
update traffic. Alternatively you can have one server object that is  
shared remotely and manages both flows. The important point is that  
all other objects will be passed as value only (and as a consequence  
you will need to model identity explicitly where you need it, in our  
example by using unique order numbers). I forgot whether Opentalk  
supports fire-and-forget semantics, I'm sure someone else here can  
chime in on this.


Let me wrap up with listing some consequences of using this model:

-Start up time is a bottleneck, whenever a client connects its model  
needs to be fully populated by the server, in our application that  
turns out to be massive with login times exceeding a minute for  
certain user roles. We partially mitigate this by partitioning the  
client model along subject areas and loading their initial data  
later: when a dependent screen is opened for the first time. If login  
happens infrequently this is not a big issue.

-All the client side software degenerates to 'just being a UI', as  
such you have to forget about the separation between domain and UI,  
there is no domain in the client - the entire Model hierarchy is  
geared towards how the domain is *presented* to the user. We found  
that this needs repeating during development, habits stood in the way  
of treating all the domain related classes on the client side as mere  
presentation classes. But once we were thinking about it in this way  
it turned out to be a great freedom.

-Nearly all domain logic is implemented on the server side only. The  
big exception is input validation which we duplicate on the client  
side so users don't have to press the 'submit' button and wait for a  
server reply only to find out that something was entered incorrectly.

-Maintaining two separate hierarchies for client and server is an  
extra expense.



HTH,

Reinout
-------