RE: [soa-rm] Random thoughts on what is a service in the context of SOA

[joe@pantella.net]

Hi Ken: 

Just a few thoughts:

1) I think that the third of the atomic categories is equivalent to the first.  If the data is not local then the entity ought not know that the data it seeks needs to be processed before it is returned.  My inclination is that the third is hidden as part of the implementation, otherwise the requesting entity is simply choreographing services of atomic category 1 and atomic category 2 (as you have them listed below).

2) "Note, the capability does not have to be aware of each or any of the accessing services."  
This is interesting.  Are there security implications here that need to be considered?  This makes me think of the capability as the service, which might be accessed by unforseen entities.  I think this note blurs the distinction between the capability and the service as you've used it.

3) I'm very interested in further fleshing out the metadata discussion, I think your discussion of metadata partitioning to facilitate reusability is extremely important.  

-- JJP
-----Original Message-----
From: Ken Laskey [mailto:klaskey@mitre.org] 
Sent: Wednesday, July 27, 2005 10:09 AM
To: SOA-RM
Subject: [soa-rm] Random thoughts on what is a service in the context of SOA


The recent ftf dug deeply into the concept of services and what needs to be said in the RM. Being the editor with the responsibility of getting the words down, I've started by collecting what I have read on this mailing list, what was said at the ftf, and a large dose of my own thoughts. The following is a rough capture of that collection. To save the time of trying to create crisp, well-worded prose for the 08 draft and then having issues raised about the included concepts, I decided to get the thoughts out there and generate some consensus to precede the polished words. This gets long but I expect there will be considerable feedback :-)

Ken

<randomThoughts>
SOA enables entities with needs to find and access the capabilities necessary to address those needs. The needs falls into the atomic categories of
- need for data with which to do local processing;
- need for processing of locally-held data, requiring the data to be sent to the processing capability or the processing capability being told how to access the data;
- need for remote data to be processed by remote capabilities.

A few notes on what is described as atomic:
- The local-local combination is a trivial case where SOA can be useful but requires nothing special.
- The case where remote processing is required but there is no specific data being worked on is a special case of remote-remote because the processing is assumed to interact with data at some point; a completely self-contained processing capability would again be a trivial case.

In many cases, the need requires a combination of access to processing and data capabilities, where the combination may be 
- transparent to the needing entity in that all the details of the combination are known or available;
- opaque to the needing entity in that a single request initiates a series of enabling capability requests, none of which are known or available;
- some intermediate state where some but not necessarily all of the details are known or available.
It could be argued that some degree of the third case is the only real option because a service description will provide some amount of information (negating 100% opacity) but it is impossible to provide 100% transparency.

Back to the underlying capabilities, these exist because someone had a need that was addressed by creating the capability or saw a need that they believed the capability would fill. The creation of capability predates any discussion of SOA but SOA conceptually provides a means to access such capabilities and, further, to use a capability for a purpose or by an audience other than the ones that were the motivation for the capability being created in the first place.

A service is the means to access capability. 

Two things are needed to effectively use a capability under SOA:
- understanding the underlying capability;
- understanding the accessing service.

Metadata is the means for conveying information that enables an entity not directly involved with the development and maintenance of the capability or service to generate that understanding. The service description is one collection of metadata. A capability description is another collection of metadata. Note, the capability description will likely exist independently from reference to the capability being used in the SOA context; however, the service metadata will point to the capability and likely to the capability metadata, and the capability metadata may reference one or more services through which it can be accessed. Note, the capability does not have to be aware of each or any of the accessing services.

The description metadata, both for a capability and the service for accessing the capability, contain several common elements:
- technical assumptions: these are related to the model of the world under which the capability or service was developed. There is an old joke about assuming a spherical chicken. In some cases, this is a fine assumption and a capability based on this technical assumption is appropriate to address the current need. In other cases, it is a poor technical assumption and it would be incorrect to use such a capability. 
- constraints: preconditions that must be satisfied for the capability or service to be used. For example, I may want to get a credit report and the credit bureau will charge me for the report. I can request the report by telephone or by Web access but there may be an additional charge if I want to receive a hardcopy by mail. The underlying capability is the periodic generation of the credit report and the ability to distribute it in different ways. 
- policies: a set of assertions and obligations to which those providing and those consuming capabilities must adhere. The use of various services to access the capabilities might introduce additional policies.
- effects: how the world will change as a result of a service being invoked and its access to its underlying capabilities.

Note that any of the aforementioned metadata elements can exist separately from the individual metadata instances and the metadata can consist of pointers, links, or other service accesses to these descriptions. This indirection facilitates the reuse of the individual descriptions and supports flexibility in how the details of the descriptions are expressed.

In addition, the service description will define the service interface. The service interface is the set of specific commands and data exchanges for invoking the service and accessing the underlying capability. This is related to the data model exposed by the service interface. Additional things can be said about the form and function of the service interface. 

All of this requires a semantic understanding, either through the use of common semantics (adequately documented) or mechanisms for semantic negotiation. Additional things also need to be said here.

This discussion has attempted to discriminate between a capability and the services that would access the capability. It is reasonable to ask whether this distinction is necessary. The prejudice here is to avoid the common situation where someone wants Web access to some legacy application and contracts for a GUI to be built. Over time, more and more business logic works its way into the GUI and the GUI becomes an ad hoc application of which the actual GUI is the most visible but not necessarily the most critical part. Eventually, exposing one stovepipe leads to creating another one. Although probably an architecture consideration, the reference model shown draw useful distinctions that are consistent with SOA concepts for flexible repurposing of capabilities and to avoid describing what could easily turn into service stovepipes. The actual discussion would be content for the reference architecture. 

</randomThoughts>
------------------------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508