All,
I have been asked to
re-clarify my suggestion for improving the organization of our spec (though I
recall that Ken Laskey and others responded that they noticed the same, shortly
after my December 4th e-mail). There is such a wealth of excellent information
(and I mean it is really top-notch, and ultra-high quality) in our current
Committee Draft 10. At the same time, I believe that the information is not
organized in the best manner, as there are concepts scattered throughout that
can be "blended together" in a single section (e.g. see "Reachability" at end, and
an earlier discussion, see "Services" discussed on line 183 and 266, etc.), and
in general, I believe that we can help the reader by "modularizing" the
information better and having a better flow. So I am simply
hoping that we can address
this now, for our next draft. That's
all.
Hope that
helps.
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: Chiusano Joseph
[mailto:]
Sent: Sunday, December 11, 2005
9:43 PM
To:
Subject: [soa-rm]
Joe's Proposed New Organization for Committee Draft 10 (and next Committee
Draft)
I just uploaded a Word document to
Kavi that contains my proposal for a new organization forour Committee Draft 10, with the
intent that this proposed new organization (or something similar) would be
reflected in our next Committee Draft. In case the upload did not work, I have
also reproduced the contents of the proposal below.
I include line numbers
from Committee Draft 10 to indicate the text that would be placed in the
various sections/subsections.
Here it is - please let
me know if you have any questions. I hope you find that it flows
nicely:
1 -
INTRODUCTION
- Keep as
is.
2 – SERVICE ORIENTED
ARCHITECTURE
2.1 – What is
SOA?
- Keep lines 148-157 only – defer
rest of section until later.
- Also include lines: 205-219,
261–263.
2.2 – How is Service Oriented
Architecture different?
- Keep as
is.
2.3 – The Benefits of Service
Oriented Architecture
- Keep as
is.
3 – THE SOA REFERENCE
MODEL
3.1 – Overview of
model
- Present figure depicting the SOA
Reference Model (line 158 figure in whatever updated form we
use).
- Mention the concepts that
comprise the reference model and the relationships between them by presenting
the concepts in a narrative paragraph with each concept name in bold. For
example: “The central concept in the SOA reference model is a service. A
service represents the capability to…A service description contains the
information necessary to interact with the service…etc.
- State that the concepts will be
discussed in detail later in the spec – i.e. do not define them here, or go
into in-depth discussion. Give the reader just enough here to make them want
to continue reading (don’t tell them too much too soon).
3.2 – Guiding
Example
- Present the example from section
3.2.2.5 (lines 417-439) here. Tell the reader that it will help them better
understand the concepts that comprise the reference model (as well as related
concepts) as they are discussed later in the spec.
3.3 – Discussion of reference
model concepts
- Discuss each individual concept
that comprises the reference model in this section.
- Include an introduction here
that explains this.
- Consider including a smaller
version of the reference model figure for each concept subsection, and
highlighting that concept (e.g. with a red square) so that the reader can see
where they are in the navigation through the reference
model.
3.3.1 –
Capabilities
- A general discussion of
capabilities and their relation to SOA (extract from various places in the
spec, and elaborate where appropriate).
3.3.2 – Visibility, Interaction,
and Real World Effects
- Provide an introduction to these
3 concepts, and discuss each separately below (see lines 159-182 of
spec).
3.3.2.1 –
Visibility
- See lines:
159-164.
3.3.2.2 –
Interaction
- See lines: 165
-171.
3.3.2.3 – Real World
Effects
- See lines:
172-182.
3.3.3 – Exchange and Execution
Context
- Mention that these concepts are
closely related to Interaction, as they are run-time
concepts
- Provide an introduction to these
2 concepts, and discuss each separately below
3.3.3.1 –
Exchange
- See lines: 166-168,
479-484
- NOTE: Not much information in
spec on the Exchange concept; recommend expanding
the explanations of this
concept.
3.3.3.2 – Execution
Context
- See lines: 168-171,
622-642.
3.3.4 –
Service
- See lines: 183-219, 266-280,
306-339
3.3.4.1 – Visibility, Interaction,
and Real World Effects
- State that these concepts, which
were discussed above for capabilities, will now be discussed as they relate to
services.
3.3.4.1.1 –
Visibility
- See lines: 195-197, 280-282,
731-741.
3.3.4.1.2 –
Interaction
- See lines:
286-294.
3.3.4.1.3 – Real World
Effects
- See lines: 295-296,
643-650.
3.3.5 – Service
Description
-
Recommend presenting a figure that
depicts the components of the service description (with the caveat that some
will be discussed in later sections):
o
Data
Model
o
Association of constraints and
policies with service
o
Service
Interface
o
Description of service
functionality
o
Etc.
- See lines: 197-199, 282-285,
340-368, 374-394
3.3.6 –
Policy
- See lines: 395-403, 674,
684-715.
4 – RELATED
CONCEPTS
- Discuss concepts related to
those that comprise the reference model, but do not actually appear as
concepts in the reference model.
- NOTE: If any of these concepts
are subsequently added to the reference model, they would simply need to be
moved to Section 3.3 (i.e. a subsection of Section 3.3 would need to be
created).
4.1 – Service Providers and
Consumers
- See lines: 199-204,
297-304.
4.2 – Service
Interface
- See lines:
404-416.
4.3 –
Metadata
- See lines:
440-477.
4.4 – Data
Model
- See lines:
488-499.
- Have 2 subsections (“Structure
of Information” and “Semantics”), per the discussion on lines
495-499.
4.4.1 – Structure of
Information
- See lines:
500-507.
4.4.2 –
Semantics
- See lines: 508-547 (includes
discussion of Ontology, but I recommend not including “Ontology” in the
subsection heading as “Semantic” suffices as the general
topic).
4.5 – Service
Contracts
- See lines: 674-683,
716-730.
- NOTE: Though the heading on line
675 is “Policies and Contracts”, lines 676-683 are more about contracts than
policies. That is why these lines are included here, and not under
“Policy”.
4.6 – Awareness, Willingness, and
Reachability
- Provide an introduction to these
3 concepts, and discuss each separately below
4.6.1 –
Awareness
- See lines:
742-765.
4.6.2 – Willingness
- See lines:
766-778.
4.6.3 -
Reachability
- See lines: 369-373,
779-787.
4.7 – Processes and
SOA
- Provide an introduction here to
the various models, and discuss them in separate subsections
below
4.7.1 – Behavioral
Model
- See lines:
548-565.
4.7.2 – Action
Model
- See lines:
566-576.
- Also discuss the notion of
“shared state” here – see lines: 651-672.
4.7.3 – Process
Model
- See lines:
577-588.
- Mention that there are 3
higher-order service attributes that will be discussed in subsections
below
4.7.3.1 –
Idempotency
- See lines:
594-604.
4.7.3.2 –
Long-Running
- See lines:
605-616.
4.7.3.3 –
Transactionality
- See lines:
617-620.
- NOTE: Recommend more discussion
of this aspect (treated very lightly here).
5 – CONFORMANCE
GUIDELINES
- Keep as
is.
6 –
REFERENCES
-
Keep as is.
APPENDIX A
- Keep as
is.
APPENDIX B
- Keep as
is.
APPENDIX C
- Keep as
is.
[THE
END]
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
