As introduced with BPMN 2.0 there are two new types of models to specify choreographies:

• Conversation-Model and
• Choreography-Model.

Modeling Choreograpies provides the possibility to sum up communication across participation borders. Hereby especially agreements about documents, message formats and also the sequence of interactions can be made between the process participants. Choreography models do not show particular internal processes of participants, they rather visualize global interactions and dependencies between participants of the process.

Conversation-Model

The new Conversation-Model is used to model a "who with whom and what"-view of processes. All process participants can be included in a compact form of modeling as long as denoting which communication is involved.

Process participants are represented as Pools (collapsed, see Pools & Lanes) in Conversation-Models. The Communication-Shape defines a set of logically related message exchanges which are tied to Pools via Conversation-Links. If there is a multi-instanced Pool (also introduced with BPMN 2.0) involved, a Forked Conversation-Link is used for it.

Furthermore Sub-Conversations can be used to define abstractions.

Choreography-Diagramm

Choreography-Models represent more detailled information than Conversation-Models. A Choreography-Model usually stands for exactly one Choreography whereas Conversation-Models implicitly hint at multiple Choreographies. Another important difference is that Choreography-Models do show the sequence of certain interactions, Conversation Models do not. Thus, contracts about communication can be arranged between process participants.

A Choreography-Task represents an interaktion between two process participants. Here it is distiguished whether a participant is initiating the communication (active part) or if it is just receiving. The party that starts the communication process is specified above or below the Choreography-Task in white whereas the receiving party will be denoted opposite to the initiating in grey. Optionally the initiating and the responding message can be modelled (white respectively grey letter symbol).

The modeler also can specify Choreography-Subprocesses which again resemble another Choreography. A slightly difference concerning notation is that more than one receiving party can be declared (but still only one initiating). The Choreography-Subprocess consists of Choreography-Tasks which involve two process participants; the Subprocess denotes all those participants that are involved in any of its Choreography-Tasks.

Choreography-Models consist of Choreography-Tasks und -Subprocesses alongside with most common BPMN elements (especially Gateways and Events).

Example:
This process shows the interaction between seller, buyer and auction house in a simplified auctioning process. To initiate the process, the Seller sends information about the product to be sold to the auction house. The auction house replies with an auction no. for the seller's product. When a potential buyer gets interested in the offered product, he can place an offer to the auction house. This is a looping process as there will usually be more than one offer and one potential buyer. If the product is sold the purchase process (here denoted as a subprocess) is initiated where buyer, seller and auction house are participants. If the product is not sold the seller has to be informed about it.