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.