OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

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

Subject: offline discussion of issues 317-333


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.


Begin forwarded message:

From: Ken Laskey <klaskey@mitre.org>
Date: September 27, 2007 10:49:31 PM EDT
To: Danny Thornton <danny_thornton2@yahoo.com>
Subject: Re: some responses to your issues

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



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"

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

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

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

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

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

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

Issue 326: agree.  The note was meant more for
immediate reviewers  
and to see if some point like this needed to be

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


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

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


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