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:]
Sent: Wed 12/7/2005 10:20 PM
To:
Chiusano Joseph
Cc:
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
