Difference between revisions of "Interaction (new dynamic model)"
Rene spronk (talk | contribs) (new page) |
Rene spronk (talk | contribs) |
||
| Line 13: | Line 13: | ||
*[[Composite Message Type]] – The set of static model definitions (wrappers and message types) that define the structures of the data that is transmitted by the interaction. | *[[Composite Message Type]] – The set of static model definitions (wrappers and message types) that define the structures of the data that is transmitted by the interaction. | ||
| − | Under the [[Communication Process Model]], [[Receiver Responsibilities]] are no longer part of the Interaction. | + | Under the [[Communication Process Model]], [[Receiver Responsibilities]] are no longer part of the Interaction. The initial interaction which starts a communication process will identify the appropriate [[CPM]] ID somewhere in the composite message type, it wont be precoordinated within the Interaction identifier. |
==Discussion== | ==Discussion== | ||
Revision as of 08:19, 1 September 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.
See Interaction for details of Interactions in the context of the old/current dynamic model.
A unique association between a specific Composite Message Type and a particular Trigger Event that initiates or "triggers" the transfer. It is a unique, one-way transfer of information.
A single Interaction explicitly answers the questions:
- How a system knows when to send a particular type of message;
- What the particular message type is.
As the list above indicates, each Interactions is defined as a tuple involving the following elements:
- Trigger Event - each interaction will be associated with a single trigger event. The trigger event represents the “real-world” occurrence that creates a need to exchange information. Note that a given trigger event may fire multiple interactions.
- Note that the semantic context of an interaction has to be defined by a domain.
- Composite Message Type – The set of static model definitions (wrappers and message types) that define the structures of the data that is transmitted by the interaction.
Under the Communication Process Model, Receiver Responsibilities are no longer part of the Interaction. The initial interaction which starts a communication process will identify the appropriate CPM ID somewhere in the composite message type, it wont be precoordinated within the Interaction identifier.
Discussion
- The current methodology states that each interaction has 1 Trigger Event associated with it. Either we have to change the statement to say that an interaction may be caused by one out of a defined set of TEs (and this set of TEs is then associated with the IN), or we should remove the TE from the triplet which defines an IN. If TE is dropped as part of the definition of an IN, the interaction identifier will solely identify the elements the composite message is being made up of.
- All of this weakens the role of the TE identifier, unless Interaction Patterns still use TEs to determine dynamic behaviour.
Question: can TE be taken out of the Interaction? What is the benefit of pre-coordinating TE and Composite Message Type in 1 Identifier?
