[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] for discussion - additional suggested changes to PR1 (Part 1)
I
concur with all of Ken's suggestions below - they lend great additional clarity
to the spec.
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: Ken Laskey [mailto:klaskey@mitre.org] Sent: Saturday, April 08, 2006 6:07 PM To: SOA-RM 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:
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]