Service Interface Model (graphic attached)

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

Colleagues,

 

OK.  Here's my take on a visual model representation for Service Interface (see attached).  I also uploaded a copy to our Kavi site.

 

It's consistent with the RM and the RA and should serve as a candidate replacement for the current Fig. 20 on pg. 41 of the WD 0.3 baseline dated Mar. 4, 2008.  The text of Section 4.1.1.2.1 needs to introduce the notion that visibility has a role to play in the Service Interface (via service Reachability).  This is consistent with the original intent of Fig. 20 but the bullet points currently do not reflect this fact.

 

I chose to use the Class classifier in MagicDraw with the <<interface>> stereotype rather than the MD Interface classifier, which is non normative against the UML 2.1.2 standard.  Very frustrating at some of these tool embellishments and also its limitations (compartments for example).

 

Also, in an attempt to be consistent with Ken's modeling of the Service Description artifact at a higher level of abstraction, I chose to model Service Interface as a Class Diagram rather than a Component/Artifact Diagram.  We can debate the aggregate associations as to whether or not they are loosely coupled aggregates or tightly coupled composite relationships.  I'm open to that discussion but we shouldn't dwell on it.

 

I believe Michael is going to take a crack at updating elements of Sections 4.1.2.2.2 and 4.1.2.2.3; however, we need to be very careful not to introduce new concepts that are not consistent with the Interacting with Services Model or even the RM in what we mean by Action (and Events).  Also, we need to be crystal clear that we use the concept of Service Description (an artifact) to as COMPLETELY AS POSSIBLE to describe a service; we do not use other terms floating around the cyberether like "Service Contract" as synonymous with Service Description.  The latter term is pretty common in the various SOA textbooks out there and one can argue a holdover concept from the older distributed object computing standards out there like CORBA IDL.  Our notion of Service Contract is very, very specific and is clearly articulated in the RM.  In the RA, it is modeled as part of the Policies and Contracts Model element of the Realizing SOAs View.

 

It would be nice to zero in on some consensus to a reasonable model for Service Interface before our tutorial at the OASIS Composability symposium.

 

Cheers...

 

 - Jeff E., JPL

 

 

Service_Interface.png