10/3/07 SOA RA Minutes

[Don Flinn <flinn@alum.mit.edu>]

Correction, additions or deletions cheerfully accepted. Will then put in 
KAVI.

10/3/07 SOA RA Minutes

Attendees Frank McCabe, Ken Laskey, Danny Thornton, Jeff Estefan, Rex 
Brooks, Don Flinn

There was a discussion of Ken’s issues that he sent to the WS-Policy TC.

Issues 317, 318 and 319 were discussed.

The 9/28/07 9:59am e-mail between Ken and Danny, re: the issues that 
Danny submitted, was used as a basis for discussion.

Issue 317 – An annotation is additional comments about the subject that 
is being described, e.g. annotation from a third party which certifies 
authoritatively to whom for what use. Discussion:

Annotations are a catch all for descriptions that don’t fit into any of 
the other blocks. Frank has a worry – how does the user distinguish 
which is an annotation. Structure of a description can be used to model 
certain uses that we know we need. There are other things that are 
needed, which is where annotations are used. Annotations are our escape 
hatch. Rex agrees.

Resolution: Accept the change of "Associated Documentation" to 
"Annotations".

Issue 318

Sub-bullet 1 - Agreed to suggestion to get rid of the attribute and 
method rectangles in diagram
13. Ken to do.

Sub-bullet 2 - Use of arrows for directed association in figure 13; 
After some discussion the
consensus was not to use the arrows,

Sub-bullet 3 - Agreed to remove composition (solid diamonds) from the 
diagram.

Sub-bullet 5 - Is a duplicate of issue 317.

Issue 319

Sub-bullet 6 - Ken - Need to define ownership some place in the spec.
Frank – Should be in the resource model. A simple definition: right to 
control some resource
right to transfer that right. Resolution – Resource ownership and 
Subject history will be taken
into account in the Resource Model.

Sub-bullet 7 – Ken to shorten the performance section for the 
description model. The removed
portions should be moved to the management section.

Sub-bullet 8 – Move dependencies to top level within the service 
description.
For a service to function, the section declares the items that are 
needed. A service description should point out those items that are 
important. Not everything that is covered in the spec need to be put 
into the service description, e.g. technical assumptions may or may not 
be important in a particular instance. Ken to reword.

Sub-bullet 9 - Choreography & Orchestration to be added to diagram 13.

Don

-- 
Don Flinn
President
Mansurus LLC
e-mail: flinn@alum.mit.edu
Tel: 781-856-7230
http://mansurus.com