Service Interface Design
You may wonder why we don't just call out to the remote geocoding service from the Address Service. This is because in creating your SOA, you need to decompose groups of functionality into services. Embedding mapping functionality inside an Address Service makes it less accessible and reusable by other clients. Having a separate Mapping Service enables you to reuse just the mapping capabilities directly. For example, if you wanted to create a map and use geocoding without a full address, you could use your separate Mapping Service directly. Learning how to break down groups of related services for reusability is more of an art than a science, and one that senior architects should play a key role in.
It is also important to design the interfaces of services well so that they don't expose the specifics of their current implementation. For example, even though the Mapping Service used a local third-party mapping product initially, I didn't expose any specific details of that third-party product through the Mapping Service interface. This let me later change the Mapping Service implementation to deliver its service by delegating to some other API such as Yahoo Maps, without having to change the WSDL interface of the Mapping Service.
Good service interface design makes all the difference between technical service plugability and practical service plugability. Remember that you can't change your service interface later without forcing a rewrite of clients of that service, which is something you want to avoid by paying careful attention up front to service decomposition and interface design.
Tracking Best of Breed
The other reason you have a separate Mapping Service rather than call out to the remote service from all over your architecture is to localize or isolate dependency on the remote service for agility. Consider a scenario where the Mapping Service proves useful and several clients in the architecture grow to depend on it. To deliver the best service to these clients, over time you want to track the "best of breed" mapping SaaS available. Today, perhaps Yahoo Maps fills this need. However, perhaps in a year, Google Maps comes out with a much better mapping service that we want to use. If you made the mistake of connecting from several points in your architecture directly to the Yahoo Maps API, then later to change to Google would require a "pervasive" rewrite where you have to touch the code in many places to make this change—a risky and cumbersome task.
Rather, by isolating the dependency on Yahoo Maps API behind the Mapping Service interface, you are able to change over to Google Maps with only a simple local change to the implementation of the Mapping Service, avoiding any code changes to the clients of the Mapping Service. This lets you make architectural changes quickly to track best-of-breed SaaS providers, easily and with minimal risk, making the architecture more flexible and business that depends on it more agile.
