#20 message version checking
We want to be able to verify the compatibility of
messages over time. First a few bounding notes:
- this has nothing to do with the revisionNumber
of a SandPersistMessage. That's the version of
the data, not the version of the struct def.
- messages serialized to XML may be transformed
by the adaptor nodes either inbound or outbound
or both. That's separate processing on a
per-application basis.
This RFE deals with autogenerated validation of
message versions and recovery hooking. This is
not a substitute for adaptor nodes, it's an
additional mechanism.
Phew. Ok, here's the idea. Each transmittable
message also has a getStructVersion() method, which
typically returns the CVS version (or whatever is
specified). The generator will need to be able to
load a class to support other systems, but this
method is written automatically.
The message receiver checks the version number of
the message to see if it is the same as what it
understands. What it understands was also
generated at compile time. If the receiver does
not understand then it first calls it's own
versionConvertTo method. If this fails, then
- if the message was received asynchronously,
then the node shuts down. It doesn't understand
what is going on, so it shuts down to avoid
causing any damage in its ignorance. This
behavior can be overridden.
- otherwise, if the message was received
synchronously, the node returns an error
STATUS_VERSIONERROR with the the expected
version as the first part of the error text.
The sender then attempts to convert the version
by calling its boolean versionConvertTo method.
If this method returns false (it was not
overridden or no conversion was possible), then
an error is logged and the messaging failure
propagates. Otherwise the converted message is
resent.
That's about it. Nodes are processing and are not
handled through this data versioning mechanism.
Logged In: YES
user_id=452458
I lowered the priority on this, not because this isn't
important, but because it's fairly situation specific and
I'm not totally convinced this is something that can be
handled automatically for all users. Let's see what comes
out of a few real-life scenarios and then factor what's
common if a common pattern develops. This approach seems
fairly viable, so I'm leaving the RFE open in case somebody
wants to try it for their particular situation. Maybe the
result could be made available as an optional patch.
The specifics of the version checking situation range way
beyond hooking particular version control systems. The main
issues revolve around the number of adaptor nodes and what
kind of technology they are using, combined with the rate of
structural message change intra/inter-enterprise.
With document-based WS comms, the adaptor node may
handle
version checking as part of general validation, rather than
an explicit activity. If versioning is very slow, and/or
legally contractual, automated versioning may not be worth
it. Likewise it might be less important on the consumer
side and more important on the provider side. There's a
big difference between bulletproofing deployment rollout
and adapting inter-enterprise comms. The appropriate
strategy is going to be pretty case specific.
Leaving this open but back-burnered for now.