Revising a Virtual Service
Web services are bound to change and evolve over time. The loose coupling principles of service-oriented architecture (SOA) imply that service providers can release a new version of a shared service without waiting for consumers to adapt, and that service consumers should test and certify on a new shared service version before switching. Consequently, you might need to have multiple versions of a shared service running concurrently and simultaneously accessible by different service consumers. Some service consumers might need to continue using an old version of a service until migration of the consumer code occurs. Therefore, Web services versioning is an important subject that should be considered carefully in all enterprise SOA approaches.
Current standards for Web services have no explicit support for versioning. However, there are two alternatives for handling access to multiple versions of Web services:
Require the consumer applications to change their code to specify which versions to access.
This option is rarely implemented due to its prohibitively complex and time-consuming nature.
- or -
Use a mediation layer (e.g.,
Mediator) to decouple the consumer from the provider, and thus allow the mediation layer to route requests to the desired version of a given service.
Mediator provides versioning solutions that you can implement, called “versioning patterns”. To implement versioning patterns, you configure virtual services in CentraSite so that consumers can access the desired version of a given service. You can use the versioning patterns to handle access to both Minor and Major versions of services.
Mediator cannot run multiple versions of the same virtual service simultaneously. Mediator only retains the last deployed version of a virtual service. However, suppose you have multiple versions of a native Web service. By using a versioning pattern, a single virtual service can provide access to the various native service versions based on an intelligent routing scheme that routes requests from a particular consumer to the correct native service version. A second option would be to provide multiple virtual services that correspond to multiple native service versions. For example, suppose you have two versions of the native service “GetOrder”. You have the following options in Mediator:
Provide a single virtual service that intelligently routes each consumer to the appropriate “GetOrder” version (either version 1 or version 2).
- or -
Provide one virtual service that routes consumers to version 1, and one virtual service that routes consumers to version 2.