Re: Message Exchange Patterns State Diagrams

Arthur Ryman <[email protected]>
Newsgroups gmane.comp.web.services.description
Message-ID <OFA7C73983.9DC2CD31-ON85257249.0047CD93-85257249.0048CAC4@ca.ibm.com>
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: [email protected]



"Patric Fornasier" <[email protected]> 
Sent by: [email protected]
12/17/2006 08:01 PM

To
"[email protected]" <[email protected]>
cc
Arthur Ryman/Toronto/IBM@IBMCA, [email protected], 
[email protected]
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.