This shows a sub-section of the Server, called Busy Server. It receives, then sends, receives, then sends, then receives a close and ends.

To make the model more general, there can be multiple receive/sends before the close. The actual message received determines the behavior--thus, it is an event-based decision and can be seen as follows:

The above model hides the receive Tasks within the event-based decision and this can be confusing as the model evolves. The other option as we discussed in the F2F is to place a generic receive Task and then use a data-based decision to follow (see below):

The following model shows the same behavior and all the receive Tasks, but is more complex. It also shows the use of the branching Intermediate Event.

The following model shows another alternative to the Event Decision. This model is similar to the solution that we had in the 0.9 spec. The Gateway would mainly be a marker for the beginning of this behavior. Which ever of the two tasks that follow the Gateway receives the message first will "pull" the flow down that path, to the exclusion of the other path(s). We use to use Events as the next object down the paths, but this solution will use Tasks of type Receive in addition to Events. This solution is compact and perserves the use of Tasks to receive messages in a choreography.