In my previous article I described few most notable service virtualization scenarios, their differences and benefits from the SOA Governance and API Management perspectives. In this article I will show how service virtualization concept in general (and Sentinet product in particular) provide real benefits for the services and APIs versioning challenge. I will use the same service virtualization scenarios as before, but this time applying virtualization concept to different service versions rather than different services.
Service Version concept
What does it mean a service or API "version”? It could mean quite a lot of different things. It can be a new service version that is different only by the actual implementation of service operations, or contract non-breaking version changes, or contract breaking changes, or even a completely different service. A good SOA Governance and API Management product should support any type of service version interpretations. Otherwise users would have had to follow only those strict interpretations that are supported by the vendor product, and almost always there will be use cases and scenarios when vendor’s product falls short of its capabilities to match customer requirements. That is exactly what Sentinet does – it sets no limits in interpreting how new service version can be defined. All that Sentinet does from the design-time service versioning perspective, it associates different service versions with the same service, so that service versions can be treated as literary different versions but not different services.
Speaking about SOAP services specifically (and according to the best practices of SOAP services versioning), a new service version might need to be provided with its own versioned namespaces for the service, its interfaces and schemas. Sentinet does not enforce this as a mandatory requirement but rather fully supports it by showing all different namespaces in the Sentinet Repository and allowing users to change (to “version”) any namespace of the virtual service elements.
At the same time Sentinet provides very specific service versioning benefits during run-time. This article describes only few most notable scenarios. The choice of selected scenario is typically driven by specific service versioning requirements, objectives and priorities.
Service Metadata
SOAP services (unlike REST APIs) are described with services metadata in the industry standard format, Web Services Description Language (WSDL). Among other WSDL elements the most relevant in the context of this article are the ones that uniquely identify service and its structure at the service, interface and operation level. As I mentioned earlier, from the design and best practices perspective, it is recommended to carefully name and version these elements. But it is also important to note that these service identifiers also take important role in managing services versioning challenge at runt-time. Below are examples of these identifiers captured by the Sentinet Console for a sample MyService:
- Service fully Qualified Name, QName that includes service Name and service Namespace.
- Interface QName that includes interface Name and interface Namespace.
- Message Action identifier, where message is either an operation’s Request or Response message. When messages are sent to a service, message Action (typically Request message Action) is used to uniquely identify which service operation a message should be sent to.
Now let's review few practical scenarios and their realization.
Single Interface Scenario
In this scenario a business service is developed and deployed in its first version, and then virtualized through the Sentinet virtual service. Both virtual and business services actively process business transactions. At some later point a new version is developed.
Requirements
- New service version has to be made available along with the older version (meaning both business service versions have to be operationally available at least for some period of time).
- Existing single virtual service has to be able to support both business service versions side-by-side.
- Existing consumer applications have to be able to continue using existing business service version, while new consumer applications have to know about and use only new service version.
- Existing consumer applications have to be provided with the knowledge on the new service version and have to be given enough time and means to migrate to the new service version.
- Older service version and new service version have to be available through the same consumer-facing endpoint (meaning no address changes and no policy changes are allowed).
- Service version upgrade process must be operationally non-interruptive.
Solution
When first service version is deployed at serviceEndpoint location, the virtual service structure may look like this:
Now a new service version is developed and deployed at serviceEndpoint2 location. Let’s make few assumptions about the new service version. These assumptions will cover few differences between existing and new version by the same scenario:
- One operation did not change its name, its implementation could have been changed though.
- Another operation changes its name and implementation.
- A new service operation is available in the new service version.
We can now modify our existing virtual service to aggregate existing business service version and the new business service version through existing virtual service interface, IVirtualInterface.
We cannot save new structure of our existing virtual service yet, because we have at least one operation, Search that will create naming ambiguity within the virtual service. We have to rename that operation in the virtual service's structure to resolve this ambiguity. Operation renaming may also involve assigning new virtual operation’s message Action to resolve another possible ambiguity here. Operation name and message action can be renamed from the Operation Details dialog box.
Once renaming is provided, the new virtual service structure may look like this:
Note that business operation Search is named here as Search2 in the virtual service, see Search2 (Search) highlighted on the screenshot above. The resulting virtual service structure is shown below.
New virtual service structure now satisfies all the runtime requirements. Virtual service endpoint did not change. Messages sent by existing consumer applications will be automatically routed to older service version while messages sent from new consumer applications will be routed to the new service version.
To make requirements completely satisfied we have to ensure that design-time requirements are also satisfied. Sentinet allows fine-grained control of the services publishing aspects. Any service interface, operation or endpoint can be disabled from publishing and will not appear in the service WSDL. In the example above we can disable publishing old operations and keep only new operations published, so that when developer requests WSDL from Sentinet Repository it will be generated only with three new operations. Finally using Sentinet monitoring capabilities administrators can identify that there is no more consumer applications that use older service version, and older version 1 can be removed from the virtual service structure (see X remove button on the screenshot below).
Now only the latest Version2 is available at run-time.
Multiple Interfaces Scenario
In this scenario a business service is developed and deployed in its first version, and then virtualized through the Sentinet virtual service. Both virtual and business services actively process business transactions. At some later point a new version is developed.
Requirements
- New service version has to be made available along with the older version (meaning both business service versions have to be operationally available at least for some period of time).
- Existing single virtual service has to be able to support both business service versions side-by-side.
- Existing consumer applications have to be able to continue using existing version, while new consumer applications have to know about and use only new service version.
- Existing consumer applications have to be provided with the knowledge on the new service version and have to be given enough time and means to migrate to the new service version.
- Older service version and new service version will be available through different consumer-facing endpoint.
- Service version upgrade process must be operationally non-interruptive.
Solution
The solution is to create the second virtual interface within the existing virtual service, where each interface is now dedicated to its own business service version.
Note that this time virtual service gets a new interface and a new endpoint. Messages sent to the old endpoint will be routed to the old service version, messages sent to the new endpoint will be routed to the new service version. Old interface can be entirely disabled for metadata publishing and will not show up in the service WSDL.
Multiple Virtual Services Scenario
In this scenario a business service is developed and deployed in its first version, and then virtualized through the Sentinet virtual service. Both virtual and business services actively process business transactions. At some later point a new version is developed. Requirements are all the same as in the previous scenarios except that a new virtual service has to be created and dedicated for the new business service version. This scenario effectively provides two different virtual services where each virtual service virtualizes its own business service version. Sentinet users can disable publishing of the whole older service version, making only new virtual service version visible to consumer applications.
Security Policies Versioning
A new service version may also include requirements for new security policies. Existing virtual service structure can be modified to include new virtual endpoint that requires new security policies. In this case new consumer applications have to use new endpoint, while existing consumer applications can continue to use older endpoint. Older operations and older endpoint can be disabled from publishing in the virtual service WSDL.
Older virtual endpoint can be deleted once Sentinet administrators identify that nobody uses virtual service through this endpoint and keep only newEndpoint available.
Transport and Communication Protocols Versioning
A new service version may also include requirements for new transport communication protocols. Exactly like with Security Policies versioning case, an existing virtual service structure can be modified to include new virtual service endpoint that requires new transport and communication protocols.