Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 366002 - Make association of message type with choreography more efficient
Summary: Make association of message type with choreography more efficient
Status: RESOLVED FIXED
Alias: None
Product: BPMN2Modeler
Classification: SOA
Component: UI (show other bugs)
Version: unspecified   Edit
Hardware: All Linux
: P3 enhancement (vote)
Target Milestone: 0.0.1-M2   Edit
Assignee: Robert Brodt CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-08 05:22 EST by Gary Brown CLA
Modified: 2012-01-31 07:50 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gary Brown CLA 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
Comment 1 Gary Brown CLA 2012-01-31 07:50:01 EST
This is now implemented using a short cut button associated with the participant band on the choreography task.