| Jeff,
Thanks for the thorough mapping. I'm happy to see that most things reasonably align, although I expect agreeing on exact words will be difficult. Below I inserted some thoughts on similarities and differences.
Ken On Jul 25, 2008, at 5:32 PM, 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.
I've gone round and round with Dave on this and (if I remember accurately) tried to clarify in my suggested changes to section 3. Roles can be set top down by the Social Structure or recognized bottoms-up based on Skills and Qualifications. As an example of the latter, no structure defined the role of greatest baseball player ever, but consensus often recognizes Babe Ruth as occupying that role. Many "experts" are recognized rather than assigned. There is also the mixed mode where the Structure can define the role but the bottoms-up consensus recognizes how or whether that role is filled. 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).
Service Contract often conflates Service Description and Execution Context. The problem is some aspects of the Execution Context are not static and so cannot unambiguously be cited before the service interaction. For example, a service provider can specify preferred Ts&Cs but there may be some negotiations with the consumer -- the resulting agreements go into the execution context. Their "choreography" sounds like our Process Model.
BTW, from section 4.1 of the RA PR!:
This
Reference Architecture uses the term service description for consistency with
the concept defined in SOA-RM.
Some of the current SOA literature speaks to the idea of a "service
contract" as effectively the equivalent, although the details of what
comprises the service description/contract may vary. The term service description is preferred because policies
are an element of description for any resource and the agreement on policies
between service participants may be thought of as a contract. Saying service contract for the service
description implies just one side of the interaction is governing and misses
the point that a single set of policies identified by a service description may
lead to numerous contracts, i.e. service level agreements, leveraging the same
description. Indeed, these
agreements establish the execution context of the service interaction and are
not a fundamental attribute of the service itself.
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.)
What they miss is the P2P nature, and this could also be construed as orchestration. Is that intended? 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
------------------------------------------------------------------------------------------ Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508 |