Transaction Management Functional Profile
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.
An important class of joint action is the business transaction, or contract exchange. Many interactions between participants in the SOA ecosystem are based around business transactions.
Business Transaction
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.
This Functional Profile includes, but is not limited to, the following capability elaborations:
Derived From Requirements
- Semantic Infrastructure Requirements::caGRID 2.0 Platform and Terminology Integration::Data Management 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.
dataUpdateMonitor
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.
