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] Related to Proposed Reorganization of Our Spec: SOA-RM "First-Class" Concepts


So you're creating the reference model for organizing the document and this can lead to multiple possible document organizations?

Too many emails to too many BAH people.

Night all.

Ken

On Dec 7, 2005, at 10:23 PM, Chiusano Joseph wrote:

Ken,
 
All true. In our case, I believe there is too much sprinkling, to the point that it's difficult to follow and absorb. So this analysis is simply an interim step on the way to my proposed new organization, and it may also be used to come up with alternate organizations as well (as I don't automatically assume that my proposed new organization will be adopted, of course).
 
Joe


From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: Wed 12/7/2005 10:20 PM
To: Chiusano Joseph
Cc: soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] Related to Proposed Reorganization of Our Spec: SOA-RM "First-Class" Concepts

Joe,

The purpose of an index in the back of a book is that descriptions of and references to a concept are often sprinkled throughout the text.  True, there is usually a small number (relative to the total number of references) of "core" descriptions, but these may also be distributed so as to be explained in the appropriate place/context.  This is not to say your analysis may not be valuable, but it may not in itself provide a satisfactory answer.

Ken

On Dec 7, 2005, at 9:58 PM, Chiusano Joseph wrote:

I am in the process of proposing a new organization to our spec, based on some of the recent e-mails we have been exchanging. In order to get to that proposed new organization, I've decided to go through the entire spec and pull out what I would call "first-class" concepts whose discussion we may wish to consolidate into one section/subsection so that readers can jump right to those concepts (though I recognize that sometimes one needs to describe certain concepts in pieces).

 

To that end, I've begun developing a list of "first-class" concepts - please see the analysis below (search on "ANALYSIS" - I've gone through half of the main part of the spec so far). In the analysis, I've basically reproduced each section/subsection heading, and listed groups of lines and what they cover. So for example, under Section 2.1 below you will see the following:

 

<Quote>
Lines 159-163: Visibility
-          Lines 161-163: Metadata, constraints, policy
</Quote>

 

This indicates that on lines 159-163, the "first-class" concept of "visibility" was discussed. Also, within that line range, on lines 161-163, the "first-class" concepts of "metadata", "constraints", and "policy" were discussed.

 

I am being careful to use the same terminology throughout the list - i.e. always "policy", not "policy" sometimes and "policies" other times.

 

What this will allow us to do, of course, is to take the information below and organize it by first-class concepts (perhaps in a spreadsheet), with the line numbers associated with each concept. Taking "metadata" as an example, in the information below we see that "metadata" is discussed on the following lines:

 

- Lines 161-163
- Lines 163-164
- Line 179
- Lines 316-320
- Lines 341-345

 

This will also enable us to examine all of these occurrences and ensure that we speak consistently about metadata in each case (i.e. that there are no contradictions). So the analysis below is the interim step to arriving at this. I will also use these line numbers for the proposed new organization.

 

Regarding the line numbers: I am using "an entire sentence" as the smallest reference. So if a sentence spans 3 lines, and there is a mention of a concept on the 2nd of those 3 lines, I list the range for all 3 lines.

 

Please stay tuned for the final result (shortly)....

 

Joe

  

ANALYSIS:

 

1 - INTRODUCTION:
 
Lines 82-87: Introduction
-          Lines 84-87: Patterns, reference architectures
 
1.1 – What is a reference model
 
Lines 89-94: What is a reference model
-          Lines 89-91: Specific architectures
Lines 95-97: Purpose of a reference model
Lines 98-101: Goal of this reference model
Line 102: “Relations” figure (SOA Implementations, etc.)
 
1.2 – Audience
 
Lines 104-112: Audience
 
1.3 – How to use the reference model
 
Lines 114-133: Summary of document
 
1.4 – Notational Conventions
 
Lines 135-137: Notational Conventions
 
1.5 – Relationships to other standards
 
Lines 139-145: Relationships to other standards
 
2 – SERVICE ORIENTED ARCHITECTURE:
 
2.1 – What is SOA?
 
Lines 148-155: What is SOA?
Lines 155-157: The perceived value of SOA, matching
Line 158: Puzzle figure
Lines 159-163: Visibility
-          Lines 161-163: Metadata, constraints, policy
Lines 163-164: Metadata, semantics
Lines 165-171: Interaction
-          Line 165: Matching
-          Lines 168-171: Context, policy, contracts
Lines 172-182: Real world effects
-          Lines 174-177: Public vs. private actions
o        Lines 175-177: State
o        Lines 176-177: Context
o        Line 178: Preconditions
o        Lines 178-180: Matching
o        Line 179: Metadata
Lines 183-204: Service
-          Lines 195-196: Service description
o        Line 197: Inputs, outputs, semantics
o        Line 198: Conditions
o        Lines 199-200: Service provider
o        Lines 200-201: Service consumer
-          Lines 207-208: Ownership
-          Lines 209-210: Web services
-          Lines 211-219: Coupling/granularity
o        Lines 217-219: Interface
 
2.2 – How is Service Oriented Architecture different?
 
Lines 221-240: How is Service Oriented Architecture different?
-          Lines 224-230: Ownership
-          Lines 217-219: Interface
-          Lines 231-232: Organization of IT assets, matching
-          Lines 237-240: Object Oriented Programming
 
2.3 – The Benefits of Service Oriented Architecture
 
Lines 242-259: The Benefits of Service Oriented Architecture
-          Lines 242-245: Main drivers for SOA
-          Lines 246-250: Value of SOA
-          Lines 252-253: Ownership
-          Lines 255-259: Scale/evolve, processes, infrastructure, agility
o        Lines 256-258: Interface
 
3 – THE REFERENCE MODEL:
 
Lines 261-263: What is SOA?
-          Lines 261-263: Discovery, real world effects, preconditions, expectations
 
3.1 – Overview of model
 
Lines 266-304: Service
-          Line 273: Offer
-          Line 277: Offer, interaction, real world effects
-          Lines 278-285: Offer
o        Lines 280-282: Service visibility
o        Line 285: Service description
-          Lines 286-294: Interaction
o        Line 287: Service provider, service consumer
o        Lines 290-291: Interface, behavior
o        Lines 291-294: Ownership
-          Lines 295-304: Real world effects
o        Lines 297-301: Ownership
o        Line 301: Security
o        Lines 302-303: Conditions, expectations
o        Lines 303-304: Conditions, policy, contracts
 
3.2 – The Reference Model
 
3.2.1 – Service
 
Lines 307-339: Service
-          Lines 307-309: Interface, constraints, policy, service description
-          Lines 309-311: Service provider
-          Lines 312-313: Interface
-          Lines 313-314: Constraints
-          Lines 315-316: Processes
-          Lines 316-320: Opacity, data model, interface, metadata, service consumer
-          Lines 321-324: Real world effects
o        Line 323: State
-          Lines 325-327: Service consumer, state
-          Lines 327-330: Service consumer, errors, input, output, data model, interface
 
3.2.2 – Service description
 
Lines 341-439: Service description
-          Lines 341-345: Metadata
o        Lines 344-345: Context
-          Lines 346-348: Data model, policy
-          Lines 349-351: Service description format, discovery
[THE END]

---
Ken Laskey
MITRE Corporation, M/S H305     phone:  703-983-7934
7515 Colshire Drive                        fax:        703-983-1379
McLean VA 22102-7508




---
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]