Benefits of Choreography modeling in a SOA
[ad]
First, what is a Choreography Model? Spoken in general terms it does model the participants of a message exchange, the messages exchanged (not necessarily the structure of the message), which interactions (message exchanges) are desiged betreen the participants, who is the initiator of an interaction, and which interactions follow on which other interactions.
The benefits of modeling a Choreography are the general benefits of doing a design for anything. It gives transparency. It results in quality, because of clear-cut statements of the boundary conditions, if fosters collaboration by forcing to discuss the message exchange contract. It can be simulated and thereby problems can be found before implementation and the consistency can be checked with other models – especially process models of the participants.
Sending messages at unspecified points in time between participants and hoping, that they will somehow be processed may seem easier in the beginning, but experience shows, that this does not pay back. Error handling is especially difficult in distributed SOA landscapes. Therefore giving the interaction a backbond and skeleton by modeling it in the first place, is key to success.
This model could even be used in the runtime by letting systems validate messages that arrive or are being sent against the model. By this two things happen: (1) The quality of the model is forced to be on the highest level (in contrast to “just a drawing”) and (2) messages sent or received at the wrong time can be identified as contract violations (instead of clumsy debugging of the application coding).
