Discussions

EJB design: Versioning of applications and Services

  1. Versioning of applications and Services (1 messages)

    [Forgive if this is in the wrong forum--it seemed like the most appropriate place]

    I have been looking for some articles/patterns etc. on the subject of service and application versioning and have not been able to find anything that has been of much use. I'm looking for people's suggestions for where to look or experiences if they have run across this issue:

    We have a defined XML spec, version 1.0. e.g.

    <process version="1.0">
    <query>
    <stuff/>
    </query>
    </process>

    We would like to use a binding mechanism (JAXB, Castor, etc.) in order to create objects from DTD/schema. We then would use the created objects in the internals of the application for business logic or whatnot (note: there likely should be some notion of seperation of specificity here, such as an implemented interface or an abstraction layer...)

    Client A uses the version 1.0 of the process XML via a JSP. Client B comes along and wants more functionality in their processes (version 2.0), so more tags are added and new infrastructure is put in place to support the new functionality, but the old functionality was not removed nor has the need for it been removed. In many cases, version 2 will be a superset of the services exposed in version 1 (although the specific tags may change).

    e.g.

    <process version="2.0">
    <query attr="true">
    <stuff-changed-name/>
    <morestuff/>
    </query>
    </process>

    (BTW the guts are inside of a J2EE container. The business rules are in found in various classes...)

    The options that have been considered so far;
    1. Keep completely seperate paths through the application and use the class/package naming to seperate the functionality between, i.e. version 1.0 and 2.0 of the application in com.a.v1.* and com.a.v2.* where each version would extend the one before it (possibly) and only change the portion that needed the new functionality (i.e., extend the changed classes)
    2. Up convert the version 1.0 request to the version 2.0 on the request and down convert on the response (i.e., map the fields)

    Some pros/cons for Number 1;
    o There could a level of confidence that the old code will still work as it wouldn't be touched.
    o The codebase would start to bloat (i.e., ProcessV1, ProcessV2, etc. all in the same package or the Process class in two seperate packages)
    o Maintenance and troubleshooting could become more complex

    Some pros/cons for Number 2;
    o A single unified codebase with a single path.
    o Easier maintenance/troubleshooting
    o An up/down conversion (v1 to v2 back to v1) would need to be done for any request of an earlier version service. This could be tedious to code and, with a number of versions, a lot of code to convert

    So, essentially;
    o What are some good ways to maintain older versions in a service-based application?
    o Do either of the aforementioned approaches seem the better of the two? A combination?
    o Are there other approaches that are viable?


    Anyone with any experience in this arena or suggestions for alternative solutions? If I was unclear or more specifics are needed, I'd be happy to elaborate.
  2. Versioning Services/Interfaces[ Go to top ]

    How did you do that??? I am also facing almost the same problem. We have a client-server application. Clients sit on various platforms and access the server using various remoting channels. We have separate set of bindings for each platform. What is the best way of versioning the services/interfaces at server side so that only compatible version clients can access the server APIs.