If you create web services that only move 'shallow' objects, you will not need Mister Model. In that case I suggest that you return to writing CGIs and simply abandon this foolish Object Oriented stuff because, well it'll never take, will it?

If you want to move Objects from client to server, you will have to deal with serialization and deserialization issues. You will need to learn XML and XML parsers. You will write custom deserializers and you will constantly fight with making those work.

If you are an object modeler, you will have code that constantly diverges from the model. You will strugle to try to be sure that your datamodel accurately reflects your API and your data structures.

If you are a coder, you really want to reduce the amount of documentation that you have to write. For service writers, this means heavily documenting your service APIs and especially your datatypes. If you are a client writer, you will hope that such documentation exists and actually reflects the state of the code as implemented.

I'm not trying to tell you this is the be-all and end-all. I am suggesting the following: UML of a sequence

A model of a sequence. It is a `simple' or `shallow' object because it contains no references to other objects. AN object like this is easily serializable.

UML of a sequence assembly

A model of a sequence assembly. This object is `deep' or `complex' because objects within it contain references to other objects. An objective of Mister Model is to make it possible to transfer objects of arbitrary complexity through the use of web services.