Web Services Migration

Web services migration is the next phase of versioning to explore, given that the Version One and Version Two services have been built and deployed on the network (described elsewhere in the Mission Critical Software: Namespace Versioning tutorial). In this next tutorial, two tools -- the registry and the Web service management intermediary -- will be examined in detail in the context of a multi-part Web services migration case study.

For simplicity's sake, let us assume that we're using open content models. So the interfaces are fully backward compatible. However, we're going to bring up the second version of our service separately from our old version. So we must have our existing service up and running when we bring the second version online.

Web Services Migration Example 1: Change Endpoint in Registry

A key question as we migrate consumers from Version One to Version Two of the service is: what's their tolerance for downtime? How long can the service be down without causing a problem for these consumers? For explanatory purposes, we will depict an ordering service and simply assume that it has only two operations associated with it: (creating) or changing orders -- and then querying to look up existing orders.

Starting point for Web services migration example

Starting point for Web services migration example

One of the first approaches many people think about when versioning a service is to use a registry; this approach is understandably popular. Essentially, when Version Two comes online, a new endpoint is put in the registry, so all the consumers are made aware of it; when they start to access services they look in the registry, locate the endpoints, and then access the endpoint for the new service. The registry, therefore, can be a simple way to migrate load over from Version One to Version Two.

Web services migration example #1: Change ordering endpoint in registry to Version 2

There are a couple of challenges with this approach though.

  • UDDI consumers cache end points until they can no longer reach the existing end point: The UDDI standard, which is one of the key registry standards, essentially states that consumers should cache endpoints until they can no longer reach the ("old") endpoint. So essentially, the consumer looks up the endpoint once continues to use that endpoint until errors come back. -- Which is just one of the things defined in the UDDI specification designed to avoid overloading the registry.
  • When is the right time to migrate order records to Version 2? In this scenario, ultimately, the service has to be brought offline to do the data migration -- because these services have data that reside "behind" them (see diagram below), and that data needs to be moved from the [domain] of Version One to Version Two -- not have it corrupted in the process.

So how to make data migration more effective? With the (somewhat inflexible) model above, the only alternative is to bring Version One offline so no consumers can access it, migrate the data, and then bring up Version Two. It's true that this approach solves the problem of registry caching -- because the consumers will know that they can't contact Version One. And then as soon as Version Two becomes available, the consumers will go and all start connecting to it ...

Web Services Migration Secrets

Register to watch the On-Demand Webinar, "Web Services Versioning Made Simple", now.

Note: The items in BOLD are required fields. You must supply a valid email address to complete the registration.


First Name
Last Name
Company
Title
Job Category
Industry
Email
Telephone
Address 1
Address 2
City
Country
State/Prov
Postal Code

Web Services Migration and Load Spikes

But this process has a secondary effect in the case of heavily used services. As a heavily used (second version of a) service comes online, the consumers will often start pulling load onto the new version as it becomes available. This can lead to troublesome load spikes on start-up: so it's important to ramp up service load gradually instead. Thus, this model may cause some problems in certain environments. It is most suitable in environments where a reasonable amount of downtime is acceptable.

A final word on downtime and migration: whether it's two hours, four hours or a day, one has to be able to judge whether it's an acceptable amount of downtime for the organization. Secondly, in this model, one has to be able to live with the nondeterministic rollover of consumers. Because if consumers have cached addresses, the organization may be presented with the issue of how to know exactly when those consumers are going to move to Version Two. And then, of course, load spikes are the other issue (which will be addressed in more detail below).

Web Service Migration Example 2: Phase Load Transfer with WSM Intermediary

The next versioning example takes the discussion up a notch -- and involves a service whose consumers have even less tolerance for downtime: a scenario in which the service can't be brought down for significant amounts of time at all. Fortunately there is another approach that can be employed, using a Web service management intermediary (see diagram below).

