Behavioral Contract Wrapper (new wrapper mechanism)

Wrapper structure

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.

Rationale

When compared to the current normative wrappers this is a new wrapper. Why do we need another wrapper?

(Mead) However, the justification below is not sufficient reason to ask implementers to shoulder yet another wrapper.

(Rene) It's a cost/benefit issue. It adds a class, but maybe its worth the price. The benefit is in support for a better dynamic model, and in a improved support for SOA architectures.

• 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.
  • (Mead) This is a worthy idea. However, it seems to me that each message instance will be passed in the context of a specific workflow/contract. Therefore, this information can be declared within the current control act wrapper.
• 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.
  • (Mead)A quick look down at the receiver responsibility section suggests that the problem is that "batch based messages interactions do not have receiver responsibilities, while message based ones do. Is this current problem a result of having done a poor job supporting batch messaging? It seems to me that the notion "batch based interaction" makes no sense. Why not treat a batch as simply a collection of messages/interactions?
• 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.
  • (Mead)Yes, and some messagers might want to use EBXML or some other mechanism. They also would want to not use the message wrappers. Still, I think we should put all the behavioral stuff that we want in the control act. We also need to do a better job explaining how to use the message and batch wrappers together. Please clarify and explain [what should be moved elsewhere from the transmission wrapper].
    • (Rene) See Add interactionId to ControlAct. This has all been discussed before, in INM as well as in MnM. There's plenty of stuff there that has nothing to do with the Transmission proper.
• 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.