The role of Choreography modeling in a SOA

[ad]
A SOA consists of Process Components, each of which fulfil a certain business functionality, that interact with each other. One possibility is that a Composite Application does call Services of an underlying Business Process Platform – be it synchronously or asynchronously. Another possibility is, that Process Components of an unterlying Business Process Platform communicate with each other by mainly asynchronous web services. Examples for the first were mentioned above while examples for the second could be a Process Component for Supplier Relationship Management including Purchasing and a Process Component for handling the Delivery, that exchange asynconous XML messages with each other. Another example is the message exchange between a seller and a buyer.
The modeling of a choreography can adress both purposes. It does focus on the exchange of the messages alone – i.e. internal details of the process components are not modeled in such a model.
However it can server as a Top-Down Design methodology – if new Process Components will need to be designed, or – it can serve as a contract between two communication participants, that are adapted to the message exchange.