Re: [soa-rm-ra] SOA-Pro & Core Concepts

[Rex Brooks <rexb@starbourne.com>]

Thanks Jeff,

This is very helpful, as I'm sure Dave's matrix will be, too.

I decided to dig into this and the OMG ontology simultaneously since 
both look like they're gonna give me a largish headache. The big 
problem with domain-specific ontologies is that if they don't cite 
their teleological parents, e.g. the upper ontology or ontologies 
from which they wish to claim descent or which they assert as 
foundational, we run into a number of thorny issues  before we even 
begin to look at the classes and their relationships. My reference to 
Teleology is aimed at the cybernetic context and history, not the 
theological context and history.

It's almost certain to take me a while to slog through this, so I 
should be able to take most other comments into account, too.

Cheers,
Rex

At 2:32 PM -0700 7/25/08, Jeffrey A. Estefan wrote:
>Frank and Team,
>
>Ignoring the diagrammatic elements that comprise the UML Profile 
>part of SOA-Pro for the moment, and just focusing on their 
>definition of core concepts like "Participants" and "Services," I 
>think we should try and take the opportunity to be good stewards and 
>harmonize our efforts.  Otherwise, if we go for standardization of 
>our RA and OMG has already standardized on SOA-Pro, I think we will 
>be doing a disservice to the community of practice out there if we 
>don't have at least the spirit of alignment.
>
>SOA-Pro defines core concepts as follows:
>
>Service Oriented Architecture - An architectural paradigm for 
>defining how people, organizations and systems provide and use 
>services to achieve results.
>
>This seems fairly consistent with our definition in the RM.
>
>Service - A capability offered by one entity or entities to others 
>using well defined "terms and conditions" and interfaces.
>
>Again, more or less consistent with our definition in the RM.
>
>Participants - Types of actors defined both by the roles they play 
>in services architectures and the services they provide and use. 
>Participants can represent software components, organizations, 
>actors, or individuals.
>
>Slight divergence from our definition in the RA.  We of course do 
>not explicitly define Participants in the RM.  Notice the use of 
>"roles!"  I think it is critical to get this into our models, 
>whether we add an additional abstract concept such as "Actor" or 
>not.  Personally, I don't really think we need to add that 
>additional complexity as long as we cover roles in our Participants 
>definition.
>
>In addition, in the RA, we distinguish Stakeholders from Participants.
>
>SIDEBAR QUESTION FOR FRANK:  Can you provide an example of a 
>non-human Stakeholder per our definition of Stakeholder?
>
>Yet to be resolved are Agents.  While Agents are described all over 
>the SOA-Pro metamodel section (Part II), I did not see any formal 
>definition of Agents in Part I of the spec.  Actually, not even in 
>Part II.  This is a topic that will require further investigation.
>
>Services Architectures (or SOA) -  A network of participant roles 
>providing and consuming services to fulfill a purpose.  Puts a set 
>of services in context and shows how participants work together for 
>a community or organization.
>
>Not explicitly defined in the RM or RA, at least not according to roles.
>
>Community Services Architecture - A "top level" view of how 
>independent participants work together for some purpose.
>
>Some elements of this concept in our Social Structure models in the RA.
>
>Service Contract - Defines the terms, conditions, interfaces and 
>choreography that interacting participants must agree to (directly 
>or indirectly) for the service to be enacted - the services contract 
>is the full specification of a service which includes all the 
>information, choreography and any other "terms and conditions" of 
>the service.
>
>Seems a little like our notion of Execution Context defined in the 
>RM, but not quite.  Does get at what Michael Poulin has been talking 
>about.  Not yet sure how to deconstruct this as of yet.  SOA-Pro 
>does not call out either Execution Context or Service Contract in 
>Annex B (Conformance to OASIS RM).
>
>There is some discussion of choreography.  They're very brave to 
>take on this term because of its inherent baggage, but they define 
>it as follows:
>
>Choreography - A specification of what is transmitted and when it is 
>transmitted between parties to enact a service exchange.  The 
>choreography specifies exchanges between parties - the data, assets 
>and obligations that go between the service participants and any 
>other service interface.  (Dave Ellis should like this.)
>
>The discussion on Service Interface is extensive and somewhat 
>complex so I won't capture it in this e-mail thread.
>
>Participant Services Architecture - A class that is expected to have 
>its external contract defined in some other portion of the model, 
>resulting in a port, and its internal composition described using 
>Service Contracts.
>
>This seems more along the lines of the UML Profile than a core 
>concept so we should let this one slide for the moment.
>
>Those are the core concepts in SOA-Pro I found.  Perhaps others have 
>found additional ones.  In any event, I think it would be wise to 
>reconcile our differences; particularly with respect to the RA 
>concepts, which are still in work.  The RM remains the guiding 
>standard for both sets of specs.
>
>Cheers...
>
>  - Jeff, JPL
>
>
>
>
>
>
>
>
>
>
>


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670