OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Fwd: [soa-rm] for discussion - additional suggested changes to PR1 (Part 1)




Begin forwarded message:

From: Ken Laskey <klaskey@mitre.org>
Date: April 8, 2006 6:07:08 PM EDT
Subject: [soa-rm] for discussion - additional suggested changes to PR1  (Part 1)

This is the follow-up to the question I raised at the end of the last telecon on where to suggest other changes to PR1.  Many of these come over from the previous thread on "comments collected from SOA-RM presentation".  Hopefully, I've incorporated everyone's major points but I welcome the coming discussion to highlight any I missed ;-)

Note, this email does not include the two points requiring considerably more thought:
- how to rephrase (rename) shared state and its use with real world effect in lines 277-286 and in section 3.2.3
- arrows and their directions in diagrams
These are being worked separately; hence, the (Part 1) in the subject line.

1. Suggest incorporating some of the discussion of differences with OO by adding to lines 218-221 as follows:

Unlike Object Oriented Programming paradigms, where the focus is on packaging data with operations, the central focus of Service Oriented Architecture is the task or business function – getting something done. This distinction manifests itself in several ways:
  • OO has intentional melding of methods to a given data object.  The methods can be thought of as a property of the object.  For SOA, one can think of the services as being the access to methods but the actual existence of methods and any connection to objects is incidental.
  • To use an object, it must first be instantiated while one interacts with a service where it exists.
  • An object exposes structure but no way to express semantics other than what can be captured as comments in the class definition.  SOA emphasizes the need for clear semantics.
Both OO and SOA are as much a way of thinking about representing things and actions in the world as these are about the specifics of building a system.  The important thing is understanding and applying the paradigm.  So the question is not “what is a service?” any more than it is “what is an object?”  Anything can be a service in the same way anything can be an object.  The challenge is to apply the paradigms to enhance clarity and get things done.  SOA provides a more viable basis for large scale systems because it is a better fit to the way human activity itself is managed – by delegation.

2. Suggest incorporating extra description for execution context by adding to lines 662-669 as follows:

The execution context of a service interaction is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction, and thus forms a path between those with needs and those with capabilities.

As discussed in previous sections of this document, the service description (and a corresponding description associated with the service consumer and its needs) contains information that can include preferred protocols, semantics, policies and other conditions and assumptions that describe how a service can and may be used.  The participants (providers, consumers, and any third parties as noted below) must agree and acknowledge a consistent set of agreements in order to have a successful service interaction, i.e. realizing the described real world effects.  The execution context is the collection of this consistent set of agreements.

The consumer and provider can be envisioned as separate places on a map and, for a service to actually be invoked, a path must be established between those two places.  This path is the execution context.  As with a path between places, it can be a temporary connection (e.g. a tenuous footbridge of an ad hoc exchange) or a well-defined coordination (e.g. a super highway) that can be easily reused in the future.

3. Suggest incorporating aspects of point 8 in the comments email by adding a paragraph between lines 165 and 166 (paragraph ending with line 165 and the one beginning with line 166 are included for context):

SOA is a means of organizing solutions that promotes reuse, growth and interoperability. It is not itself a solution to domain problems but rather an organizing and delivery paradigm that enables one to get more value from use both of capabilities which are locally “owned” and those under the control of others.  It also enables one to express solutions in a way that makes it easier to modify or evolve the identified solution or to try alternate solutions.  SOA does not provide any domain elements of a solution that do not exist without SOA.

Note that while an SOA service brings together needs and capabilities, the provider of the underlying capability may not be the same entity that eventually provides the service which accesses that capability.  In reality, the entity with the domain expertise to create maintain, and evolve a given capability may not have the expertise or the desire to create, maintain, and evolve its service access. 

The concepts of visibility, interaction, and effect apply directly to services in the same manner as these were described for the general SOA paradigm.  Visibility is promoted through the service description which contains the information necessary to interact with the service and describes this in such terms as the service inputs, outputs, and associated semantics.  The service description also conveys what is accomplished when the service is invoked and the conditions for using the service. 

4. Suggest incorporating aspects of point 9 in the comments email by adding a sentence at line 232 (paragraph ending with line 232 included for context):

First, SOA reflects the reality that ownership boundaries are a motivating consideration in the architecture and design of systems.  This recognition is evident in the core concepts of visibility, interaction and effect.  However, SOA does not itself address all the concepts associated with ownership, ownership domains and actions communicated between legal peers. To fully account for concepts such as trust, business transactions, authority, delegation and so on – additional conceptual frameworks and architectural elements are required.  Within the context of SOA, these are likely to be represented and referenced within service descriptions and service interfaces.  The presence of service descriptions and service interfaces provides a ready location for including such references and thus facilitates reuse of externally developed frameworks and interoperability among systems availing themselves of this reuse.




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




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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]