Interaction (new dynamic model)

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 Interaction 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?

(Lloyd) I can get sold on de-coordinating the TE. However, the composite message type corresponds to the "arguments" of the interaction "method" As arguments are generally taken as part of the signature for a method (Ed: i.e. the method's name along with the number and types of the parameters -and their order), it makes sense that they should be considered part of the interaction.

(M&M Q3 9/13/6) Discussion continued from above however in specifying the interaction patterns for a committee, there will remain a need to bind (and identify) trigger events and composite messages. See "CPM" on Wiki for requirement to identify the interaction patterns. Although pre-coordinating ALL uses of a composite message type may not be feasible, there is certainly a reason to pre-coordinate these in many circumstances. Final designation of "interaction" content must await completion of the CPM discussions.