Remoting version compatibility

[timfox]

Messaging requires full forward and server backward compatibility, between clients and servers (and in the future between servers and servers)

We are building placeholders for this into 1.0 so as not to get caught out in later versions.

However, since we are reliant on remoting we are also bound by it's level of version compatility.

What compatibility guarantee does remoting provide (if any)?

I.e. backwards/forwards/ful compatibility.

If remoting only provides a backward compatibility guarantee (or no guarantee) then it seems we can only achieve Messaging's compatibility guarantee by freezing the version of Remoting used in Messaging 1.0 which would not be good.

[starksm64]

Correct. Remoting needs a strong guarentee. The main issue is future revs of remoting need to be validated before being incorporated into jms.

[timfox]

Added JIRA task:

http://jira.jboss.com/jira/browse/JBREM-340

[tom.elrod]

As far as versioning goes, I can't really take the same approach as jms (see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=76752) where write out version as first byte to wire. This is because a remoting client or server can be used with other thirdparty components (i.e. http remoting client talking to 3rd party web server). Therefore, the best I can do is implement versioning in the externalizing of the remoting objects I expect to pass over the wire (and there are a lot these).

As for features, older features should be usable in future versions (so can use old clients with newer servers). However, newer clients won't necessarily work with older servers (at least the new features won't be supported by the server).

[starksm64]

What matters is that remoting can be configured to the requirements of jms, otherwise jms cannot rely on remoting for its stable transport layer. Although a specific wire format may not be a requirement, one should be able to take control of it. In the case of the http transport, we should be able to map a format version to a header, or first byte of the post content, etc.