This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Constrain Transmission Wrapper"
Jump to navigation
Jump to search
Rene spronk (talk | contribs) |
|||
| Line 6: | Line 6: | ||
* ''Message.attachmentText'' - Contains information referenced by the message | * ''Message.attachmentText'' - Contains information referenced by the message | ||
* ''Transmission.responseModeCode'' - Indicates the type of response desired at the application level | * ''Transmission.responseModeCode'' - Indicates the type of response desired at the application level | ||
| − | * ''Transmission.versionCode'' - Indicates how to | + | * ''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 | * ''Transmission.interactionId'' - Indicates how to validate the interaction, allows confirmation of "can I process this?" and determines receiver behavior | ||
| + | |||
| + | |||
Possible solutions include: | Possible solutions include: | ||
| − | 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 | ||
| Line 20: | Line 22: | ||
* Advantages - Addresses disadvantages above | * Advantages - Addresses disadvantages above | ||
* Disadvantages - It adds yet another layer | * Disadvantages - It adds yet another layer | ||
| + | |||
| + | === 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) | ||
Revision as of 06:13, 2 June 2006
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 include:
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
- Advantages - Addresses disadvantages above
- Disadvantages - It adds yet another layer
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)
