By Jeff Hanson and Ryan Ireland

One of the major benefits provided by a service oriented architecture (SOA) is the decoupling of the client requesting the service and the service itself. Through a registration and discovery mechanism, the SOA provides location transparency, which allows clients to not know (or care) about where a component or service is actually located. Let’s take a look at some of the advantages and disadvantages of location transparency.

Find out more about decoupling

To find out more about the benefits of decoupled systems, check out “Take advantage of the benefits of loosely coupled Web services.”

Location transparency means virtual platforms
A service is generally registered with a public or private registry, such as a database, a directory service, a UDDI registry, or an XML file. Once a service is registered, components that want to call the service may use the registry to locate and then call the service. The registration and discovery of the service are enabled through the SOA platform in a manner that releases the service from needing to know where or how it has been deployed.

This registration and discovery mechanism allows the location of a component or service to be unknown (or transparent) to the developer. In this way, a virtual platform in which all components or services seem to reside within the same machine or programming space is created, as illustrated in Figure A.

Figure A
Location transparency creates a virtual computing platform.

The virtual platform illusion allows you to access both local and remote services using identical calls, an ability known as transparent access. To do this, references to services should be made abstractly, such as by using SOAP/HTTP. For example, the following SOAP envelope is passed as the reference information, providing the service name, operation name, and parameters for a stock quote service:
<?xml version=”1.0″?>
  <soap:Body xmlns:m=””>
    </m:GetStockQuote >


Because location transparency deals with information objects being accessed without knowledge of their location, the actual locations of services should be specified in configuration mediums, such as UDDI registries. In addition, service calls should be targeted at common location endpoints, such as URLs and URIs. For example, the following URL endpoint is specified to call our stock quote service:

Development advantages
One of the primary benefits of service location transparency is the elimination of location as a concern for the developer. As a developer, instead of worrying during development about the location and access details of a service, you’re free to focus on solving business domain problems. An SOA framework or platform should handle all of the registration and discovery work required to use a service.

Another advantage for location-transparent services would be that there is no need to overlap development processes. In other words, design issues are dealt with at design time, development issues at development time, and deployment issues at deployment time. The location of a service should be a deployment decision.

With an SOA framework or platform providing the registry and discovery of a service, the service deployer can determine where each component is physically located and is then free to alter the deployment at a later date. Perhaps initially, the service and the client will be co-located on the same machine. And then, as the need arises, the service could be moved to another machine to provide scalability and redundancy. Simply by changing the deployment information of the service, the service can now be found at its new location without rewriting any service or client code.

Another example might be an application that must guarantee a certain level of performance for premium users while providing the same functionality but at a reduced performance rate for others. This kind of functionality is easily provided within an SOA environment. Because the service is the same for both users, and the client code requesting the service is the same, the only process involved in the determination of performance rates is the service discovery process. The discovery process locates a service on the fastest machine or cluster available for a premium user and passes the request to the same service located on a slower performing machine or cluster for a regular user.

Not all peaches and cream
While location transparency provides many benefits, it also raises a few issues. These are some of the most prevalent:

  • The application is dependent on the reliability of the network system.
  • More network bandwidth is required because of the high number of messages sent and received.
  • Location logistics must be registered and updated to support service installation and service migration.

However, measures can be taken to deal with each of these issues. For example:

  • Deployment of common failover mechanisms to deal with network instability problems
  • Implementation of message-dispatch optimizations to reduce the amount of message traffic
  • Use of registry technologies, such as UDDI and ebXML, to deal with service migration issues

As I’ve shown, the development process benefits from location transparency from the design phase through the deployment phase. It provides opportunities for code reuse and deployment process enhancements. There are, of course, challenges that arise with location transparency, but with creative use of existing technology, these challenges are not insurmountable.