Intent
Exchange data wise correlation states between first and second interactions, when a confirmation is required from consumer for further processing of a service operation’s behavior.
Motivation
During an interaction between a service consumer and a service operation, the operation may require confirmation from the consumer to accomplish its behavior completely.
Example
Dr Good prescribes some drugs for patient Whitefield. He uses PrescribeDrugs service operation to fulfilling his request. This operation does drug interaction (http://en.wikipedia.org/wiki/Drug_interaction) and if any contraindication is found, it has to suspend this interaction and convey these necessary details to Dr Good. Some contraindications may be relative meaning that the benefit of the drugs outweighs the risk and some contraindications may be absolute which are life-threatening. According to the contraindication type, Dr Good takes a decision to go with the medication order, or suspend as shown in figure 1.
A set of input data items (data contracts in WCF) given to a service operation determines its behavior. Some input data items may be fatal to the behavior which makes the interaction faulted and consumer receives appropriate fault details. The consumer is responsible to provide the correctness of the data items for successful completion of the service operation. Until otherwise, the operation keeps throwing the same faults.
Either successful or fault acknowledgement might not be the solution for all interaction as briefed in the example section. Some operations require confirmation from the consumer for further processing due to the input data given by the consumer. The intimation about this can be considered as “warning”, so that consumer can override the warning or stop the processing. A warning can be overridden by calling the service operation second time which can be called as determined interaction by the consumer.
A mechanism to be followed between consumer and provider so that consumer can override the warning and provider can understand that decision in the second time invocation of the service operation in the stateless nature of the service. The mechanism should be supported irrespective of the transport protocols and bindings used in the interaction.
Solution
The following characteristics determine the mechanism to implement determined interaction:
- Warning might be raised by individual input data items
- The user during the interaction must be same
- The interaction should be stateless and transport agnostic
A warning might be raised by individual input data item to the operation. For example, drug 1 might be allergic to the patient and there is an interaction between drug 2 and the food taken by the patient. So, consumer should provide confirmation on each and every warning explicitly and the confirmation should not be against whole interaction. The input data item those are reason to a warning can be referred as “admonished objects”.
Dr. Good is the only person that can override if any warnings are thrown in the first interaction, otherwise it would make the system functionally inconsistent and yield information hazard.
As mentioned, the determined interaction should be agnostic to the underlying transport protocol and bindings, so that constraint to the consumer can be avoided. For example, if this is implemented on WCF session based, then non .NET application could not interact. During the determined interaction, if any new warning is generated, then the interaction should be suspended irrespective of the consumer’s decision. Also, the benefit of the stateless is that if the consumer does not want to override a warning, calling the operation second time is not at all required.
As an abstract, the implementation of determined interaction should consider the following:
- Warning is based on admonished objects
- The user
- Stateless
The admonished objects could be primitive type (drug ID of type “string”) or a WCF data contract (drug information which comprises drug name, dosage detail, form) in the message contract.
As like as the fault mechanism, warning and the followed determined interaction should be WCF binding agnostic and the service provider should not be forced to retain the state of previous interaction like session. During the determined interaction, it should verify the following:
- The interaction originates from the same user who invoked the first time interaction
- The admonished objects are the same as previous ones; otherwise it is meaningless
- Differentiate first and determined interaction
When consumer invokes the operation for the first time, a warning will be raised against the particular data contract. Before sending the warning detail to the consumer, a correlation state should be generated and attached along with the warning detail. This correlation state will help to differentiate the first and determined interaction, confirm the user and the admonished objects.
The consumer should invoke the determined interaction with the correlation state provided in the first time interaction, along with admonished objects which will intimate the service operation to override the specific warning. If the same warning is generated, in the presence of correlation state, the warning will be overridden. The below figure shows the structured representation of “correlation state” in Warning and Data Contract types.
Warning will be generated at the first time interaction with correlation state which can be passed either as response message or fault message in the SOAP based on your preference. The data contract should always have the placed holder for correlation state. For the first time, it will send this as null and is filled during determined interaction.
Correlation State
Correlation state should help the service operation to identify the user, data against the warning and the warning itself during the determined interaction. Generally, service oriented applications provide unique identity to the user. Only thing to be designed upfront to adopt this mechanism is to provide unique number for every possible warning in the service operation.
Correlation state should be comprised of:
- User identity
- Unique warning number
- Data transfer object to be admonished
- Salt value
Passing the above set of information to the consumer will make service contract bulky. So, hashing the above set information into fixed size will make the correlation state always be same size irrespective of the data it hashes and make the service contract consistent. To avoid consumer mimic of correlation state, a salt value can be used.
In the determined interaction, with the same set of information, the operation should create a fresh correlation state and compare this with the one given by the consumer. If both are the same, then the user, data are correct and overridden can be allowed as shown in below figure.
Implementation
