Some visual (UML/SysML) modeling suggestions for the SOA-RA

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

RA Team,

As far as visual modeling is concerned, specifically, UML 2 modeling, I 
suggest the following:

1) We model service participants (consumers and providers) as UML actors 
(either as classes with the "actor" stereotype or as stick figures, or both, 
depending on context of use)

2) We model agents, services, and mediators as UML components.  [Note: I'm 
grounding the concepts of participants (as well as stakeholders), agents, 
and services based on the attached conceptual model from Frank.]  Agents 
should use the "agent" stereotype and services should use the "service" 
stereotype.  Service components should also reflect UML 2 interfaces and 
ports and these should be labeled.  Some good examples of this are 
illustrated in the attached recommended UML Profile for SOA.  Mediators 
should use a stereotype the most closely matches its function, e.g., 
"registry" or "repository" or "discovery" just as an example.

3) We model the higher-level (end state) Service Description as a UML 
artifact.  We can do this one of three ways.  As 1) UML class with the 
"artifact" stereotype, my least favorite, 2) UML component diagram with 
"artifact" stereotype, or my preferred method, provided UML tooling support 
exists, 3) UML component using dog-eared tag notation.  Unfortunately, not 
all UML modeling tools support the latter today even though its part of the 
UML 2 spec.  This higher-level model of the service description can be used 
in our Interaction models, which we can illustrate with UML activity, 
sequence, and communication diagrams to model behavior.

4) We model architecture views and viewpoints based on the example depicted 
in the SysML 1 specification.  You can see an example of this applied to our 
work in the first figure of my initial write-up on interacting with services 
under TheArchitecture Wiki at:
http://wiki.oasis-open.org/soa-rm/TheArchitecture/Interaction .   You will 
need to log in to see the diagram.

5) Finally, that we decide as a team whether or not to include frames as 
part of our UML models.  The UML 2 spec does not mandate their use, but 
curiously, the SysML spec does.  This is not a big deal now but we'll need 
to settle on it before we go public with the first draft of the RA.

Modeling the conceptual model of the elements that comprise a Service 
Description should be modeled as a UML class diagram with the full set of 
associations between elements.

Currently, these are the major RM elements that are associated with the 
Service Description:

1) Information Model

2) Behavior Model

3) Service Reachability

4) Service Functionality

5) Service Interface

6) Contracts & Policies

Of course each of these elements, in turn, will need to be modeled.

There are some good examples of use of UML class diagrams for depicting 
information models.  See, for example, the following:

* ebXML Registry Information Model (ebXML RIM)
http://www.oasis-open.org/committees/regrep/documents/2.0/specs/ebrim.pdf

* Java API for XML Registries (JSR 93)
http://java.sun.com/xml/downloads/jaxr.html

(Leverages ebXML RIM and UDDI 2 data descriptions heavily)

* Modeling WSDL using UML
http://www.ftponline.com/javapro/2003_10/online/wsdl_aparikh_10_24_03/
http://ieeexplore.ieee.org/iel5/10610/33519/01592447.pdf?arnumber=1592447

With respect to principles associated with service descriptions and the 
minimum set of elements a service description should contain, there is a 
good discussion in the Newcomer/Lomow book (Understanding SOA with Web 
Services) pp. 109-117.  Due to copyright restrictions, I will not share them 
in this note.  I should point out that the authors actually use the term 
"service contracts" but the context in their use is really synonymous with 
what we mean by service descriptions.  There is some very useful reference 
material contained therein nonetheless, and more importantly (from pp. 
109-112), material that is not necessarily specific to Web services and WSDL 
contracts.

Duane mentioned a number of potentially useful abstract models as resources 
(e.g., WS-Policy) and I hope that he and the rest of the team will share 
these references in forthcoming e-mail notes and Wiki entries.

If you have additional questions with respect to modeling guidance.

Regards...

 - Jeff E.

UML-ProfileForSOA.pdf

stakeholder.png