RE: [soa-rm-ra] Comments on Editor Notes In Section 4.1 Service Description Model

[Danny Thornton <danny.thornton@scalablearchitectures.com>]

In reply to the comments, the mechanisms to enforce policies and contracts are likely to be identical at the IT level.  This is a core principle of the Policies and Contract section.  In the interest of parsimony, derivations into the many types of policies and contracts are not discussed in the policies and contract section.  Those derivations could be discussed in other sections where appropriate, in the Service Description section for example.

Danny 
> -------- Original Message --------
> Subject: RE: [soa-rm-ra] Comments on Editor Notes In Section 4.1
> Service Description Model
> From: "Poulin, Michael" <Michael.Poulin@uk.fid-intl.com>
>
> Please, find my comments in the text
> Kind regards,
>
> Michael Poulin
>
>
> -----Original Message-----
> From: Danny Thornton [mailto:danny.thornton@scalablearchitectures.com] 
> Subject: [soa-rm-ra] 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. 
>
> M.P. Based on my company experience, Service Contract is agreed
> composition of subsets of policies derived from the Service Description
> and policies provided/required/applied by the service consumer.
> Example: a service consumer wants to use existing SOA service for
> sensitive data. Service functionality meets consumer's needs very well
> but Service Description does not mention any security communication
> protocol. Consumer agrees with Provider that the latter would issue a
> version of the service capable communicate via, e.g., HTTPS based on the
> Security Policy represented by the service consumer. Thus, the Service
> Contract includes Policies from both participating parties.
>
> 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.
>
> M.P. I disagree with "performance metrics and SLAs is specific to
> Service Description". It is specific to the Service Contract only. A
> service provider may have a generic SLA but it can/should be
> 'overridden' by the Contract's SLA - it is specific for each individual
> service consumer execution context (business and technical)
>
> M.P. Sentence "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" says that specialized form of
> contract (SLA) is not a Contract. Oups! If the sentence would say "...it
> would go into ...", I were with it.
>
> M.P. I agree, Section 4.4 does not clearly define relationship between
> Description and Contract. The "measurability of Assertions and
> Commitments and their relationships" is important in this section but
> only after Description-Contract relations are clarified. In my first
> comment to this message, I tried to define these relations. 
>
>
> 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. 
>
> M.P. This note is very much Web Services centric. We, probably, have to
> stay away from promoting particular technology.
>
>
> Danny