Behavioral Contract Wrapper (new wrapper mechanism)
The Behavioral Contract Wrapper is a Wrapper that contains information about a event that has happened, as well as the expected behavior of the receiver because of the fact that the event has happened. It contains metadata needed to support the Dynamic Model, either in the form of Receiver Responsibilities or the new CPM.
The Behavioral Contract Wrapper contains a BehavioralContract act which has a 1..1 relationship with a ControlAct in Event mood. As such the Behavioral Contract Wrapper contains the identification of the Trigger Event.
The BehavioralContract Act has a recursive Act Relationship to allow for nesting. This can be used (amongst other things) to support a transactional grouping (a.k.a. transactional batching) mechanism.
When compared to the current normative wrappers this is a new wrapper. Why do we need another wrapper?
- The current dynamic model is being discussed, Receiver Responsibilities (a feature which is linked to the Trigger Event) is deemed not to be sufficient to express the dynamic model. The suggested alternative (CPM) allows for process/business workflows to be modelled. A business workflow is essentially a contract between the sending and receiving parties: it describes the expected behaviour of parties, and therefore also the behaviour of the receiver of an interaction.
- It's important to separate the class representing the "Event" from the class representing "the behavior I expect you to execute because this event has happened". Under the current dynamic model this is pre-coordinated into 1 Act: the control act. This leads to open issues, see the bottom half of these pages: Receiver Responsibilities, Trigger Event.
- The current Transmission Wrapper contains some aspect of the new BehavioralContract wrapper. It would be nice if those could be moved away from the Message or Batch class (so that those using SOA architectures don't have to implement the HL7 Transmission wrapper anymore). The things that have to be moved out of the Transmission wrapper are however not Trigger Event related so can hardly be stuck in the ControlAct wrapper. The Transmission Wrapper should be limited to those things that are really transmission related.
- The BehavioralContract act has a recursive COMP relationship, this can be used to replace the current Batching process. The old batch mechanism has Transmission Wrappers (of payload objects) within a Transmission Wrapper (of the batch) - this leads to all sorts of issues, and is a waste of bandwidth.