 |
Page History
| Scrollbar | ||
|---|---|---|
|
| Page info | ||||
|---|---|---|---|---|
|
| Panel | ||||
|---|---|---|---|---|
| ||||
|
Summary
...
Description of the profile
...
An important class of joint service action is the business transaction, or contract exchange. Many interactions between participants in the SOA ecosystem are based around business transactions. A business transaction is a joint action engaged in by two or more participants in which the ownership of one of more resources is exchanged.
A classic business transaction is buying some good or service, but there is a huge variety of kinds of possible business transactions. Key to the concept of business transaction is the contract or agreement to exchange. The form of the contract can vary from a simple handshake to an elaborately drawn contract with lawyers giving advice from all sides.
A completed transaction establishes a set of social facts relating to the exchange; typically to the changes of ownerships of the resources being exchanged.
Business Agreement
A business agreement is an agreement entered into by two or more partners that constrains their future behaviors and permitted states.
A business agreement is typically associated with business transactions: the transaction is guided by the agreement and an agreement can be the result of a transaction.
Business transactions often have a well defined life-cycle: a negotiation phase in which the terms of the transaction are discussed, an agreement action which establishes the commitment to the transaction, an action phase in which the agreed-upon items are exchanged (they may need to be manufactured before they can be exchanged), and a termination phase in which there may be long-term commitments by both parties but no particular actions required (e.g., if the exchanged goods are found to be defective, then there is likely a commitment to repair or replace them).
From an architectural perspective, the business transaction often represents the top-most mode of interpretation of service interactions. When participants interact in a service, they exchange information and perform actions that have an effect in the world. These exchanges can be interpreted as realizing part of, and in support of, business transactions.
Business Process
A business process is a description of the tasks, participants' roles and information needed to fulfill a business objective.
Business processes are often used to describe the actions and interactions that form business transactions. This is most clear when the business process defines an activity involving parties external to the organization; however, even within an enterprise, a business process typically involves multiple participants and stakeholders.
In the context of transactions mediated and supported by electronic means, business processes are often required to be defined well enough to permit automation. The forms of such definitions are often referred to as choreographies:
Process Choreography
A process choreography is a description of the possible interactions that may take place between two or more participants to fulfill an objective.
A choreography is, in effect, a description of what the forms of permitted joint actions are when trying to achieve a particular result. Joint actions are by nature formed out of the individual actions of the participants; a choreography can be used to describe those interlocking actions that make up the joint action itself.
Data updates may include updates to multiple data sources, necessitating the need for transactions.
Data updates that trigger transactions are captured by the platform and are propagated upstream to the semantic infrastructure. An example would be the platform monitoring events to identify changes to data.
Transaction Management specializes capabilities architecturally implied by its associated concepts of Composition , Service Composition . The implied architectural capabilities are described in the following paragraphs.
Composition Artifact 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.
Architectural implications of composition on the Semantic Infrastructure are reflected in the following capabilities:
- tools to facilitate identifying description elements that are to be aggregated to assemble the composite description;
- tools to facilitate identifying the sources of information to associate with the description elements;
- tools to collect the identified description elements and their associated sources into a standard, referenceable format that can support general access and understanding;
- tools to automatically update the composite description as the component sources change, and to consistently apply versioning schemes to identify the new description contents and the type and significance of change that occurred.
Service Composition Service composition mechanisms to support orchestration of service-oriented business processes and choreography of service-oriented business collaborations.
The capabilities of Service Composition include:
- Declarative and programmatic compositional languages
- Orchestration and/or choreography engines that support multi-step processes as part of a short-lived or long-lived business transaction;
- Orchestration and/or choreography engines that support compensating transactions in the presences of exception and fault conditions.
...
Capabilities
...
- assembly
- businessTransaction
- compensatingTransaction
- componentAcquisition
- compositionalLanguage
- compositionArchive
- compositionChange
- dataUpdateMonitor
Requirements traceability
Requirement | Source | Capability | ||||||
|---|---|---|---|---|---|---|---|---|
Data management includes linking of disparate data sets and updates of data across the ecosystem. Data updates may include updates to multiple data sources, necessitating the need for transactions. Linkages between the different disparate data sets will be managed by the semantic infrastructure. Data updates that trigger transactions are captured by the platform and are propagated upstream to the semantic infrastructure. An example would be the platform monitoring events to identify changes to data. Link to use case satisfied from caGRID 2.0 Roadmap: the patient has an electronic medical record that spans multiple institutions. The clinical workup data (for example, genomics and proteomics data) is linked to the clinical care record; similarly pathology and radiology findings must be attached to the patient's electronic medical record. | Semantic Infrastructure Requirements::caGRID 2.0 Platform and Terminology Integration::
| |||||||
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::
| compositionalLanguage from inherited abstract profile Service CompositionbusinessTransaction from inherited abstract profile Service CompositioncompensatingTransaction from inherited abstract profile Service Composition | ||||||
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::
| compositionArchive from inherited abstract profile Compositionassembly from inherited abstract profile CompositioncompositionChange from inherited abstract profile CompositioncomponentAcquisition from inherited abstract profile Composition |
| Anchor | ||||
|---|---|---|---|---|
|
...
Description
...
Tools to facilitate identifying description elements that are to be aggregated to assemble the composite description.
...
Requirements addressed
...
...
Overview of possible operations
...
| Anchor | ||||
|---|---|---|---|---|
|
...
Description
...
Orchestration and/or choreography engines that support multi-step processes as part of a short-lived or long-lived business transaction;
...
Requirements addressed
...
...
Overview of possible operations
...
| Anchor | ||||
|---|---|---|---|---|
|
...
Description
...
Orchestration and/or choreography engines that support compensating transactions in the presences of exception and fault conditions.
...
Requirements addressed
...
...
Overview of possible operations
...
| Anchor | ||||
|---|---|---|---|---|
|
...
Description
...
Tools to facilitate identifying the sources of information to associate with the description elements.
...
Requirements addressed
...
...
Overview of possible operations
...
| Anchor | ||||
|---|---|---|---|---|
|
...
Description
...
Declarative and programmatic compositional languages
...
Requirements addressed
...
...
Overview of possible operations
...
| Anchor | ||||
|---|---|---|---|---|
|
...
Description
...
Tools to collect the identified description elements and their associated sources into a standard, referenceable format that can support general access and understanding.
...
Requirements addressed
...
...
Overview of possible operations
...
| Anchor | ||||
|---|---|---|---|---|
|
...
Description
...
Tools to automatically update the composite description as the component sources change, and to consistently apply versioning schemes to identify the new description contents and the type and significance of change that occurred.
...
Requirements addressed
...
...
Overview of possible operations
...
| Anchor | ||||
|---|---|---|---|---|
|
...
Description
...
Data updates may include updates to multiple data sources, necessitating the need for transactions.
Data updates that trigger transactions are captured by the platform and are propagated upstream to the semantic infrastructure. An example would be the platform monitoring events to identify changes to data.
...
Requirements addressed
...
...
Overview of possible operations
...
| Scrollbar | ||
|---|---|---|
|
...
