'Enterprise' 101 - Location Transparency

Let's say you wrote a nice service, something like getHello(), and put it on a server. Now you want to write your client and use it to invoke your service. If you're following most development cookbooks, you're writing some code like this:




public class TestClient {
public static void main(String [] args) {
try {
String endpoint =
"http://ws.apache.org:5049/axis/services/echo";

Service service = new Service();
Call call = (Call) service.createCall();

call.setTargetEndpointAddress( new java.net.URL(endpoint) );
call.setOperationName(new QName("http://soapinterop.org/", echoString"));

String ret = (String) call.invoke( new Object[] { "Hello!" } );


So what's wrong with that, you ask? Your code is going to work-- your client will be able to call the server. But you're missing an important ingredient-- Location Transparency.

The client code you see above is less than Enterprise-worthy because the service endpoint is embedded directly in the client source code. What happens when the server has a hardware failure and needs to be replaced? Your client code will be irreversably broken and will need to be recompiled. Also, you are confined to hitting one service from your client-- if the server becomes a bottleneck, you don't have a good way to scale out.

Location Transparency-- the Registry solution

One solution to the Location Transparency problem is to use a registry to find your server. The registry is a well-known place where servers are registered and clients go to ask locations of servers. UDDI is the 'spec' answer for web services, though it hasn't worked out as well as the spec writers probably would have liked. Today there are other web service-centric registries that serve the same purpose as UDDI, but offer 'value adds' from the implementors. In the CORBA world, you might use a 'Name Service' to act as your registry. Still others might code their own registry using a database or some other CRUD data store.




Here are some pros and cons of a registry solution:

Registry Pros
- Allows loose coupling between client and server
- Can be implemented in a way that lets the client 'discover' services based on attributes like method arguments

Registry Cons
- Does not take into account servers that crash. If a server is registered then crashes, the registry will still steer clients toward the dead machine.
- Does not make a provision for load balancing. A registry isn't usually charged with telling a client which like-typed server to run against-- it just provides a list of the servers.

Niceties
- If you can code your services to self-register with the registry when they start, that's a good thing. Your operational admins probably have better things to do then key new services into the registry.
- You'll also want the services to self-unregister when they come down gracefully. Note that this doesn't help a crashed server, though.

There are other ways to address the Location Transparency problem, though-- through Messaging and through a Load Balancer are a couple of good ones. But those are posts for another day.

'Till then,

Happy Coding!