Service Interaction Models (focusing on message exchange)

["Jeffrey A. Estefan" <jeffrey.a.estefan@jpl.nasa.gov>]

RA Colleagues,

Before I invest time and energy into documenting aspects of the Service 
Interaction model, i.e., "Interacting with Services" (part of the Realizing 
a SOA view), I'd like to share three visual models with you and get your 
take.  I recognize the holiday season is upon us so perhaps we can discuss 
these models during one of our early '07 telecons.  Because some of you are 
UML savvy and others are not, I will certainly explain the semantics of the 
diagrams during a future telecon.  I am not going to take the time to 
explain each and every UML classifier and connector here.

Notes: These diagrams represent the static and dynamic models associated 
with information/message exchange as part of Interacting with Services. 
None of these models depict any interaction with a mediator such as a 
service registry-repository to facilitate discovery, i.e., it is assumed as 
a pre-condition that awareness has been established and that the service 
description is available to the service consumer for processing.  The notion 
of "intermediary" is introduced in two of the models (to model Policy 
Enforcement Point).

The first diagram is a UML 2 communication diagram that represents the 
Dynamic Model of a Standard Atomic Service Interaction.  In other words, 
this model represents the most general interaction pattern that should be 
applicable to most SOAs, particularly rule-based, policy-driven SOAs.  I 
will let you digest the diagram and not document each step here.  Like I 
said before, I need to make sure we're all on the same page before investing 
too much time in a formal writeup.  I should note that physical elements 
associated with network infrastructure (e.g., transport layer, routers, 
etc.) and middleware were purposely omitted from the model.  Frankly, I 
don't think they're necessary for an RA of this level (however, they are 
important for concrete architectures).  Also, if we keep the third diagram 
described below, we can probably drop the stereotypes.

Working backward starting with run-time and then focusing on design-time, 
the next model is a UML 2 component diagram that reflects the Meta-Level 
Artifacts of Describing Services, which models the required information 
needed to facilitate message exchange between consumer and provider agents. 
Note that this is very legal (normative) UML yet many UML tools do not 
support the notion of multiple compartments with stererotypes, which is why 
I modeled these in Visio vice MagicDraw.  The Visibility and Service 
Description team should review this model.

The final diagram is a UML 2 class diagram that represents the Static Model 
of a Standard Atomic Service Interaction.  Although helpful to illustrate 
the key concepts necessary for message exchange, I personally have some 
problems with this model.  First, it blurs the design-time with the run-time 
aspects of service interaction.  Second, in SOA practice, the service 
interface is more properly represented (i.e., modeled) as an artifact so it 
can be used at design-time.  Nevertheless, the attached model does 
illustrate the provided and required interfaces.  The important thing 
reflected in this model is the fact that the service is "realized" by the 
provider agent.  This is often a point of confusion when I talk about SOA 
with various projects, customers, etc.  This is due in large part to those 
oversimplified and overused "publish-find-bind" triad diagrams.  Anyway, 
it'll be up to this RA community to decide whether or not this particular 
visual model is useful model or if it just muddies the water.

Looking forward to your comments and discussion.

Everybody please, have a safe and happy holiday!

Regards...

 - Jeff E.

Interaction_Collaborators.png

Interaction_Meta-Level_Artifacts.png

Interaction_Dynamic_Model-Atomic.png