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.

(Lloyd) We're not asking for another wrapper. We're re-defining the split of information between the Transmission and existing "ControlAct" wrapper. At the moment, if you throw away the transmission wrapper, you can't process the message. With this re-defined split, the transmission wrapper becomes transport only and does not need to be exposed to the application.

(Mead) Ah, have I mis-understood the proposal? Is the control act wrapper being re-defined and beefed up, while the transmission wrapper is being purified to only handle transmission stuff? I like both of those. If the end product is NOT a structure that has a) transmission wrapper, b) some new "contract" wrapper and c) a control act wrapper, than I am happy. Let's not add a 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.
  • (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.
  • (Rene) It's easy to stick some new attributes in the controlAct class. If those attributes are however characteristics of another activity, then should be modeled as such.
  • (Lloyd) We are conveying it in the ControlAct wrapper, however, we can't hang it off the ControlAct class because that class represents the trigger event and things like receiver responsibilities, whether an acknowledgement is desired, etc. don't belong on the trigger event.
  • (Mead) Well, it would be good to see the concrete proposal first, but adding new content to an existing wrapper is not the same (nor as difficult to swallow) as adding a whole new 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?
  • (Rene) The batch mechanism is messy because it was copied from v2 without a real analysis of what it means, what the use-cases are, and how it should be modeled. The issue has been tackled somewhat by a recent INM motion, see Batch Transmission Wrapper. Those that want to use a Batch as a Transactional grouper (instead of a Transmission grouper) don't have that option in v3, it requires nesting of controlActs, which doesn't fit with the trigger events being modeled.
  • (Lloyd) It's more than just batch responses. It's making the transport layer focus solely on transport.
  • (Mead) As noted (I hope)above, I am for this.

• 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.
    • (Lloyd) I am strongly opposed to adding the transmission stuff to ControlAct. I'm perfectly happy to have a class between transmission and ControlAct and for them to be defined as part of one wrapper.
    • (Mead) Lloyd, are you suggesting that interaction id is transmission stuff? At first blush, I disagree. Or, are you talking about what we used to call "message id".? If so, how does "id" fit in?

• 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.