offline discussion of issues 317-333

All,

Danny and I have had some offline dialog on a number of his issues.  I noticed I needed to come up to speed again on what I meant or why I wrote something in a certain way, so if I began the discussion with the issue writer, then others could join in when we both were fresh for the discussion.

Danny and I reached that refresh point and now it's time to pass on to everyone else.

Ken

Begin forwarded message:

From: Ken Laskey <>

Date: September 27, 2007 10:49:31 PM EDT

To: Danny Thornton <>

Subject: Re: some responses to your issues

 see inline.  We are probably close to bundling this for the whole mailing list.

Thanks,

Ken

On Sep 27, 2007, at 2:02 AM, Danny Thornton wrote:

I have embeded my responses below.  

 
issue 317: willing to replace 

"Associated Documentations" with "Annotations"
 
ok

 
Issue 318:

1) agree
 

Before somebody told me about it, I did not know you

could left click the upper left corner of the

attribute rectangle or method rectangle to get rid of

the rectangles in the class so I'll pass this on

incase it is helpful. 

 
2) not sure where to add arrows unless I replace

aggregations -- is  

this what you propose?
 

You can right click on the end of aggregegated

association and then choose "Show Navigability" from

the popup menu.

 
3) I used composition (solid diamond) in places

where I thought the  

group MUST have the component and wouldn't really

exist if the  

component wasn't present.  This may be overloading

what UML intends.   

I could agree to replacing all compositions with

aggregations.
 

Composition in UML means that the composed object's

life span (instance creation and deletion) will be

controlled by the object it is composed from and that

the composed object will not be associated with

another object during the composed object's life span.

  This really starts to speak about the run-time

aspects of a system.  In the service description

model, we do not describe instance creation in the

run-time sense so I would avoid composition.  As far

as using composition/aggregation for a must have or

could have, we would probably get flogged by many

software architects for using it that way.

I knew I was being neither accurate or consistent in my use of composition and was going to clean that up when we settled other questions I had.  However, that may not spare me the flogging.

 
Issue 319:

6) First, if kept I'd replace "Subject History: with

"Resource  

History".  
 
ok

 
Second, responsibility may be delegated

by the owner.  In  

that case the owner is one of the responsible

parties (for certain  

things) and the delegate is responsible for the

delegated scope.   

Some of this may also be handled when I connect with

the resource model.
 
If the suggestion is to add owner and delegate as a

subclass of Responsible Parties, my feeling is that

this will be going down a path that many people would

feel is not necessary, particularly architects. 

Resource Ownership and Resource History is concise

enough so that people can understand the purpose of

Provenance.  I fear more than that will lead to

explanation and debates.  I am not clear how delegated

scope fits into Provenance the way scope was discussed

in the meeting.  We could leave this one for TC

discussion.

I think the answer may be to construct the Responsible Party in such a way that it could be the Owner or a Delegate and it may not be necessary to be any more specific.  I think I may have put in an issue that says we need to define the term Owner, and that might help.

 
7) If I have Performance Metrics then I need

something for other  

conditions that can be required when generating

policies; hence,  

Nonperformance Metrics, but I'm open to a different

term.  
 
Providing a concrete example of Nonperformance Metrics

would help in understanding how Nonperformance Metrics

could be used in a concrete Service Description. I am

looking at the Service Description in terms of how I

would implement it and I am having some difficulties

coming up with a plausible concrete scenario for

Nonperformance Metrics.

A nonperformance metric could be whether the service was stress tested with a prescribed number of real or simulated users.

 
For  Metrics Access, I was 

thinking that the description MAY have  

information on how to access an identified metric

(see lines 909-911).
 
This could be Applicable Metrics as described in lines

909-911.  However, I think this is an implementation

detail that does not explicitly need a class in the

Service Description UML model.

Agreed.  As you suggest, the accompanying text could simply say the description MAY have access info.

 
8) Yes to spelling out RWE.  I like the other detail

in the visual  

but would be satisfied just covering this in text

(see issue 324).   

I'd want to get opinion of others re the diagram but

not necessarily  

a long discussion.
 
ok

 
9) OK by me but then need to check consistency with

Interactions  

section.
 
ok

 

Issue 320: agree  -- was left in because the

assertions that follow  

are not generally agreed wisdom and I wanted to

check for heartburn  

before the concrete hardened.
 

 

Issue 321: there are some assertions and conclusions

in this section  

that should be included somewhere and I would be

happy to reduce this  

section to just say it gives description link to the

stuff in the  

somewhere, but I wouldn't delete until the somewhere

exists.
 
This issue is specific to lines 874 and 875.  The

question posed in response to the sentence is - what

is local in a distributed system?

If a service is an aggregate of several other services, the availability of the aggregate service is some way derived from the availability of the parts.  It was the parts I was referring to as "local", but I agree that could be confusing.

 

Issue 322: agree
 

 

Issue 323: agree -- this note captures topic for

possible discussion  

when we consider this section
 

 

Issue 324: disagree -- while might remove from

diagram (issue 319,  

8) ) I believe an expansion of what goes into a

description of  

Functionality is important.  In particular, SOA will

be used for  

technical aspects of the business, and technical

assumptions cannot  

be ignored (as they often are).  [What comes to mind

is an episode  

where the contract requirements violated the laws of

physics.]
 
I agree with keeping Service Functionality, Functions,

and Real World Effect.  I see machine processable

dependencies being described in orchestration,

choreography, protocols ... other elements of the

service description.  If it is not a machine

processable dependency then it could be included as

part of the function description but I do not think it

explicitly needs a class in the Service Description

UML model.  I would make a similar argument about

Technical Assumptions.

Too tired to get together a coherent position.  I'll need to see what adding orchestration and choreography to the the process model will capture.  We'll keep this one open for now.

 

Issue 325: I think there was a reenforcement of a

point and an  

extension being made here.  I would see other

wording/content changes  

are needed and then revise to eliminate redundancy.
 
ok

 

Issue 326: agree.  The note was meant more for

immediate reviewers  

and to see if some point like this needed to be

made.

Issue 327: agree

Issue 328: agree
 

 

Issues 329, 330: There was an email thread on this

at one point and  

this tries to capture the consensus, although the

wording could be  

tighter.   In summary, if the SLA are all conditions

and results  

around a behavior, then each SLA recreates large

portions of  

description.  I think this view of SLA comes from

there being more  

ink used on hypothesizing about SLAs than actual

generation and  

use.   What this section advocates is a minimum

scope for what SLA  

provides and where it fits with other, reusable

parts of  

description.  This is likely something we have to go

over carefully.
 
Ok with rewording or a concrete example that

demonstrates the intent of 930-935.

 

Issue 331: agree once we're sure we did it.

Issue 332:  agree

Issue 333: agree
 

Danny

____________________________________________________________________________________

Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.

http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow  
 

 
-----------------------------------------------------------------------------

Ken Laskey

MITRE Corporation, M/S H305      phone: 703-983-7934

7151 Colshire Drive                         fax:       703-983-1379

McLean VA 22102-7508

 

 
-----------------------------------------------------------------------------

Ken Laskey

MITRE Corporation, M/S H305      phone: 703-983-7934

7151 Colshire Drive                         fax:       703-983-1379

McLean VA 22102-7508

 

smime.p7s