Ok, I finally got some decent internet access....
At 07:04 PM 5/14/2002 -0400, Shengaout, Michael wrote:
>Here is the scenario we need to support:
>* Stateful session bean returns collection of Cayenne data objects
>to web container.
>* Web container deletes and modifies objects, adds new ones and
>calls stateful EJB with the updated collection. Updates may be done to the
>attributes (setName(), set DOB()), as well as to the relationships
>(addAddress(), setToEmployer()).
>* Changed collection is reconciled (somehow) with the Cayenne
>context in the bean and saved to the db.
I agree with the set of requirements.
>Now here are the issues.
>1. Data Context is not sent remotely. Reference to DataContext in
>every data object is transient (meaning it is not going to be serialized
>and sent remotely). We need to handle reference to NULL DataContext
>gracefully,
Here is what I think about the whole client-server communication issue. I
think that client must first obtain a special ClientDataContext from the
server bean via a business method call:
// ClientDataContext extends DataContext
ClientDataContext ctxt = remoteObj.getClientContext();
This will eliminate any limitations of what client can and can not do with
Cayenne. ClientDataContext is passed by copy and communicates with the
server via a mechanism that we come up with. This can be an extra socket
connection, RMI etc. This way this will work not only with EJB servers but
with any other remote scenarios (applet-servlet communication for
instance). This is similar to what WebObjects uses with their Java Client
technology [
http://developer.apple.com/techpubs/webobjects/JavaClientDesktopApps/index.html
], they use HTTP to communicate with the server (fewer problems with
firewalls, tunneling, etc.) We can implement optimized serialization
mechanisms to transfer objects back and force, and place as little
limitations on the client as possible.
>2. We have problem creating new data objects on client (web
>container). To create a new object we need to register it with
>DataContext, which is not sent remotely (see prev item).
[Not a problem with the solution above]
>1. Make DataContext field in the Cayenne data objects non-transient
>and sending server DataContext to the client. Of course, it means that the
>whole tree of objects, including those not needed, will be sent out
>remotely, but we will have everything on client side! When new objects are
>added and the changed collection is sent back to the server (from web
>container to EJB container), the first thing EJB method would do is
>replace DataContext from server with the one received from client.
I think this fits into what I suggested. To do a final commit client
DataContext would commit to its server-side peer via its own connection
channel, then a business method will be called on an EJB that also has
access to the server-side peer:
try {
// will send changes to EJB-side context
ctxt.commitChanges();
// will commit changes to the database
remoteObj.commitChanges();
}
catch(Exception e) {
// do something smart
}
This way server can also do some data operations with objects within a
business method, since it has been already synchronized with the client.
>2. We may use different DataConext-s for client and server. I am not
>sure how exactly we will do it, but we may use writeObject()/readObject()
>and writeReplace()/readResolve() methods for substituting DataContext on
>the fly. To get this going we will need a singleton access to the server
>DataContext, so that the client DataContext could reconcile itself with
>the server DataContext as data is read.
Agreed. Each client DataContext will have a server peer context. In a way
this is singleton, but I would rather call it session context or something.
It will be created from scratch every time a session bean is assigned to a
new session.
Andrus
This archive was generated by hypermail 2.0.0 : Thu May 16 2002 - 04:48:24 EDT