Last week I posted my review of SoaML standard, which was followed by a discussion with a couple of authors of that standard. This gave me an idea to state my understanding of the basic model of service orientation that I see differently than the well known triangle-model of Provider-Registry-Consumer shown below.
To my understanding, the concept of service orientation leads to a double-triangle-model, which recognises a Service as the 'first class citizen' in addition to the Provider-Registry-Consumer trio. Here is how my model looks like:
Thus, what are the differences?
The first and the foremost difference is that a Service is viewed at large - as a business and technical entity. The Service can exist on its own under the Provider supervision, i.e. with or without Consumers.
The Service is advertised and defined to its Consumers via Service Description document that may be registered in the dedicated Service Registry. The Service Description contains enough information to allow potential service Consumers make the decisions whether the Service can satisfy their needs. Among others, Service Description contains definition of offered business functionality, promised Real World Effect (results), policies required by the Provider, available communication interfaces and tested executions context (business and technical). In other words, registration of the Service requires much more information to be announced than registration of an Interface. I can say that registration of the Service is about WHAT the Service can do and WHAT is needed to use it while registration of the Interfaces is about HOW to use it.
Another aspect of the Service is that it clearer articulates that the service Provider is not necessary the owner of the capabilities the Service provides access to. We can say almost the same thing about the Interface but a tacit assumption is that, at least, one Component covered by the Interface belongs to the service Provider. We do not know and not interested about other Components, whose they are and where they are. From one hand, it is good, from another hand, it opens 'a door' to irresponsible behaviour of the service Provider toward the Consumers because the Provider cares about the communication via Interface only, not about the business functionality and Real World Effect for the Consumers.
When potential Consumer finds appropriate Service, it is the time to set up a Service Contract between the Consumer and Provider. The Service Contract is an agreed set of policies, rules and choices that the Provider guarantees to the Consumer regarding the Service. In majority of cases, the Service Contract is a derivative of the Service Description; the Service Contract may include, e.g., a subset of policies and interfaces defined in the Service Description. The Consumer may also demand certain policies of its own to be included into the Service Contract. For example, the Service Description lists communication via secured channel (e.g., over SSL) as an option while for the Consumer it is the mandatory requirements, i.e. policy; the Service Contract can state using secured channel as a mandatory condition of the Service use.
In the illustration, the negotiation of the Service Contract from the Consumer side is shown as dotted arrow. This reflects the fact that not all Service Descriptions are negotiable to all Consumers. Such Service Description may represent a Security Service that is mandatory as is to all Consumers. In this case, the Service Description plays the role of implicit Service Contract. It is also important to notice that the Service Contract negotiation may be performed as on-line, automatically, as off-line - this depends on the level of automation available in the Provider-Registry-Consumer triangle.
After the Service Contract is set, the Consumers concentrate on the Consumer/component - Service relationship. What and how the Provider is doing becomes of no importance to the Consumers, i.e. the Provider become transparent whilst the Service is working and the SLA is preserved. This permits not only changing of the service implementation in the boarders of the Service Description and the Service Contract, but also changing the service Provider within related legal boundaries (i.e. the Provider may be acquired by another organisation or the Provider delegates its rights to a third party. In the latter case, the existing Consumers may be informed if their Service Contract contains such policy).
Described differences between Service-oriented and Interface-oriented models give me an opportunity to extend service orientation onto pure business entities and Business-Technology relationships. Why an Interface-oriented model cannot do the same? Because Business is interested, in general, in WHAT, WHY and WHO with regard to offered business functionality and Real World Effect, which are provided by very particular service entity. The Interface-oriented model positions HOW to reach the business functionality and Real World Effect as the highest priority, i.e. it answers to the different concern, which is not that valuable to the Business, to the business goals and objectives.
As a result of this line of logic, I can say that the design of business services, in Business and Technology, i.e. when the Services are realising business functions, features, services and process, must be done in the Service-oriented model. If the implementation relates to the business services, the design of implementation in Technology may be done in the Interface-oriented model but within the boundaries defined by the Service-oriented model.
Leave a comment