Defining a Services Platform

In my previous post I discussed the steps Compassion was taking in order to implement SOA. As promised I won't bore you with business process specifics (step number 1) but it might be of interest to many of you the SOA standards we've adopted. These were written in large part by a extremely talented fellow Compassion architect named Chuck Boudreau (and owner of Golden Hills Software and the SurveyGold product).

The way we approached this task is to define a "services platform" that includes seven key categories in which we published standards for our IT organization. These categories describe essential services necessary to enable effective communications between a service consumer and a service provider. The idea of doing so was based on advice from the book Understanding SOA with Web Services by Newcomer and Lomow.

Here they are:

Service Discovery
The automatic identifying of a software-based service which allows processing functions to be offered and then executed after they have been located. Also includes design time notification

Service Contract
The request and (optional) response schemas for each operation exposed by a service, the security protocols, and the bindings associated with a service automatic identifying of a software-based service.

Service Agents (Proxies)
These isolate the idiosyncrasies of calling diverse services from your application, and can make available additional services, such as basic mapping between the format of the data exposed by the service and the format your application requires.

Communication
The envelope schema including addressing and context to support routing and correlation of messages sent between service consumers and service providers.

Security
Message encryption, service consumer authentication and security consumer authorization and how authorization is managed.

Message Exchange Patterns
Service contracts express valid message exchange patterns between two parties. The party that initiates communication is called the initiator. The other party is called the service. Service contracts specify one or more operation contracts. An operation contract represents an individual message exchange or a correlated request/reply message exchange

Management/Quality
Addresses operational and management concerns including logging, performance monitoring, duplicate message handling and exception management.


In the posts that follow I'll drill down into each of these and describe what is included in each standard and a little about how we arrvied at the standard.