RE: [soa-rm] [Your Feedback, Please] FW: [soa-demo] RE: [soa-forum] SOA-

First off apologies for disappearance for a few weeks (months?).

Secondly to +1 on Ken’s comments, I’ve been working quite a bit recently with a few people who are looking to define their SOA approach and helping them move towards the RM definition as the basis of what they talk about. It is undoubtedly true that there are many other definitions which don’t quite match, but right now I’ve more confidence in our definition than in those others. We shouldn’t water down our definitions just to fit other existing elements as it will reduce the value of what we have created.

On some specifics from below, particularly focusing on actors.

From the perspective of a service everything that interacts with it is an actor, these actors may or may not be people they could be other services in the system, the distinction is mute from the perspective of the service. Where it will have an impact is at the technology implementation stage (e.g. don’t give your CEO a WSDL and expect him to do anything) but that is post Reference Model and into Architecture.

To go over the bit I like best about the RM over other proposals I’ve seen is that it can be applied not only to IT but also to pure business or human services. Adding in “community”, “roles” and “actors” in this way is (IMO) confusing as it sounds more like an HR department’s view of the world than an architects. From a comprehension perspective people equate (through UML and RUP) Actor with “person” rightly or wrongly this is the current view, it is also not clear from what is below whether a community on mass can be considered an actor as the definitions for actor and community are pretty similar (e.g. are the mighty Wolverhampton Wanderers first team an “actor” or a “community”, what would the club itself be?).

I disagree however with Ken on not using SOA for email … in sending this email I’ve interacted with our local Email Service (Iusing (sic) a proprietary interface) which has dispatched the email to the OASIS list server (another service this time using a standards based interface) which did the same to all of your email servers via a defined standards based interface and hence via your local service interface on to you J

From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: 18 April 2006 20:38
To: Chiusano Joseph; SOA-RM
Subject: Re: [soa-rm] [Your Feedback, Please] FW: [soa-demo] RE: [soa-forum] SOA-Demo Glossary / OASIS SOA-RMCommittee Draft

see inline

At 04:25 PM 4/17/2006, Chiusano Joseph wrote:

The e-mail below is from the listserv for the in-process SOA demo within the US Federal SOA CoP, which several of us participate in. I suggested on a recent call that our spec's terminology be used as a starting point in the demo and related conversations - below the demo lead (Cory Casanave) lists his observations regarding potential usage of our terminology.

Please feel free to provide feedback on this to our TC list, as it is regarding how our spec is potentially used. Let me know especially if you disagree with any of his observations, and I can pass those differences back to him.

Thanks,
Joe

Joseph Chiusano
Associate
Booz Allen Hamilton

700 13th St. NW, Suite 1100
Washington, DC 20005
O: 202-508-6514
C: 202-251-0731
Visit us online@ http://www.boozallen.com

From: soa-demo-bounces@colab.cim3.net [ mailto:soa-demo-bounces@colab.cim3.net] On Behalf Of Cory Casanave
Sent: Monday, April 17, 2006 1:37 PM
To: soa-demo@colab.cim3.net
Subject: [soa-demo] RE: [soa-forum] SOA-Demo Glossary / OASIS SOA-RMCommittee Draft

Thanks Joe,

Agree we need to use our terms consistently and in-line with evolving industry use (figuring out and agreeing on what that is may be the challenge)

I looked over the Glossary of the Oasis-RM, there is good match but a bit of a theme difference in that the Oasis document is very focused on “a service” where we tend to be more focused on an architecture of a set of services in a community.

I would relate the Oasis-RM terms to the terms in the document as follows;

{SOA} Service

[Oasis-RM] The means by which the needs of a consumer are brought together with the capabilities

a provider. See Section 3.1.

[Demo] Corresponds to “Service Interaction” in the document

[Suggestion] Ok with “service” but would prefer a qualification to avoid confusion with the generic term and use in the FEA. Perhaps we should use “SOA Service”.

The RM is for SOA so the context is very clear. What it does point out is that when others are talking generically about "service" and mixing in specifics on SOA service, those persons should be clear to which they refer.

{SOA} Service Interface

[Oasis-RM] The means by which the underlying capabilities of a service are accessed.

[Demo] Same

{SOA} Capability

[Oasis-RM] A real-world effect that a service provider is able to provide to a service consumer.

[Suggestion] A real world effect that an actor can provide to a community by playing a role in that community

While a service is available to a community, I believe the interaction is with a specific consumer and not the community as an aggregate consumer. Also, I can play a role in a community and have a real world effect without ever interacting with an SOA service. This email is such an example.

{SOA} Role

[Oasis-RM] Not Specified

[Suggestion] The responsibilities and behavior of an actor in a community that is realized, in part, by providing and/or using services. The role is specified in terms of responsibilities, capabilities and interactions.

The service is not aware of the role of the consumer beyond what must be identified to evaluate conformance to policy. It is not an RM concept as the details of policy are out of scope.

{SOA} Community

[Suggestion] A collection of actors that collectively realize business value by providing and/or using services. The community is specified by the purpose of the community and the roles various actors may play in realizing that purpose. Note that a community can be very large or as small as 2 actors.

See discussion under capability.

Other sources to be considered;

[RM-ODP] The basic concepts of RM-ODP Enterprise

language are object, role, community, objective, behavior and action. An

object is a model of an entity, either an entity of the system to be specified or

an entity of the system environment. Objects can be grouped to form a

community. In that case, they exhibit the behavior needed to realize the

objective of the community. By doing this, they fulfill roles of the

community since a role identifies a behavior. This is a set of actions with

constraints on when they appear. Actions can be interactions between

several objects or internal actions. Objects can model people, organizations or systems.

Other comments on the Glossary (not currently in demo, but may be)

Behavior Model

[Oasis-RM] The characterization of (and responses to, and temporal dependencies between) the

actions on a service.

[Suggestion] The characterization of (and responses to, and temporal dependencies between) the

actions of an actor on or in response to a set of services

From: soa-forum-bounces@colab.cim3.net [ mailto:soa-forum-bounces@colab.cim3.net] On Behalf Of Chiusano Joseph
Sent: Thursday, April 13, 2006 1:22 PM
To: Service-Oriented Architecture CoP
Subject: [soa-forum] OASIS SOA-RM Committee Draft

As discussed on our call today, I am sending out this spec for our reference in terminology and other areas.

Joe

Joseph Chiusano

Associate

Booz Allen Hamilton

700 13th St. NW, Suite 1100

Washington, DC 20005

O: 202-508-6514

C: 202-251-0731

Visit us online@ http://www.boozallen.com

--
     ---------------------------------------------------------------------------------
/   Ken Laskey                                                                \
|    MITRE Corporation, M/S H305    phone: 703-983-7934   |
|    7515 Colshire Drive                    fax:      703-983-1379   |
\   McLean VA 22102-7508                                              /
    ----------------------------------------------------------------------------------

soa-rm message