Forward/backward server-client compatibility
ovidiu.feodorov Feb 3, 2006 12:32 PMScott wrote:
I have looked through the current jboss-jms tree usage of serialization and we are making the same mistake with respect to versioning of the stream format. There is no versioning. Each writeExternal/readExternal pair should have a version number that allows for the contents to evolve over time in a backward compatible way. Adding data that can be reasonably defaulted is a backward compatibile change that we need to support.
Ovidiu wrote:
Thanks
I'll make sure we fix this.
Tim wrote:
I'd like to explore the compatibility requirements for JBossMessaging a bit more as this is currently a bit of a grey area for me.
I'm assuming a version x client should work with any version y server where y >= x.
Should a version x client work with a version y server where x > y ?
When can we make changes to interface/wire format? Is it only on major releases?
I'd like to get a better understanding of this so we can make sure we're building it in properly.
Scott wrote:
The requirement is long term compatibility or else the messaging framework is not suitable for the backbone of an ESB which by definition will operate in a heterogeneous environment. If an binary incompatible change has to be introduced, this is really a new invoker protocol that needs to be a derivative of the existng protocol. This is like introducing UIL2 in addition to UIL. Both will need to be supported at that point. Certinly one can have features never available in the other.
There is no x, y for which interoperability does not exist.
Ovidiu wrote:
In other words, total backward compatibility.
Of course, we need to add tests for that (TODO)
Adrian wrote:
But more importantly. Scott wants forwards compatibility as well ;-)
Depending on how this is designed/works, the protocol/version could be negotiated once at initial connection rather than passing it on every request.
Adrian wrote:
There's some "interesting" edge cases when a client wants to know if it can take advantage of certain features in the later versions of the protocol.
The problem being if it is talking to a cluster with transparent failover and the cluster is heterogenous in terms of versions supports.
Ovidiu wrote:
Interesting. How about client and the server that are "open" to the protocol they use, they negociate this using some sort of handshake.
Or even better, the client has the wiring to "adapt" its wire protocol based on the information it finds in the ConnectionFactory. The server "advertises" the wire protocol it understands, and the client has a built-in mechanism to adapt to that.
I (we) need to think about this.