Summary
Description of the profile
The execution context of a service interaction is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction, and thus forms a path between those with needs and those with capabilities. Service generation is the ability to provision an execution context from the service descriptions, and associated artifacts, managed by the Semantic Infrastructure.
The service description (and a corresponding description associated with the service consumer and its needs) contains information that can include preferred protocols, semantics, policies and other conditions and assumptions that describe how a service can and may be used. The participants (providers, consumers, and any third parties) must agree and acknowledge a consistent set of agreements in order to have a successful service interaction, i.e. realizing the described real world effects. The execution context is the collection of this consistent set of agreements.
The execution context is not limited to one side of the interaction; rather it concerns the totality of the interaction – including the service provider, the service consumer and the common infrastructure needed to mediate the interaction. While there may be third parties, for example, government regulators, who set some of the conditions for the execution context, this merely increases the conditions and constraints needing to be coordinated and may require additional information exchange to complete the execution context.
The execution context is central to many aspects of a service interaction. It defines, for example, a decision point for policy enforcement relating to the service interaction. Note that a policy decision point is not necessarily the same as an enforcement point: an execution context is not by itself something that lends itself to enforcement. On the other hand, any enforcement mechanism of a policy is likely to take into account the particulars of the actual execution context. The execution context also allows us to distinguish services from one another. Different instances of the same service – denoting interactions between a given service provider and different service consumers for example – are distinguished by virtue of the fact that their execution contexts are different.
Finally, the execution context is also the context in which the interpretation of data that is exchanged takes place. A particular string has a particular meaning in a service interaction in a particular context – the execution context.
While the execution context captures the conditions under which interaction can occur, it does not capture the specific service invocations that do occur in a specific interaction. A service interaction introduces the concept of an Interaction Description which is composed of both the Execution Context and an Interaction Log. The execution context specifies the set of conditions under which the interaction occurs and the interaction log captures the sequence of service interactions that occur within the execution context. This sequence should follow the Process Model but can include additional details. For example, the Process Model may specify an action that results in identifying a data source, and the identified source is used in a subsequent action. The Interaction Log would record the specific data source used. Such uses of execution context imply (1) a standardized format for capturing execution context and (2) a subclass of general description could be defined to support visibility of saved execution contexts.
Descriptions of the interactions are important for enabling auditability and repeatability, thereby establishing a context for results and support for understanding observed change in performance or results. The architectural implications is that the following capabilities are required:
- one or more mechanisms to capture, describe, store, discover, and retrieve interaction logs, execution contexts, and the combined interaction descriptions;
- one or more mechanisms for attaching to any results the means to identify and retrieve the interaction description under which the results were generated.
The semantic infrastructure provides the service description, and related artifacts, which the platform leverages for service generation. The constraints and policies specified in the semantic infrastructure are inherited by the platform and are enforced as runtime policies.
Additional platform specific and runtime information is provided by the developer at the time of service generation.
Service Generation specializes capabilities architecturally implied by its associated concepts of Interaction . The implied architectural capabilities are described in the following paragraphs.
Interaction Descriptions of interactions are important for enabling auditability and repeatability, thereby establishing a context for results and support for understanding observed change in performance or results. Infrastructure services provide mechanisms to support service interaction.
Architectural implications of interactions on the Semantic Infrastructure are reflected in the following capabilities:
- one or more mechanisms to capture, describe, store, discover, and retrieve interaction logs, execution contexts, and the combined interaction descriptions;
- one or more mechanisms for attaching to any results the means to identify and retrieve the interaction description under which the results were generated.
- mediation services such as message and event brokers, providers, and/or buses that provide message translation/transformation, gateway capability, message persistence, reliable message delivery, and/or intelligent routing semantics;
- binding services that support translation and transformation of multiple application-level protocols to standard network transport protocols;
- auditing and logging services that provide a data store and mechanism to record information related to service interaction activity such as message traffic patterns, security violations, and service contract and policy violations
- security services that abstract techniques such as public key cryptography, secure networks, virus protection, etc., which provide protection against common security threats in a SOA ecosystem;
- monitoring services such as hardware and software mechanisms that both monitor the performance of systems that host services and network traffic during service interaction, and are capable of generating regular monitoring reports.
Capabilities
- binding
- cdiscFormGenModel
- interactionLog
- interactionResults
- logging
- mediation
- monitoring
- security
- serviceGenModel
Requirements traceability
Requirement |
Source |
Capability |
|---|---|---|
In the medium-term (3-to-5 years) CDISC is interested in generating CDISC-standards based data collection forms (e.g., Case Report Form). Ideally data capture forms and the data captured by devices would follow CDISC standards. When data is submitted to a regulatory agency, (e.g., FDA), the compliance of this data with CDISC standards should be validated. Data collected using CDISC standards should have Computer Semantic Interoperability (CSI). However, this is not a current requirement; but the Knowledge Repository update of NCI Forms may provide this capability. *Source: * * 5/20/2010 Interview, Rhonda Facile * 06/09/2010 CDISC Share F2F Meetings, David Iberson-Hurst |
Gap Analysis::CDISC::CDISC-15 - Support generating standards-based data collection forms |
|
Interaction is the activity involved in using a service to access capability in order to achieve a particular desired real world effect, where real world effect is the actual result of using a service. An interaction can be characterized by a sequence of actions. Consequently, interacting with a service, i.e. performing actions against the service--usually mediated by a series of message exchanges--involves actions performed by the service. Different modes of interaction are possible such as modifying the shared state of a resource. Note that a participant (or agent acting on behalf of the participant) can be the sender of a message, the receiver of a message, or both. Interacting with Services has the following architectural implications on mechanisms that facilitate service interaction: A well-defined service Information Model, as elaborated in the inherited Information Model profile. A well-defined service Behavior Model, as elaborated in the inherited Behavior Model profile. Service composition mechanisms to support orchestration of service-oriented business processes and choreography of service-oriented business collaborations, as elaborated in the inherited Service Composition profile. Infrastructure services that provides mechanisms to support service interaction, as elaborated in the inherited Interaction profile. A layered and tiered service component architecture that supports multiple message exchange patterns (MEPs)l, as elaborated in the inherited Message Exchange profile. |
Semantic Profile::OASIS SOA::Interacting with Services Model |
interactionLog from inherited abstract profile InteractioninteractionResults from inherited abstract profile Interactionmediation from inherited abstract profile Interactionbinding from inherited abstract profile Interactionlogging from inherited abstract profile Interactionsecurity from inherited abstract profile Interactionmonitoring from inherited abstract profile Interaction |
A service description is an artifact, usually document-based, that defines or references the information needed to use, deploy, manage and otherwise control a service. This includes not only the information and behavior models associated with a service to define the service interface but also includes information needed to decide whether the service is appropriate for the current needs of the service consumer. Thus, the service description will also include information such as service reachability, service functionality, and the policies and contracts associated with a service. A service description artifact may be a single document or it may be an interlinked set of documents. Architectural implications of service description on the Semantic Infrastructure are reflected in the following functional decomposition: * Description will change over time and its contents will reflect changing needs and context. This is elaborated in the inherited Change profile. * Description makes use of defined semantics, where the semantics may be used for categorization or providing other property and value information for description classes. This is elaborated in the inherited Semantic Model profile. * Descriptions include reference to policies defining conditions of use and optionally contracts representing agreement on policies and other conditions. This is elaborated in the inherited Policy profile. * Descriptions include references to metrics which describe the operational characteristics of the subjects being described. This is elaborated in the inherited Metrics profile. * Descriptions of the interactions are important for enabling auditability and repeatability, thereby establishing a context for results and support for understanding observed change in performance or results. This is elaborated in the inherited Interaction profile. * Descriptions may capture very focused information subsets or can be an aggregate of numerous component descriptions. Service description is an example of a likely aggregate for which manual maintenance of all aspects would not be feasible. This is elaborated in the inherited Composition profile. * Descriptions provide up-to-date information on what a resource is, the conditions for interacting with the resource, and the results of such interactions. As such, the description is the source of vital information in establishing willingness to interact with a resource, reachability to make interaction possible, and compliance with relevant conditions of use. This is elaborated in the inherited Interoperability profile. Policy capabilities are specialization of Artifact capabilities. |
Semantic Profile::OASIS SOA::Service Description Model |
interactionLog from inherited abstract profile InteractioninteractionResults from inherited abstract profile Interaction |
Service generation is the ability to generate services from user defined service metadata. The semantic infrastructure provides this metadata and the platform leverages this metadata for service generation. The constraints and policies specified in the semantic infrastructure are inherited by the platform and are enforced as runtime policies. Additional platform specific and runtime information is provided by the developer at the time of service generation. |
Semantic Infrastructure Requirements::caGRID 2.0 Platform and Terminology Integration::Service Generation |
|
binding
Description
binding services that support translation and transformation of multiple application-level protocols to standard network transport protocols;
Requirements addressed
Overview of possible operations
cdiscFormGenModel
Description
CDISC Form Generation Model API
In the medium-term (3-to-5 years) CDISC is interested in generating CDISC-standards based data collection forms (e.g., Case Report Form). Ideally data capture forms and the data captured by devices would follow CDISC standards. When data is submitted to a regulatory agency, (e.g., FDA), the compliance of this data with CDISC standards should be validated. Data collected using CDISC standards should have Computer Semantic Interoperability (CSI). However, this is not a current requirement; but the Knowledge Repository update of NCI Forms may provide this capability.
Requirements addressed
Overview of possible operations
interactionLog
Description
One or more mechanisms to capture, describe, store, discover, and retrieve interaction logs, execution contexts, and the combined interaction descriptions.
Requirements addressed
Overview of possible operations
interactionResults
Description
One or more mechanisms for attaching to any results the means to identify and retrieve the interaction description under which the results were generated.
Requirements addressed
Overview of possible operations
logging
Description
auditing and logging services that provide a data store and mechanism to record information related to service interaction activity such as message traffic patterns, security violations, and service contract and policy violations
Requirements addressed
Overview of possible operations
mediation
Description
mediation services such as message and event brokers, providers, and/or buses that provide message translation/transformation, gateway capability, message persistence, reliable message delivery, and/or intelligent routing semantics;
Requirements addressed
Overview of possible operations
monitoring
Description
monitoring services such as hardware and software mechanisms that both monitor the performance of systems that host services and network traffic during service interaction, and are capable of generating regular monitoring reports.
Requirements addressed
Overview of possible operations
security
Description
security services that abstract techniques such as public key cryptography, secure networks, virus protection, etc., which provide protection against common security threats in a SOA ecosystem;
Requirements addressed
Overview of possible operations
serviceGenModel
Description
Service Discovery Model API
