Software as a Service: A pattern for modern computing

Understanding Service Oriented Architecture

Since SaaS is built upon services, understanding SaaS depends on understanding Service Oriented Architecture (SOA) first. According to the OASIS Reference Model for Service Oriented Architecture, SOA is an architectural paradigm and discipline that may be used to build infrastructures enabling those with needs (consumers) and those with capabilities (providers) to interact via services across disparate domains of technology and ownership. (Service Oriented Architecture is an architectural paradigm expressed as a reference model by OASIS.) Services act as the core facilitator of electronic data interchange, but they require additional mechanisms (such as service descriptions, policies, and so on) in order to function. Several new trends in the computer industry rely upon SOA as the enabling foundation. These include the automation of Business Process Management (BPM), composite applications (applications that aggregate multiple services), and the multitude of new architecture and design patterns (including Mashups and SaaS) collectively referred to as Web 2.0. ( Web 2.0 is defined as a set of design patterns in the O'Reilly Media book "Web 2.0 Architectures: What Entrepreneurs and information architects need to know").

OASIS defines the pattern of SOA as a reference model, an abstraction that may be used to capture the core concepts within a service oriented environment and the relationships amongst them. The view of architecture starts with a service and its relationship to other core aspects that architects, software developers, and others will need to consider when building or understanding service oriented systems.

In SOA, services have accompanying service descriptions that convey details about how to consume services and the real world effects of consuming the service. These descriptions must additionally convey both semantics (pragmatics) and syntax for both humans and applica­tions to use. Within the context of SaaS, consumers of such services must be able to fully understand several aspects of the service before invoking it. This differs from virtualization (also referred to as "cloud computing") where the consumer is not necessarily aware that their computing resources are remote and abstract and where logical and physical maps of network topology may diverge.

Figure 1: The core reference model for Service Oriented Architecture (Courtesy of OASIS)

According to the OASIS reference model, each service has an interaction model, which includes the externally visible aspects of invoking a service. Most service interaction patterns are modeled off a simplistic request-response invocation paradigm, although other patterns of interaction are equally plausible.

Visibility and real world effect are also key concepts for SOA (see Figure 1). Visibility is the capacity for those with needs and those with capabilities to see and interact with each other. This is typically implemented by using a common set of protocols, standards, and technologies across service providers and service consumers. For consumers to determine if they can interact with a specific service, service descriptions provide declarations of aspects such as functions and technical requirements, related constraints and policies, and mechanisms for access or response. The descriptions must be in a form (or can be transformed to a form) in which their syntax and semantics are widely accessible and understandable. The execution context is the set of specific circumstances surrounding any given interaction with a service and may affect how the service is consumed.

Since SOA permits service providers and consumers to interact, it also provides a decision point for any policies and contracts that may be in force. The purpose of using a capability is to realize one or more real world effects. At its core, an interaction is "an act" as opposed to "an object" and the result of an interaction is an effect (or a set/series of effects). Real world effects are, then, couched in terms of changes to a shared state. This ability to change the shared state of data is essential to effective SaaS applications.

The concept of policy also applies to data represented as documents. Further, policies must persist to protect such data far beyond enterprise walls. Specifically, policies must be linked with the data or functionality (software) that is involved with services, wherever they persist. A contract is formed when at least one other party to a service oriented interaction adheres to the policies of another. Service contracts may be either short-lived or long-lived. In SaaS terms, a service contract may be an ongoing relationship in which certain functionality will be provided whenever the consumer (SaaS user) requires it.

SaaS, however, is more than just SOA delivering functionality. It's important to understand another related pattern, the Model-View-Controller (MVC) pattern, before diving into the SaaS pattern itself.

Page 2 of 7

Previous Page

Next Page