How can a service be moved without impacting its consumers?
Various logistical circumstances may require a service to be physically relocated, thereby requiring configuration or code changes on the consumer end.
Application and Transport-level redirect features are used to preserve consumer-to-service connectivity.
Redirection logic placed at the original service location either transparently redirects consumer requests or responds to consumers with a notification indicating the new service location. This redirection can be applied at the transport protocol level or at the application protocol level.
Requires additional planning of resource design as well as possible impact to the intermediaries - proxies, network devices etc.
PrinciplesService Loose Coupling
ContributorsRaj Balasubramanian, Jim Webber, Thomas Erl, David Booth
There are numerous reasons as to why a service may need to be relocated:
- IT departments may be subject to restructuring due to corporate acquisitions or company-wide re-organizations.
- Infrastructure may need to be scaled requiring the introduction of new servers and the redistribution of previously deployed services.
- New security requirements may demand that a service be isolated or relocated to a different enterprise domain.
Any one of these situations can necessitate that a service be assigned a new physical address. For services with multiple consumers, this can lead to a ripple effect whereby consumer programs designed to communicate to the original physical address will encounter runtime failure. To avoid this scenario, all consumers must be redesigned with the new address, which may also be impractical, depending on how urgent the service relocation is and how many consumers are affected.
There are two ways to address the problem:
- Redirection at the Transport Protocol Layer - This approach ensures the redirection occurs at the network transport protocol (TCP) layer and addressed by use of network devices.
- Redirection at the Application Protocol Layer - This approach ensures the redirection occurs at the application transport protocol (HTTP) layer and addressed by use of application proxies and intermediaries.
In addition to the above approaches, there can be two types of service relocation.
- Transparent Relocation - This approach ensures that the consumer is unaware of the change and that all service interaction proceeds normally.
- Relocation with Referrals - A mechanism residing at the service's original location responds to consumer requests with an appropriate code indicating the new service location.
With transparent relocation, consumers are not required to change. With referral-based relocation, consumers must be able to accept and process the relocation response.
Transparent relocation is typically achieved by the application of Intermediate Routing together with specialized redirection logic or by using core networking services (such as DNS). This redirection can be implemented at the transport or application protocol layer. At the transport protocol layer, network appliances are used. This can be applied to both HTTP based REST services as well as SOAP based web services. HTTP specification offers guidance on accomplishing the redirects as indicated below. This is leveraged fully in REST services. For SOAP based services, there are additional intermediaries in the form of middleware environments, such as the Enterprise Service Bus, to accomplish routing functionality.
Implementing relocation by referral can also be achieved via intermediate routing logic, but is more commonly built at the application protocol layer. HTTP specification offers guidance on accomplishing the redirects as indicated below. This is leveraged fully in REST services.
The HTTP specification contains several provisions that address temporary move and permanent moves, primarily due to its origins in Web publishing. Some of the more relevant HTTP codes that are associated with the header fields in the HTTP response include:
- 301 Moved Permanently
- 302 Found
- 303 See Other
- 307 Temporary Redirect
The modified address or the older address of the service is specified in the Location field in the response header. Additional information can be provided in the response body.
For example, let's say the consumer sent a request message with the following HTTP header:
GET /services/customer_listing HTTP/1.1 Host: myserver1
If the service was permanently moved from one physical server to another, this request message may be responded to with a message such as this:
HTTP/1.1 301 moved permanently Location: http://myserver2/services/customer_listing Content-type: application/xml Content-length: 120
<?xml version="1.0"?> <resource_move name="Customer Listing"> <new> <a href=http://myserver2/services/customer_listing/> </new> <old> <a href=http://myserver1/services/customer_listing/> </old> </resource_move>
Upon receiving this response the consumer must be able to follow the updated URL form the Location field.
When following the transparent relocation approach, it may be tempting to never update consumers because service interaction continues to occur as it always has. For anything that requires more than changes at the networking (DNS) level, this pattern can lead to the need for middleware or network appliances and can further compound governance efforts required to keep track of all of the old and updated locations that need to be continually maintained.
The relocation by referral method either requires that consumers undergo a change to incorporate the new service location or that they be designed to receive the response codes containing the relocation information. Either way, this will impact consumer programs that were not designed for this type of response.
Note: Due to the HTTP-centric nature of REST-based implementations, consumers of REST services may naturally contain the processing logic required to accept HTTP response codes.
Case Study Example
Alleywood architects are looking at revamping their Customer Listing service in preparation for a soon-to-be-implemented data center platform. Additionally, some of Alleywood's IT departments have been transferred to a new subsidiary that has been recently created. Both of these circumstances require that previously implemented services need to be moved.
The IT team responsible for the moves must address the impacts from the physical server, as well as the separation of the underlying business entities. The team has been told by management that the new subsidiary will be called "Alleywood Specialties" with exclusive support for large contractors from the parent Alleywood Lumber Company. Hence, the customer database will be separated and any calls to clients of Alleywood Specialties must point to Alleywood Specialties systems.
The design team comes up with the following strategy:
- All calls going to the older data center will be redirected to the new data center using network level changes. This requires adding policies on the routers, updating the DNS servers to reflect the new IP addresses of the server locations, as well as changes to firewall policies.
- All calls specific to the affected business entities will be addressed with the HTTP 301 response code, which will be part of a message that also includes the new location of the service.