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:
- Documentation is critical to the success of a system
- UML models are good
- Models as XML are not as good
- Serialization is not trivial
- Writing and understanding serializers is not easy
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.
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.
