Re: [soa-rm-ra] Service Interaction Models (focusing on message exchange)

[Danny Thornton <danny_thornton2@yahoo.com>]

Hi Jeff,

I'll toss out some comments to kick off a discussion
about the service interaction view.  Thanks for
sending out the diagrams!

The Dynamic Interaction  Model shows the consumer
interacting with a Policy Enforcement Point (PEP) and
then the PEP sends a message to the Provider Agent. 
This seems to imply the PEP has its own rules engine
(similar to the way the Policy Decision Point is
commonly implemented) and is external to the provider
service.  I've seen the PEP modeled this way on other
projects.  I tend to think of the PEP as being
integrated into the business logic of the provider
service (or orchestration/composition thereof).  Other
thoughts on this?

Danny  

--- "Jeffrey A. Estefan"
<jeffrey.a.estefan@jpl.nasa.gov> wrote:

> 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.
> 
> 
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com