java work

State vs commands

A recent thread on a french java mailing-list prompted me to finish up this post I have kept in draft for a while and post it...

I have been working a problem which can be abstractly described as : pushing and updating a data model on a client which will never going to send updates to the server (aka master/servant model). The catch is that the data model on the client may have a different granularity than the data model on the master !

Basically, I see two solutions to the problem:
- via commands : add X, change Y, remove Z. From what I understand, this would be considered in SOAP as RPC-style
- via state : "this is what should be on your side for the tree of elements W,U,V". From what I understand, this would be considered in SOAP as document-stlye

I have been trying to figure out the real differences between these and their consequences.

Commands: Commands come naturally to a programmer. They are explicit and, on the surface, imply detailed knowledge of what is going on in the system. However, I question whether all clients always need to be told by the server whether something is being added, changed or removed. In fact, I am nearing the conclusion that in a one way, low-throughput system, commands are unecessary when a master commands a slave. Furthmore, such detailed commands are only useful if the data models match closely; if not, the client still has to analyse the commands and determine the necessary course of action on his side.

State: During discussions, I have found that state is not an easy notion to grasp for some people who feel much more comfortable discussing commands with their associated parameters. The way I see it is that a state-based exchange system is an easy way to "just" push the latest version of a tree of elements to a client, without having to do any analysis on the server. This can come in handy when (a) the server's CPU must be saved and it would be costly to determine the commands (b) the client doesn't need to be told what is "happening" and just needs to know "what is".

Equivalence of state and commands: Can anyone confirm that both are in fact equivalent ? I assume that they really are using the following line of reasoning:
- Sending a document (state) with a unique id for the first time to a client is equivalent to an add command and can be determined by the client.
- Sending a document (state) with a unique id that is already in a client's system is equivalent to a modify command and can also be determined by the client.
- Sending a empty document (state) with a unique id that is already in a client's system is equivalent to a remove command and can also be determined by the client.

Obviously, you could also decide on a document to describe an element and send add, update and delete commands with the document as a parameter. This would tell the client what it needs to do with the document explicitly.

The question that springs to mind here is : what is the real value of having the server describe the command add/modify/remove in this case assuming the client can determine itself ?

Granularity of state: Once you start delving into the idea of just sending state across the wire, it becomes important to determine the correct granularity of the state you want to transfer.
The "larger" it is, the more often the server is likely to send the full document and the more analysis and brute-replacing the client will have to do when it receives it.
The "finer" it is, the more document types you have to handle and the more critical it is for the system to process documents in the correct order across document types (if doc A references state described in doc B, you better make sure doc B has been correctly processed first).

A few ideas
- whether you choose a fine or a large granularity, you will end up sending as many documents if you send them "live". However, large documents will incure higher transport cost
- if you buffer and delay updates on the server then you can probably group multiple server-side updates into one document send so larger documents will in fact lower the traffic

Building the state/documents to be sent over the wire: Once the system has decided that something has happened and needs to be pushed to a client, the documents must be built. There are two ways to do this:
- the first is to store some state in the event message that triggers the document building.
- the second is to make the event message stateless and query the system state to build the document

Although the first case may seem most appropriate, I don't think it is. If the documents you build aggregate multiple underlying business objects, you're going to have to store all of their state in each message. Furthermore, if you store state in the event messages, you must make sure they arrive in the correct order at the subsystem that builds the documents. This may be a very costly pre-requisit or even impossible in a clustered environment.

The second case relaxes the ordering assumption as long as events do in fact arrive at the document build subsystem. Furthermore, the part of the system that generate the event messages and the part that processes them really are decoupled, there are no assumptions of what the message needs to contain.
The drawback to the second case is that building a document requires querying the business objects (but that may very well been have been the case in the first case too!) and being very careful of caching (imagine a case where a business object is changed, an event message is sent but when the state is queried to build a document, the cache is stale).

Uses for such a system: A state based system for information exchange can be used when you don't want to impose a total order on the events that trigger the sending of the information (typical of a clustered environment). You can buffer these notifications for a while and then build the documents that you can determine have been impacted by the changes to your system state.

• even if more than one event has consequences on a document, the document can be sent only once


• the order in which events have been received doesn't matter because you're not building you document based on information in the even message but on information directly from the state of your system.

Drawback to such a system: Handling the case where state is removed from the system can be tricky. If the top element of your tree is removed and you receive the notification for it, you can no longer get any information for it when you handle the notification ! I think the way around this is to put some state for removal notifications but it won't solve the problem of erasing all the documents in the nodes below the top element. In this case, the client needs to enforce referential integrity and remember that when exchanging state, you exchange documents : why not send an empty document with the id of the element that was removed ? (This can be an issue if you identify the element by a natural key though..). If an element below the top element is removed then you must resend the document describing the top element and its children...

Has anyone worked on these issues ? Any pointers ? Comments ?

Posted by pgirolami76 at April 3, 2004 10:15 AM | TrackBack