Remote Clients

Imported from Google Groups
1

I am developing a system using both a web-enabled server and an
Eclipse RCP client. The server is handing all requests from the RCP
client to store to the database and perform other operations such as
emailing reports, etc.

One of the modules requires to be disconnected from the server so that
the user may do their inspections of equipment. These inspections
require reports to be generated and handed to the equipment operator.
When the user returns to the office and connects to the network their
inspections need to be uploaded the server.

I am wondering if it is too late to be processing a "command" on the
server as the operation has already had real-world changes (ie: the
printed report). Is it possible, even suggestable, that this remote
RCP client also processes changes using commands but then just upload
the events? I should point out that when they start their inspection
that there is no existing record so no concern with conflict
resolution.

It doesn't end there. :slight_smile:

Just because the record was started on the client and then uploaded
later to the server, there will be future changes to this inspection
but only through the server (ie: online mode only). So capturing
these events on the server will be benefitial.

Thanks!

2

Hi Randy,

this problem is often referred to as “disconnected clients”. The issue is that clients do not always have the ability to validate their actions against a single server that knows about an aggregate’s exact state.

The basic solutions to this is actually not really that different from connected clients. A little while ago, one of my workshop attendants came to me with a very similar problem. He was building an application for inspections too. So, here is the basic flow of things:

1- A clients connects to the server (lets assume for the first time). By executing queries, it builds and stores local model. In your case, I could imagine that it would be information regarding the equipment to be inspected.

2- The client disconnects. The client will fully rely on its local model from now on. Before making modifications to your local models, make a copy of them, or make sure a copy can be retrieved from the server, You’ll need it when merging changes.

3- The user does an inspection, and creates some commands (to create an Inspection aggregate with all relevant information). As time (and the inspection) progresses, more command are executed.

These commands are executed agains a local “command model”. This command model should be a full copy of the (relevant parts of the) command model on the server. That means the local client will generate the exact same events as the server would, in the same state. Apply these events on the local working copy of the query model.

4- The user returns to the connected world and connects with the server. Now, it’s merging time.

The client will download all the missed (but relevant) events from the server. These would be any of the events from the locally stored aggregates that the client hasn’t seen yet. If any of these events conflict with your locally generated events, ask your user to resolve them. Your user will be able to change the commands that were stored locally.

The local working copy of the client is no longer necessary. It can be discarded.

Apply all downloaded events to the local model (the clone you made in step 2).

Next, your client sends the locally stored commands to the server. The server will generate new events, which your client will apply to the model as well.

5- Now, the client is completely up-to-date with the server, and all changes have been merged.