Difference between revisions of "Constrain Transmission Wrapper"
Rene spronk (talk | contribs) |
Rene spronk (talk | contribs) |
||
| Line 14: | Line 14: | ||
* ''Transmission.interactionId'' - Indicates how to validate the interaction, allows confirmation of "can I process this?" and determines receiver behavior | * ''Transmission.interactionId'' - Indicates how to validate the interaction, allows confirmation of "can I process this?" and determines receiver behavior | ||
| − | Possible solutions | + | ==Possible solutions== |
1. Moving some/all of these attributes to ControlAct (which would actually have to be a deprecate and copy) | 1. Moving some/all of these attributes to ControlAct (which would actually have to be a deprecate and copy) | ||
| − | |||
* Advantages - ControlAct is already understood and in place | * Advantages - ControlAct is already understood and in place | ||
* Disadvantages - This information relates to the Interaction, while ControlAct really Describes the trigger event. Also, ControlAct is used to convey history, where these attributes aren't terribly relevant | * Disadvantages - This information relates to the Interaction, while ControlAct really Describes the trigger event. Also, ControlAct is used to convey history, where these attributes aren't terribly relevant | ||
2. Adding an additional class to deal with this information. See [[Behavioral Contract Wrapper (new wrapper mechanism)]], which adds an Act to the current ControlAct wrapper. | 2. Adding an additional class to deal with this information. See [[Behavioral Contract Wrapper (new wrapper mechanism)]], which adds an Act to the current ControlAct wrapper. | ||
| − | |||
* Advantages - Addresses disadvantages above | * Advantages - Addresses disadvantages above | ||
* Disadvantages - It adds yet another layer | * Disadvantages - It adds yet another layer | ||
| + | |||
| + | OPEN ISSUE: MnM and INM to express a preference for one of the above options (regardless of which specific attributes will be "moved"). | ||
=== Discussion === | === Discussion === | ||
Revision as of 15:40, 6 December 2006
This page documents an INM Workitem, i.e. an issue within scope of the INM Committee that either is still being discussed, or the resolution of which has not yet been included in an INM ballot.
This page documents an Open MnM Hot Topic, i.e. a methodology issue requiring a resolution from Modeling and Methodology.
Issue
The current message and transmission layer seems to mix transmission and "how to interpret/process" information. Examples of the latter include:
- Message.profileId - Indicates how to validate the instance. Can influence receiver behavior
- Message.processingCode - Indicates how the instance is to be treated
- Message.processingModeCode - Indicates how the instance is to be treated
- Message.responseCode - Indicates the type of response desired at the application level
- Message.attachmentText - Contains information referenced by the message
- Transmission.responseModeCode - Indicates the type of response desired at the application level
- Transmission.versionCode - Indicates how to validate the interactions, allows confirmation of "can I process this?"
- Transmission.interactionId - Indicates how to validate the interaction, allows confirmation of "can I process this?" and determines receiver behavior
Possible solutions
1. Moving some/all of these attributes to ControlAct (which would actually have to be a deprecate and copy)
- Advantages - ControlAct is already understood and in place
- Disadvantages - This information relates to the Interaction, while ControlAct really Describes the trigger event. Also, ControlAct is used to convey history, where these attributes aren't terribly relevant
2. Adding an additional class to deal with this information. See Behavioral Contract Wrapper (new wrapper mechanism), which adds an Act to the current ControlAct wrapper.
- Advantages - Addresses disadvantages above
- Disadvantages - It adds yet another layer
OPEN ISSUE: MnM and INM to express a preference for one of the above options (regardless of which specific attributes will be "moved").
Discussion
In application responses, it would make sense to include a link to the original controlAct, instead of including a reference to the orginal Transmission. (Tom de Jong, 20051113)
20060630 MnM discussion
- need a better explanation of why the layers should be separated
- Need to indicate what can be thrown away and what can't
- Need to indicate what can be changed when routing and what can't
- Better mapping to "standard" transports
- need to recognize that this "non-transport" information is routing related
- Ask INM and SOA to update this
- Defer future discussion until INM asks us to re-address
- Consider as an agenda item INM/MNM joint meeting Sept. 2006
