[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Joe's Proposed New Organization for Committee Draft 10 (and next Committee Draft)
Joe, This is not the process for making changes
to the specification. We have a well defined process for proposing change. -Matt From: Chiusano Joseph
[mailto:chiusano_joseph@bah.com] 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 O: 202-508-6514
C: 202-251-0731 Visit us online@ http://www.boozallen.com |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]