| Good work Jeff!
Some thoughts and responses inline: On Jul 25, 2008, at 2: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.
I agree, that we should try to do this where it makes sense.
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.
We focus on needs as well as capabilities. 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 the interests of making some progress, I would like to defer the discussion and definition of roles. However, we probably need to account for both the top-down and the bottom-up view of role 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?
The government is a classic non-human (inhuman?) stakeholder. In a lower level scenario, a SOA-based management system may be populated with agents that are monitoring services. The agents' owners are presumably stakeholders, but so, in a way, are the management agents themselves - according to the definition of stakeholder: an entity with an interest in the state of services and the outcome of service interactions.
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.
Do we need this concept?
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.
Ditto? We have not tried to classify instances of SOA-based systems. 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).
Agree with Ken's remarks. 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.)
I get an allergic reaction reading this definition of choreography.
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
In summary, what are the concrete takeaways?
Frank |