Re: Message Exchange Patterns State Diagrams

Patric,

As I mentioned, a state diagram is very abstract. A MEP describes message 
exchange which is precisely what a Sequence diagram shows. Yes, it shows 
one particular exchange, but the MEPs aren't that complex. They have one 
mainline exchange and perhaps one other one for the Fault case. So two 
diagrams per MEP would work.

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca



"Patric Fornasier" <patric.fornasier@gmail.com> 
Sent by: www-ws-desc-request@w3.org
12/17/2006 08:01 PM

To
"paul.downey@bt.com" <paul.downey@bt.com>
cc
Arthur Ryman/Toronto/IBM@IBMCA, www-ws-desc@w3.org, 
www-ws-desc-request@w3.org
Subject
Re: Message Exchange Patterns State Diagrams







Hi Arthur and Paul,

Thanks for your replies.

> (Arthur)
> I think it is clearer to show the interactions using UML Sequence 
Diagrams.

I'm not sure if a Sequence Diagram is the right tool to model the
patterns. Sequence Diagrams are very specific and can only show one
execution path of a pattern at a time, whereas state diagrams allow to
capture multiple valid exchange patterns in a concise way.

Imagine a simple pattern such as the "in-out" for example. The out
message can be either a normal SOAP message containing application
data or it can be a SOAP fault. In a sequence diagram you can not
capture conjunctions (SOAP message OR SOAP fault) and hence you'd have
to draw 2 sequence diagrams, each one capturing the very specific
case. Of course for modeling a bit more complex patterns such as
in-optional-out, you'd end up with even more specific sequence
diagrams.

> (Paul)
> I though they showed a particular implementation,
> also a service might have other states, events
> and exchange messages to other parties.

No, they don't show a particular implementation. They represent the
perspective of ONE service. Of course a service can communicate with
different parties at the same time and thus be at different states at
the same time, because it will have a different state machine instance
for each session!

> (Paul)
> I might model my service very differently but still
> conform to a particular MEP.

I'm not sure if I can follow you on this. What is the criteria then
that you conform to a particular MEP if not the exchanged messages?!?
Could you maybe give me an example of what you mean?

Cheers,
patric