Service Versioning

I am curious how others have tackled/solved/neglected the issue of 
service (interface) evolution and versioning.

I'm thinking about the case where I need/want to evolve a service 
interface, but I know that there are clients out there hanging about 
with the old interface definition.

I can think of two (reasonably sensible, I think) approaches: one by 
creating a VersionedService interface defining a compatibility check 
method something like a
     requiresVersion( ServiceVersionID version )
that informs the service proxy of the interface-version known to the 
client.  (Could run this the other way around and have the client ask 
what service versions the proxy supports, but I see that getting messy...)

Alternatively, use a java.lang.reflect.Proxy to connect the client's 
notion/version of an interface to the (Jini)Proxy delivered to the 
client by a LUS.

(I don't much like the third possibility: "interface Foo2 extends Foo" 
solution.)

What other approaches (presumably more clever stuff) have people taken?

-- 
mike morris :: mikro2nd (at) gmail (dot) com

http://mikro2nd.net/
http://mikro2nd.net/blog/planb/
http://mikro2nd.net/blog/mike/

-- A day without chillies is a day wasted --

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]