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: RE: [soa-rm] Joe's Proposed New Organization for Committee Draft 10 (and next Committee Draft)

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.
Joseph Chiusano
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:chiusano_joseph@bah.com]
Sent: Sunday, December 11, 2005 9:43 PM
To: soa-rm@lists.oasis-open.org
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:



- Keep as is.




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.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 (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). – Visibility


- See lines: 159-164. – Interaction


- See lines: 165 -171. – 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 – Exchange


- See lines: 166-168, 479-484

- NOTE: Not much information in spec on the Exchange concept; recommend expanding

the explanations of this concept. – Execution Context


- See lines: 168-171, 622-642.


3.3.4 – Service


- See lines: 183-219, 266-280, 306-339 – 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. – Visibility


- See lines: 195-197, 280-282, 731-741. – Interaction


- See lines: 286-294. – 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.




- 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 – Idempotency


- See lines: 594-604. – Long-Running


- See lines: 605-616. – Transactionality


- See lines: 617-620.

- NOTE: Recommend more discussion of this aspect (treated very lightly here).




- Keep as is.




-          Keep as is.




- Keep as is.




- Keep as is.




- Keep as is.





Joseph Chiusano


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




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