SOA-RM Wiki
1. Service Interaction View
Reference Viewpoint: Service Interaction Viewpoint
Version: Working Draft 1, August 1, 2006
Figure x Model elements described in the Service Interaction View
1.1. Interacting with Services
Interaction is the activity involved in making use of a capability offered in order to achieve a particular desired real world effect, where real world effect is the actual result of using a service (as opposed to merely the capability offered by a service provider). An activity can be characterized by a sequence of actions. Consequently, interacting with a service involves performing actions against the service, usually through a series of information exchanges (e.g., messages), although other modes of interaction are possible such as modifying the [shared] state of a [shared?] resource.
In many cases, interacting with a service occurs across service participant ownership boundaries; therefore, it is important to adequately characterize the information and behavior models associated with a service interaction. The information model documents the syntax (structure) and semantics (meaning) of the information content associated with information exchanges between service participants, and the behavior model documents the actions and the process or temporal aspects of interacting with the service. The information and behavior models are essential elements that are referenced by the service description, which provides the information needed in order to use, or consider using, a service.
Recall from the SOA-RM, that the initiator in a service interaction MUST be aware of the other parties (awareness), the participants MUST be predisposed to interaction (willingness), and the participants MUST be able to interact (reachability). These are all preconditions to visibility.
There are many facets of interaction but all are grounded in a particular execution context (the agreed upon elements and conditions under which interaction can occur). Execution context can be thought of as the evolving collection of answers, agreements, expectations, and appropriate future actions that forms a path between those with needs and those with capabilities and thus permit service participants to interact.
Conceptually then, a service interaction model can be illustrated using a UML class diagram as follows:
This conceptual model shows that the abstract service interaction model is “made up of” the real world effect, the service description (which references an information model and a behavior model), visibility, and the execution context. The information model contains properties of syntax and semantics and the behavior model contains properties of action and process.
Each of these elements of the service interaction model is further described in this SOA-RA architectural view (the Service Interaction View as shown in Figure x).
1.2. Real World Effect of Using Services
[Frank’s Section]
1.3. Service Description
[In Work - Jeff]
It should be noted that a service description is actually an artifact, usually a document-based artifact, that references not only the information and behavior models associated with a service but also provides data associated with service reachability, service functionality?, describes the service interface, and specifies the policies and contracts associated with a service. [NOTE TO TEAM: THIS CAN LEAD TO AN EXTENSIVE DISCUSSION AROUND THE SD SO IT MAY TURN OUT THAT WE MOVE THIS TO A SEPARATE VIEW, E.G., SERVICE INTERFACE VIEW OR SERVICE DESCRIPTION VIEW. WILL FOCUS ON INFO MODEL AND BEHAVIOR MODEL FOR NOW].
1.3.1. Information Model
Within the context of SOA, the information model is a characterization of the information that is associated with the use of a service. The information model describes the structure, format, and meaning of information and data that may be exchanged with a service as well as prescribing what information needs to be provided to the service in order to access its capabilities and interpret responses.
The key to facilitating and improving the retrieval and understanding of information and data is the use of metadata. The importance of metadata in helping to achieve true [xxx] cannot be stressed enough. Consequently, the following subsection is dedicated to providing additional insight into metadata, particularly as it relates to an information model.
1.3.1.1. Data-Level Information Model
Layering
Data Formats, Elements and Definitions
Schema
1.3.1.2. Data-Level Model Integration (& Mediation)
In an enterprise with very large scale, it is nearly impossible to define a single set of data architecture standards that are suitable for everyone. Individual systems and services are usually built to a set of standards, data models, and technologies that best address their requirements. Mediation is used to integrate information and services that use these different standards and technologies. For the purposes of this SOA reference architecture, mediation is divided into four types:
Adaptation – Adapters provide service mediation when an invoking application cannot communicate directly with the service. Adapters act as an API layer that allows compatibility between different types of applications and the service;
Aggregation – Aggregation provides a central point of information that is being integrated from multiple sources. The information may then appear as if it comes from a single source;
Transformation – Transformation services convert information between formats when application requests information that is not in the format it desires;
Orchestration – Orchestrates multiple services by coordinating and managing the flow of service events. This is often referred to process automation or workflow management.
Adaptation and orchestration can be considered functions of Service mediation. They are largely affected by the Service Level Information Model (see Section x.x.x.x).
Transformation and aggregation are data mediation functions. The Data Level Information model must possess the necessary elements to support these functions. The key to supporting them is the presence of accessible metadata. Metadata must describe differences in the name, structure, and representation of the data to be mediated for automated mediation to be successful.
[also include concept from Newcomer/Lomow pp 120-121]
1.3.1.3. Data-Level Security
There are several aspects of data level security that need to be described as part of the Data Level Information Model. Five of the most common and important aspects of data level security are:
- Integrity – [DEFINE THESE]
- Trustworthiness
- Validity
- Confidentiality
- Access control categorization
Each aspect of data level security is further described in the following subsections.
1.3.1.3.1. Integrity
The integrity of data can be very important in some cases. One approach to providing data integrity is the use of digital signature technology. Digital signatures provide a means to detect if signed data has been altered. The private key of some entity in the system is used to create a digital signature for some set of data. Other entities in the system can check the integrity of the signed data set via signature verification algorithms. Any changes to the data that was signed will cause signature verification to fail, which indicates that integrity of the data set has been compromised.
The signature creation and verification algorithms use a variety of parameters. The set of parameters used by signature algorithms include the public and private keys of the signer, the data being signed, the signature itself (which is used by the verification algorithms), and mathematical parameters that are specific to the particular algorithms being used (although these mathematical parameters are often embedded in the public/private key pairs and do not have to be handled separately).
A party verifying a digital signature must have access to the public key that corresponds to the private key used to generate the signature. Thus, it is always important to know who created the signature and how to get the public key of the signer.
The structure and syntax of digital signatures and the association of signatures with XML-based data, for example, is defined in the XML Encryption and XML Signature specifications. Similarly, the structure and syntax for exchanging public key information (i.e., X.509v3 certificates) is defined in the Extensible Key Management Specification (XKMS). Because this SOA reference architecture is intended to be technology neutral, we do not delve further into exploring these technology standards; however, we would expect organizations developing concrete SOA architectures to do so.
1.3.1.4. Message Level Information Model
1.3.1.5. Service Level Information Model
1.3.2. Behavior Model
1.3.2.1. Message Exchange Interaction
1.3.2.2. Changing State of Shared Resource Interaction
1.3.3. Policy and Contacts
[Danny’s Section]
1.3.4. Reachability
[Danny’s Section]
1.3.5. Visibility of Services
[Danny’s Section]
1.3.6. Execution Context
[In Work - Ken]
1.4. References
[1] DoD Net-Centric Data Strategy
[2] JAXR Specification
[3] DISA Info Arch from Estefan et al.
[4] ISO/IEC 11179-3
[5] OMG SysML Spec 1.0
2. ORIGINAL OUTLINE
2.1. Service Interaction
How do I reach you?
2.1.1. Information and Behaviour Model
2.1.2. Information Exchange Medium
Messages, etc. etc. MIME types