This wiki has undergone a migration to Confluence found Here
Design pattern: request interaction pattern
Jump to navigation
Jump to search
Issue: should the Receiver Responsibilities of an order intercation be defined as two distinct interactions (accept, refuse) or as one interaction?
Option: A singe interaction
A single interaction would have a generic act as its MT (e.g. a generic application acknowledgement message type as deifined in the Shared Messages topic). The acknowledgement code (AA, AE) would indicate sucess or failure.
Option: Two interactions
When using two interactions they could have different static models - both of them rich in detail.
Discussion
- 2009-01-15 MN Q2, informal discussion: Initial leaning is that best practice is to have 2 distinct receiver responsibility interactions because each has a distinct trigger event and the "Accept" trigger event may actually be the trigger for other interactions. It also makes it easier to see what's happened without drilling into the message and conveys this in a consistent way. Also, it allows for better re-use if the payloads need to be different for accept vs. refuse (rather than a single message type that's a choice of the two pieces). (Note that a Web Service wrapper can be used to allow a choice of any of the possible receiver responsibilities.)