While many architectures are aimed at the application to application space, eventually interactions with humans must transpire. In the first article in this series, we introduced the OASIS Reference Model (RM) for SOA as an abstract framework for understanding significant relationships among the entities in a service oriented environment. The second article explored using the model during the architectural process. This time, we cover the role of the 'human element' inherent in an SOA.

	express delivery
	• print  • comment
	One could state that humans are not directly part of SOA any more than business process is; however both business processes and humans utilize the SOA infrastructure. 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. This is the third in a series of four articles. Download a PDF version (139k), complete with diagrams.
	Glossary terms: SOA, RIA, MVC, AJAX, client-server, lookup tool Sponsored links: your text link here

Service oriented architecture (SOA) is an architectural paradigm and solution to the problem of connecting capabilities and requirements via the action boundary called the 'service'. One of the core tenets of this interaction is 'managed transparency', an act by which the consumer of a service should not care how the service is performed, but only that it is performed, and from the service provider's side, only that a request has been issued and a result has been communicated back to the consumer. The service itself does not (and should not) really care about anything that exists above the consumer in the service stack since it cannot see why the service is being used.

The common convention for interpreting architectural 'stack' diagrams is that each layer of a stack can see only itself (N) and the layers immediately above (N+1) and below (N-1). If you draw a stack in which the service consumer is the layer above (N+1), you can see that a service (N) should not care what it is consumed for (N+2). A service itself is blind to the fact that it is being used as part of a process or is being called on for something else. Of course, there may be exceptions to this where an architect has a good reason for creating such a dependency, but in general the axiom is accepted. In the exception (ie, making a service mindful of some state that exists above the service consumer), dependencies of this nature make it more difficult to change infrastructure later since they must be carefully analyzed before any proposed change is made.

Since human beings live in the world above the service consumer, the service itself will not necessarily care or be aware that a human is there. It is highly likely however, that humans are part of a service call and exist as either the trigger of some event that results in a service call and/or are the ultimate consumers of the service result themselves. While contradictory to the title of this article, one could state that humans are not directly part of SOA any more than business process is; however both business processes and humans utilize the SOA infrastructure.

Client-side containers

To enable such interactions, architects should take great care to abstract any details of the service itself away from the human. The human should view the "V" (view) component of MVC and not care about the C (controller) or M (model) components. Accordingly, architects need a mechanism to present consistent views to the human that are abstract of any dependency upon the service.

One of the most popular ways to do this is to use a container on the client side for all interactions with the consumer. This is not new thinking, as client-server architecture has used this for a long time. Commodities such as web browsers have become commonplace for interactions with multiple services. The model is easy to understand when the ratio is one human consumer to one service, however as IT infrastructure changes over time, a single service may be divided into multiple endpoints that all must be interacted with to provide the human being the ultimate end result. Popular patterns include client-server and Rich Internet Applications (RIAs).

Client server is a simple two-tier architecture that incorporates the final view into the client component. There are variations of this model. The first is the 'thin' client whereby the server contains the processing (control) components while the client tier merely presents the end result to the human with minimal processing. The human interacts only with the client tier and has no connection directly with the server tiers.

Rich client interaction

Alternatively, clients can incorporate some moderate processing themselves by using JavaScript or other scripting languages to manipulate objects on the client. Two new variations of rich-client interaction models with services are AJAX (Asynchronous JavaScript and XML) and Adobe Flex. Both use a container for presenting the human the final view of their interaction with the service but use complex processing and communication techniques to maintain state with multiple services in the back end. In both cases, Flex and AJAX embody MVC and use a controller on both the server and the client.

The use of this paradigm can enable rich internet applications to be developed that interact with multiple back end services. A Flex or AJAX application may communicate directly with multiple services then abstract all the complexity of SOA and present the view and some control components to the human being above the client side.

Several examples of RIAs interacting between humans and services can be seen all over the Internet. Some applications like Apple's iTunes have viewer panes which are generated locally on the client machine (such as the user's music library). When the user switches panes to view the iTunes music store, the application connects directly to the Apple iTunes music store service, retrieves a result set then presents it to the user. To the human being, the end result is a seamless experience joining both service calls and local processing into one application.

The end result of careful architecture and planning is a model for software using the Internet as a reliable medium for content delivery which begins to blur the lines between conventional applications and software as a service. This software can incorporate interactions with human beings as the ultimate consumers of service calls. SOA is the foundational paradigm for architecting such applications while standards like XML, web services and others make the interoperability between humans and services possible over the Internet.

More on this topic