1. All existing applications need to be updated to use the latest version of the service.
2. All existing applications keep using the previous version of the service and the new application gets to use the latest version.
there are pros and cons to both.
With approach #1, extra time and effort are needed to update existing implementations and to retest applications to make sure they the new version doesn't break anything. Automated regression testing is of a key value here. If a team has good coverage in automated tests, retesting can be done fast.
Approach #2 would let a developer to only worry about the new application, with the existing applications continuing to use the previous version of the service. This approach, though straight forward and simple on the surface, is laden with hidden problems of version conflicts. Let's say we have Service A packaged as version 1.0 (a-1.0.jar) and version 2.0 (a-2.0.jar). Even though the two versions are packaged independently of each other, they still not be both used from within the same client application (for example, a web application war deployment) if the classes with changes have the same names. If you deploy a-1.0.jar and a-2.0.jar, you may not get an immediate indication that you may have a problem. But only one of the two jars will actually be used and you may get strange linkage errors or inconsistent and unexpected results later.
Approach #2 is obviously superior to #1 if we could only find a way to resolve conflicts and make sure that the old code runs against v 1.0 of the service and the new code runs against v.2.0 of the service. What's the answer?
I believe relief will come from the OSGi Alliance. I've heard a lot about it (Eclipse is based on OSGi), but only now am finally facing a situation, similar to the one described above, that requires me to take a closer look at what OSGi's is really promising. Over the next few weeks, I'll be playing with various OSGi implementations and APIs. I'll report my findings here.
