Difference between revisions of "Behavioral Contract Wrapper (new wrapper mechanism)"
Rene spronk (talk | contribs) |
Rene spronk (talk | contribs) |
||
(2 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
{{INM Workitem}} | {{INM Workitem}} | ||
− | [[Image: | + | [[Image:20070125 new wrapper strucs.gif|200px|right|thumb|New Wrapper structure]] |
The '''Behavioral Contract Wrapper''' is a [[Wrapper]] that contains information about a [[Trigger Event|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''' is a [[Wrapper]] that contains information about a [[Trigger Event|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]]. | ||
Line 15: | Line 15: | ||
: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. The control act wrapper being re-defined and beefed up, while the transmission wrapper is being purified to only handle transmission stuff. | :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. The control act wrapper being re-defined and beefed up, while the transmission wrapper is being purified to only handle transmission stuff. | ||
− | *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. | + | *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. (See [[INM assumptions with regards to CPM]] for details). |
*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]]. | *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 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. | *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. | ||
*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 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]. | **(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 [[ | + | ***(Rene) See [[Constrain Transmission Wrapper]]. 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. | ***(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? | ***(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? |
Latest revision as of 07:14, 25 January 2007
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
See the discussion page for discussion details.
When compared to the current normative wrappers this is a new wrapper. Why do we need 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. The control act wrapper being re-defined and beefed up, while the transmission wrapper is being purified to only handle transmission stuff.
- 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. (See INM assumptions with regards to CPM for details).
- 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 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.
- 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 Constrain Transmission Wrapper. 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?
- (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].