Most of us seem to disagree with you, Joe.
Sorry.
-matt
From: Chiusano Joseph
[mailto:]
Sent: Monday, December 12, 2005
10:32 AM
To:
Subject: RE: [soa-rm] Joe's
Proposed New Organization for Committee Draft 10 (and next Committee Draft)
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
