From SOA to SaaS

"Service-Oriented Architecture" (SOA) and "Software as a Service" (SaaS) are two driving forces in software architectures today. In this article, I explore how to grow a local SOA into a federated SOA distributed over the Web to both use and deliver SaaS. In the process, I examine how "mashups" relate to SOA over the Web and how, if used inappropriately, they may circumvent some of the benefits of SOA and SaaS.

SOA

Service-oriented architecture has established its value in enterprise systems as an architecture for integration, consolidation, and reuse. This has provided a path to integrate and consolidate legacy systems onto a consistent platform for growth and agility going forward. The building blocks of the SOA are services that all adhere to the pattern in Figure 1.

Figure 1: Service pattern.

Ensuring that services adhere to a strict pattern and set of access protocols enables growth in the numbers of services in an SOA without increasing its complexity. This in turn has improved reuse, reduced redundancy, and improved maintainability and flexibility of such systems.

One key aspect of an SOA is that all clients are thin in that they contain no business logic. Rather, business logic is located in services where it can be reused across many different types of clients ranging from web browser UI clients, to IVR clients, to system-level B2B external component-type clients.

Services in an SOA may be accessed using a variety of protocols. For the purpose of this discussion, I focus on web services where clients connect with services using SOAP/HTTP and the interfaces of our services are specified using Web Services Description Language (WSDL).

WSDL is agnostic of implementation language. In the SOA example I present here, the service implementation is in .NET C#.

[Click image to view at full size]

Figure 2: Application architecture.

Figure 2 shows an overview of the application architecture of my SOA example. The Mapping Service is responsible for providing mapping-related services, including geolocation to lookup a latitude/longitude for an address. The following code, from MappingService.asmx.cs (available at http://www.ddj.com/code/), illustrates this:

public LatitudeLongitudePoint geocode( 
  string street, string city,
    string state, 
      string zip, string country ) 

The Address Service is responsible for managing addresses, and provides methods such as add, which may be used to add a new address (see AddressService.asmx.cs):

public Address add( Address address )

In the process of adding, the address geolocation is done to assign a latitude/longitude to the address. The Address Service depends on the Mapping Service for this geolocation as in Figure 2, and as shown by the following code (see AddressService.asmx.cs) from the implementation of the add method in the Address Service:

LatitudeLongitudePoint point = 
  new MappingService().geocode( 
    address.Street, address.City, 
      address.State, address.Zipcode, 
        address.Country );
address.Latitude = point.Latitude;
address.Longitude = point.Longitude;

The Add Address ASP Web Page is responsible for enabling users to enter new addresses, and then add them. Once the address is added, the latitude/longitude coordinates associated with the address are displayed.