This article (the last of four articles) circles back to the SOA Reference Model. It describes how to implement against each part of the model. Though the model concepts are abstract, this article delves into actual architecture and describes a real-world implementation of each component.

Some important milestones have been met while writing these articles. First, the Reference Model (RM) for SOA is now an official Committee Specification at OASIS. This is a special designation marking a significant achievement on its way to becoming a recognized and tested industry standard. It is currently en route to becoming a full OASIS specification per the OASIS rules and procedures. A second important milestone is the creation of the Reference Architecture (RA) subcommittee within the technical committee (TC). The RA is focused on a reference architecture that uses the RM as a guide, similar to this article.

During the architectural process, reference models are used to guide architects in the development of their architecture. The model has concepts on it that require implementation in the real world. While discussing the implementations of the model's concepts and components is outside of the scope of this article (and is within the scope of the RA SC), I will discuss a few of the high-level components and their real-world counterparts.

To accomplish this task, I would like to reference a graphic from the official RM committee specification (see Figure 1).

Figure 1. Principal concepts in the Reference Model

Let's take the service. A service is a mechanism which facilitates access to some core functionality. Since one of the main business drivers is the ability to repurpose the functionality across multiple consumers, implementing a service using a "lowest common denominator" approach probably has merit, with respect to standards and protocols. For example, implementing the service using a proprietary C++ interface will probably not scale too well if potential consumers are located on a different machine across a network. A better solution would be to opt for one technology family to use across all consumers and providers of services and use those tools for implementation.

By far, the most common is the "web services" set of standards and protocols. Most common of these (I am guessing here, based on my personal experience) is to use some form of SOAP to allow a consumer to bind to a service and XML schema to define the actual constraints for passing parameters in and out of a service. The combination of these two has many advantages over other technologies. To name a few: both are platform- and OS-agnostic, both have plenty of open source tools to work with or implement, both are industry standards by convention, design, and the aforementioned qualities.

In order for a service to be used, it must first be located and then be described in terms that a consumer can understand. For the "Service Description" component of the Reference Model, the Web Services Description Language (WSDL) is an ideal mechanism, especially if you use the Simple Object Access Protocol (SOAP) and the Extensible Markup Language (XML) for the service. It is a W3C standard, well documented, and widely implemented.

In order for an interaction to happen with a service, there must be a manner in which consumers can signal the service to invoke it. Another common implementation of this aspect of the model is the Internet (TCP/IP)—specifically HTTP as a protocol for communication. Note that SOAP can be implemented over HTTP (as is quite common), yet is not in any way dependent upon HTTP. In fact, SOAP can also be used over User Datagram Protocol (UDP). Just having a domain address will also require you to use the domain name services to reference the actual IP address of a service.

The visibility is implemented using a combination of these concepts. In order for a service to be visible to a potential consumer, there must be a path to where it persists or at least an alias layer or proxy. For most consumers, simply being able to see the service alone will not be sufficient. Consumers also require some form of description of the service and what its "real-world effect" will be if invoked. This is to aid in deciding whether or not to try to invoke the service.

Additionally, metadata registries are being successfully used as a mechanism to facilitate discovery of a service. There are multiple standards for both registries and directories that can point at services and use some form of taxonomy or ontology to classify them based on their owners, function, or any number of other properties. As such, sharing semantics seems to be intuitively an important part of service discovery and visibility. Some form of shared vocabulary should be present to help aid consumers in making decisions about service invocation.

Some platform companies like Adobe have implemented the SOA Reference Model within their offerings. For example, a shared registry within the Adobe LiveCycle platform is a single point of reference for all services present in the platform. Service providers make references in the registry about what their services provide to help consumers within the platform locate them later on. The Adobe LiveCycle platform also implements the core set of web service standards, knowing full well that consumers will likely be invoking services from beyond the LiveCycle platform. The platform can be extended by providing service connectors using various protocol sets that will make the service's visibility available to other providers on third-party platforms.

While this is the end of the four SOA-related articles, this is in no way the end of my involvement with SOA and the standards around it. Stay tuned to my blog for periodic updates on this topic.

About the author