http://www.bpmnforum.net/blog27/bpmn/bpmn-standard/a-first-bpmn-20-choreography-model-2/ Unifying Applications and Business Process Management in the Cloud Wed, 18 Jan 2012 17:22:33 +0000 hourly 1 http://wordpress.org/?v=3.0.2 http://www.bpmnforum.net/blog27/bpmn/bpmn-standard/a-first-bpmn-20-choreography-model-2/comment-page-1/#comment-4 frank.michael.kraft Fri, 06 Mar 2009 10:32:47 +0000 http://www.bpmnforum.net/blog/?p=128#comment-4 The reason is most probably the merged view, where collaborations are merged with the choreography. In this case the pool of one participant is on one side and of the other on the other side. Then it is much easier to connect the message flows, if all participants on the choreography tasks are on the same side. A small remark: It is not about sender or receiver, but about initiator of the task. There could be more message exchanges related to a choreography task than one, in which case the sender and receiver would be the other way round. But the initiator is still the same. So initiator is a nontechnical term in contrast to sender or receiver. The reason is most probably the merged view, where collaborations are merged with the choreography. In this case the pool of one participant is on one side and of the other on the other side. Then it is much easier to connect the message flows, if all participants on the choreography tasks are on the same side.
A small remark: It is not about sender or receiver, but about initiator of the task. There could be more message exchanges related to a choreography task than one, in which case the sender and receiver would be the other way round. But the initiator is still the same. So initiator is a nontechnical term in contrast to sender or receiver.

]]> http://www.bpmnforum.net/blog27/bpmn/bpmn-standard/a-first-bpmn-20-choreography-model-2/comment-page-1/#comment-3 vanto Fri, 06 Mar 2009 10:15:33 +0000 http://www.bpmnforum.net/blog/?p=128#comment-3 Is there a reason why the distinction between sending and receiving participants is realized via coloring? Wouldn't it be more intuitive (and more readable in a huge diagram) to always have the sender on top and the receiver at the bottom of the task? Is there a reason why the distinction between sending and receiving participants is realized via coloring? Wouldn’t it be more intuitive (and more readable in a huge diagram) to always have the sender on top and the receiver at the bottom of the task?

]]>