In the first example, essentially all the requests were going to the Version One service. Here, in Step 1, the Web service management intermediary is initially configured to start rejecting all change service requests. What that means is the data won't be allowed to change; the migration task thus becomes simpler. All queries can still be allowed to pass through to service Version One because Version One has a full copy of all of the data. So queries can still successfully go through and the organization will at least have some level of uptime and availability associated with the service -- even during the migration of the data. In summary, with the rule in force (in the WSM intermediary) that data can't be changed, queries will go forward and succeed, and the data migration can commence.

Web services migration example #2: Use Web service intermediary to phase load transfer

Web services migration example #2: Use Web service intermediary to phase load transfer

Once the data migration is complete (step 2 in the diagram), the Web service management intermediary can, in many cases, automatically update the endpoint (step 3) so that consumers can get to the Version Two service. Finally, the rules in the Web service management intermediary are now changed to direct all change and query operations to Version Two now that all the data are migrated over.

Web Services Migration Example 2: Drawbacks of WSM Intermediary Approach

It is clear how, with this method of versioning migration, no downtime whatsoever applies to query operations, but there is still downtime associated with change operations. And there is a "side effect" of this approach that ought to be mentioned as well.

While there is the additional advantage of fine-grain control (of exactly when consumers are transferred to Version Two -- because the intermediary itself switches its configuration exactly when it is time to roll consumers over), the load-spike issue mentioned above still remains.

Web Services Migration Example 3: Gradually Phase Load Transfer With WSM Intermediary

Let us, therefore, now discuss another variation of this configuration and learn how to get a higher level of availability from it. One of the things about data in systems is that a lot of it is potentially independent of other pieces. This fact presents us with an opportunity with respect to data migration.

In this particular case, we are talking about customer records and order records. And so one of the things we can imagine is a situation in which the data is segmented into variations. For the sake of the example below, let us explicitly segment our customer order records by Customer ID: thus, all customers whose ID number ends in 0 will be separate from those whose ID number ends in 1 -- and so on, all the way up through 9.

Web services migration example #3: Use Web service intermediary to gradually phase load transfer

Web services migration example #3: Use Web service intermediary to gradually phase load transfer

What this approach permits one to do is to consider the migration of each of these bands of customers separately. The customers who have IDs that end in 0 can be migrated before the ones that have IDs that end in 1. Thus, the general approach to the process is that we change the configuration on the Web service management intermediary so that it rejects changes to orders where the Customer ID ends in 0, but it still lets through all queries and all changes to other customer IDs: IDs that end in 1 or 9.

Once that configuration change is made, customer records that have Customer IDs ending in 0 are migrated; this initial migration will thus only encompass (something like) one-tenth of the total orders in the system. Next, change the configuration so that all customers whose ID ends in 0 will be serviced by Version Two. Everyone else, of course, will still be serviced by Version One.

This process can be repeated over and over for all of the other Customer ID groups. Repeat it for Customer IDs ending in 1 through 9 and gradually, approximately one-tenth of the orders at a time will be moved over to Version Two of the ordering service.

Web Services Migration Example 3: Advantages

There are several distinct advantages to the migration approach outlined above:

  • Zero downtime: There is now zero downtime associated with querying as there was in the previous example
  • Change has a narrow (sliding) downtime window: There is downtime associated with the change operation for only one-tenth of the customers at a time, instead for all customers (during the entire period of a data migration.)
  • No data-integrity issues: No possibility of data-integrity problems
  • No load spike: Since approximately one-tenth of customers at a time are being moved to Version Two, this represents a gradual ramping of the load on the second version of the service

Web Services Migration: Summary

There's no perfect migration strategy; IT will instead need to choose from among the approaches presented above:

  • A registry-centered approach
  • An approach that phases the load transfer, or
  • An approach that moves data over sequentially in order to gradually phase the load transfer

For any individual service, IT will need to choose from among the three different migration approaches, based on criteria like:

  • How mission critical is the service?
  • How geographically dispersed are the consumers?
  • Is there a window of usable downtime, perhaps at midnight on Sundays? Or not

IT will have to make these judgments on a service-by-service basis.

For More Information

Web services migration is just a part of what you need to know about versioning your services. Learn the rest: download the free webinar, SOA Versioning Made Simple