Re: Service 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?
I presented a rather detailed approach that Orbitz took and is still 
working at JavaOne last year. Not sure if you can get at the slides, but 
I could send them to you if I still have them around. We essentially 
added a number of service attributes that controlled the versions of the 
services and then did compatibility checks during look ups to find 
compatible services for a client. All of this was behind dynamic proxies.

Gregg is correct in that when you add methods you should be fine. This 
is where compatibility checks come in. I've talked to some folks about 
using preferred classloaders in addition to help handle some of the 
other versioning concerns, but I never got around to implementation. I 
would assume that depending on your size and complexity, classloaders 
might help.

Our main issue wasn't the service versioning, which is pretty simple as 
long as you never remove methods and can gracefully handle slow upgrades 
services (where you slowly bring up the new versions and then slowly 
bring the old ones down). Our biggest issue was data versioning, which 
brings so many headaches along with it. Something we took a look at was 
SDO to make data versioning simpler. DOM is another solution and I've 
done some playing with dynamic languages like Groovy for data because of 
the dynamic runtime invocation.

I would assume that you make changes to your data over time and that 
you'll run into this issue depending on you tiers and such. I talked a 
lot with folks about triangular tiers where your bottom tiers change 
next to never and deal with data as abstractly as possible and as you 
move up the stack you become more volatile. The reason being that if 
something near the bottom changes drastically enough it forces the rest 
of the stack to change to prevent data issues such as data hiding, data 
truncation, data mangling, data dependency corruption, etc. I coined a 
term to describe this lower tier modifications: "bounce the world" 
because whenever we found a need to change a lower tier we ended up 
bouncing every server in the data-center to support the change. Very 
painful.

-bp

--------------------------------------------------------------------------
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]