SaaS
Software as a Service has established itself on the Web through the provision of APIs; for example, Yahoo Maps (developer.yahoo.com/maps). Here, I focus on SaaS delivered as an API, accessible remotely over the Web at a system level where the consumer is a nonvisual system component. SaaS has enabled new systems to focus on their core value add, while essentially outsourcing supporting services.
This in turn has yielded benefits, including speeding time-to-market and reduced licensing, maintenance, and administration costs.
In an Enterprise SOA, where all services are implemented locally and none are outsourced over the Web, implementations are full in the sense that they contain all business logic, or may be adapters that can delegate to a local third-party framework, library, or product. For example, in a local enterprise architecture, the Mapping Service implementation may simply delegate to some third-party product also running locally. (To see a list of such products, search the Web for "geocoding software products".)
The Convergence of SOA and SaaS
Fortunately, the service interface/implementation pattern in Figure 1 enables a convenient architectural path to align these two powerful trends and leverage their synergies.
As more services become available over the Web as part of the SaaS trend, service implementations can change so that instead of implementing all logic by themselves or delegating to some local third-party product, they instead delegate to some remote service delivered by some third party.
For example, Yahoo Maps includes an API that you can use to geocode an address (developer.yahoo.com/maps/rest/V1/geocode.html). To make use of this geocoding service, you can simply switch the implementation of your Mapping Service and change the geocode method to delegate to the Yahoo geocode web service instead of processing such requests in our local system (see MappingService.asmx.cs):
XmlSerializer xs =
new XmlSerializer(typeof
( ResultSet ) );
WebRequest request =
WebRequest.Create( uri );
WebResponse response =
request.GetResponse();
ResultType result =
( (ResultSet) xs.Deserialize
( response.GetResponseStream()
) ).Result[ 0 ];
point =
new LatitudeLongitudePoint
(Double.Parse
( result.Latitude.ToString() ),
Double.Parse
( result.Longitude.ToString() ) );
This change to your implementation from using a local geocoder to using the remote Yahoo Maps API does not change the WSDL interface for the Mapping Service, so there is no impact to any of our service clients through this change. This agility afforded by the simple service pattern is extremely important as it enables us to make localized changes to services without changes to the service interface and (more importantly) without causing pervasive rewrites of clients, which are risky and costly.
It is important in an SOA to have a uniform set of protocols for accessing services to improve their ease of use and minimize the complexity of service clients, as well as enable the SOA to grow without adding a lot of complexity due to different access protocols. In my SOA example, all services are accessed using web services with SOAP/HTTP(S). However, note that in the Mapping Service geocode method implementation, I use the Yahoo Maps API with an XML/HTTP REST ("REpresentational State Transfer") protocol. In this way, implementations of my services that delegate out to remote services perform a "glue" function in making remote services with diverse APIs and access protocols accessible locally through a set of services that may all be accessed more easily and uniformly using the same protocol.
