We previously introduced the OASIS Reference Model (RM) for SOA as an abstract framework for understanding significant relationships among the entities in a service oriented environment. This article explores how to use the model during the architectural process.

	express delivery
	• print  • comment
	Architects will want to ensure that their concrete architecture has a physical manifestation of each of the elements represented in the abstract model. Duane Nickull is senior standards strategist, Adobe Systems, and chair of the OASIS Service Oriented Architecture Reference Model Technical Committee (SOA-RM TC). He is also vice-chair of UN/CEFACT and was a co-editor of ebXML. Edited by Ken Laskey, lead engineer for The MITRE Corporation, and Matt McKenzie, software development manager at Adobe, this is the second in a series of four articles. Download a PDF version (144k), complete with diagrams.
	Glossary terms: SOA, registry, SOAP, OASIS, W3C, lookup tool Sponsored links: your text link here

The reference model itself consists of a minimal set of unifying concepts, axioms and relationships — independent of specific standards, technologies, implementations, or other concrete details. Concrete architecture built using this reference model will likely introduce additional elements such as security, management, service composition and more. In fact, it is envisioned that architects may use several reference models for a specific architecture including network models such as the OSI 7 layer stack, and others.

When building a specific architecture, architects must consider related work items such as specifications, profiles, protocols and standards. This is the bridge between the abstract model and real-world standards such as web services, W3C recommendations et al. The gist is that architects will want to ensure that their concrete architecture has a physical manifestation of each of the elements represented in the abstract model. The manifestations may be realized using the related work items. This separation of the reference model from the underlying implementation enables the concepts as described to remain useful as future implementation mechanisms are developed. (Readers should note that not having at least one of each reference model concept does not mean your architecture is not "service oriented." However it may not be labeled as conformant to the reference model as per the requirements for such outlined within the current draft.)

The length of this article is not sufficient to illustrate concrete examples for each element of the reference model, but an example will be given that illustrates a smaller subset and discusses how architects may account for those.

The current draft of the Reference Model introduces conceptual elements of the model for a service, along with visibility, interaction, service description, real world effect and the execution context. We will illustrate how architects may wish to use this model to construct their service architecture. Let's take a look at "Visibility" as a concept.

Service visibility

For a service provider and consumer to interact with each other they have to be able to 'see' each other. This is, in fact, true for any consumer/provider relationship — including in an application program where one program calls another: without the proper libraries being present the function call cannot complete. In the case of SOA, visibility needs to be emphasized because it is not necessarily obvious how service participants can see each other.

An architect who will place several services in their architecture will need to consider who will be using the services and how they will be able to find and bind to the services. Some of the aspects of this will be handled by the underlying transport or perhaps out of band. Other aspects may be best served by the architect using a service registry as a persistent, architecturally neutral third party that holds the required information and can dispense it to the service consumers. Some possible mechanisms include UDDI or a custom built service registry. This would allow each service provider to place details of their service into the service registry, along with useful information that the service consumer would require to interact with the service. Some examples of this may be the unique network location of the service, the protocol used to bind to it (possibly SOAP), any available supplemental behavior that is available to the service consumer to invoke such as security protocols, reliable messaging protocols or even transactional behavior such as the interaction model for the service.

On the Internet, some of this is done via search engines. A search engine allows an individual website to be visible to entities who may wish to view it using their browser. In this case, the service consumers would find all they require to bind to the website via the search engine — including the unique address, the protocol used and some additional claims made by the website such as what it is about. Note that here we have described one possible set of implementation choices but many others are possible as long as those chosen enable a functioning SOA.

Model conformance

When the Reference Model for SOA becomes a final standard, architects may wish to declare their architecture is conformant with this reference model. Conforming to a reference model is not generally an easily automatable task — given that the reference model's role is primarily to define concepts that are important to SOA rather than to give guidelines for implementing systems.

Individual service oriented architectures may reference the concepts outlined in this specification. The authors expect that any design for a system that adopts the SOA approach will:

1. Have entities that can be identified as services as defined by this Reference Model
2. Be able to identify how visibility is established between service providers and consumers
3. Be able to identify how interaction is mediated
4. Be able to identify how the effect of using services is understood
5. Have descriptions associated with services
6. Be able to identify the execution context required to support interaction
7. Make it possible to identify how policies are handled and how contracts may be modeled and enforced

It is not appropriate for this specification to identify best practices with respect to building SOA based systems. However, the ease with which the above elements can be identified within a given SOA-based system could have significant impact on the scalability, maintainability and ease of use of the system.

More on this topic