7 Replies Latest reply on Mar 21, 2006 11:40 AM by Mark Little

    Versioning of services

    Mark Little Master

      Using the ESB/SOA actually consists of two phases: the initial creation phase and the maintenance phase, which may have different requirements from the creation phase. Services evolve over time and it is often difficult or impossible to find a quiescent period in which to replace a service. As such, in any enterprise deployment there is likely going to be multiple versions of services being used by clients at the same time. Some of the version mismatch may be hidden by suitable routing and on-the-fly message modifications. JBossESB will address the challenge of versioning of services, something that other implementations tend to ignore. Preliminary thoughts are that services will be identifiable via major and minor version numbers, with pattern matching capabilities provided by a pluggable rules engine, e.g., a default rule would be that all minor versions are compatible within the scope of the same major version number, but that can be overridden with a specific rule by the service provider or system administrator.

      There's often non quiescent period when old services can be replaced. Many ESB implementations overlook this issue. We shouldn't fall into the same trap.

        • 1. Re: Versioning of services
          Mark Little Master

          Damon Sicore mentioned that Shotoku may be useful for helping to address the versioning requirements.

          • 2. Re: Versioning of services
            Scott Stark Master

            We also should not repeat the mistake of ignoring management of esb deployments as a fundamental aspect that needs to be considered from the perspective of an admin as opposed to a developer. I would like a discussion between the JBossESB, JBossAS, and JBossON teams on the whole service definition, versioning and management issue.

            • 3. Re: Versioning of services
              Mark Little Master

              Agreed. I haven't got round to adding the topic on management yet, but it's there to be done.

              Mark.

              • 4. Re: Versioning of services
                Newbie

                How about the possibility to tag a service as deprecated? This would allow to warn the consummer (or the admin) that a migration to a newer version is now imperative.

                • 5. Re: Versioning of services
                  Mark Little Master

                  Sure. We could support that within the repository, which would allow for static bind-time evaluation, as well as some tag within the header (or context) of a response from such a service that the receiver could then use at runtime to force a rebind to a newer version.

                  The problem is always going to be finding a quiescent period when the service can be removed entirely. Without maintaing durable user information, and requiring users to explicitly bind/unbind (ref/unref) the service, you're never going to be able to guarantee a service-fault hit by some client once the service is removed. However, one of the things the ESB architecture we're developing will allow, is the placement of Tomb Stones, so in the case where you really want to leave a permanent forward reference, you can do so: a TS would simply redirect automatically to a new service and short-cut the chain back to the client so that subsequent invocations don't need to go via the TS.

                  • 6. Re: Versioning of services
                    Newbie

                    Thanks for your reply. The Tomb Stone concept is great! It will be very helpful to manage smoothly the transition period in the service end-of-life cycle.

                    D.

                    PS. Will it glow in the dark? ;-)

                    • 7. Re: Versioning of services
                      Mark Little Master

                      It won't glow in the dark, but if you deploy enough of them you may see Wyatt Earp!

                      Actually the concept goes back to some early work I did with some colleagues on fixing the broken link problem in the Web (http://citeseer.ist.psu.edu/context/1033244/0). Still applicable today.