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: Comments on Editor Notes In Section 4.1 Service Description Model



I like the clarification between service description and service
contract in the introduction of the Service Description Model.  

Section 4.1.1.1 
Editor Note - Augmented Resource Model
Comment: This looks like a Frank Action to incorporate the resource
model modifications into section 3 and characterized versioning as we
described a few meetings back.

Section 4.1.1.2.4 
Editor Note - Figure 22, Policy, Contract, Technical Assumptions,
Semantics Model
Comment: The elements of the model and their relationship are specific
to service description (relationship of policies and contracts to
technical assumptions for example) so this seems to be an appropriate
place for the model and the text.

Second Editor Note - Move figure 23 and some text to Section 4.4
Policies and Contracts
Comment: Same comment as above, the discussion of performance metrics
and SLAs is specific to Service Description.  The reason it would not go
into Policies and Contracts is because metrics are described in terms of
measurable assertions and SLAs are a specialized form of contract.  The
Policies and Contract section is more generalized than what is being
discussed in the Service Descriptoin section.
This section also states that Metrics will be described in Section 4.4
Policies and Contracts.  Section 4.4 describes metrics more generally as
the measurability of Assertions and Commitments and their relatonships
to the IT Mechanisms of Enforcement Point and Decision Point.

Section 4.1.2.2
Editor Note - Figure 25 - The relationship between Message, Protocols,
Action, and Endpoint
Comment: A message can be an xml document with no associated protocols
for delivery.  The endpoint defines the protocol, for example soap or
sockets or whatever you like. One way to characterize this would be to
make the relationship between Message and Action dependent on Endpoint
and then associate protocols with the Endpoint. 

Danny



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