Bug 366002

Description Gary Brown 2011-12-08 05:22:23 EST

Build Identifier: 

The addition of the 'add participant' mechanism on the ChoreographyTask has been a great efficiency improvement. However the other efficiency problem is the creation of the message flows, messages and item definitions that are required for each of the choreography tasks. This aim should be to create this information in a single step, as opposed to the current multiple steps - creating up to three components, defining their properties and associations.

Essentially a particular choreography task is going to be represented by the participants and a message type (or possibly two if a choreography task represents a request/response).

The MessageFlow for each message would be specific to the choreography task, but the Message and ItemDefinition components would be shared with other places in the choreography that use the same message type - so as with the participants, the user should be offered the ability to create a new message type (referencing the appropriate item defn import - e.g. xml schema elements/types), or select from a list of previously imported message types.

The other part of the MessageFlow is the source and target participants - was thinking that the first MessageFlow associated with the ChoreographyTask should use the initiating participant as the source, and other participant as the target. If the user then wants to add a second MessageFlow (i.e. the response), these participants would be reversed.

We then need to have a mechanism for deleting the 'request' or 'response' message flow - editing the details may need to be done through the properties for the ChoreographyTask, as there is no visual representation of the message flow - although menu items could be added to the context menu for the ChoreographyTask to make this more direct?

Reproducible: Always