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: RE: [soa-rm-ra] Comments on Editor Notes In Section 4.1 Service Description Model


Please, find my comments in the text
Kind regards,

Michael Poulin


Senior Solution Architect, EMF Solution Management

Fidelity Investments International

' +44-173-783-6038
* michael.poulin@uk.fid-intl.com 
@    http://www.fidelity.co.uk/

Important: Fidelity Investments International (Reg. No.1448245),
Fidelity Investment Services Limited (Reg. No. 2016555), Fidelity
Pensions Management (Reg. No. 2015142) and Financial Administration
Services Limited (Reg. No. 1629709, a Fidelity Group company) are all
registered in England and Wales, are authorised and regulated in the UK
by the Financial Services Authority and have their registered offices at
Oakhill House, 130 Tonbridge Road, Hildenborough, Tonbridge, Kent TN11
9DZ. Tel 01732 361144. Fidelity only gives information on products and
does not give investment advice to private clients based on individual
circumstances. Any comments or statements made are not necessarily those
of Fidelity. The information transmitted is intended only for the person
or entity to which it is addressed and may contain confidential and/or
privileged material. If you received this in error, please contact the
sender and delete the material from any computer. All e-mails sent from
or to Fidelity may be subject to our monitoring procedures. Direct link
to Fidelity's website -
http://www.fidelity-international.com/world/index.html 




-----Original Message-----
From: Danny Thornton [mailto:danny.thornton@scalablearchitectures.com] 
Sent: 12 March 2008 04:58
To: soa-rm-ra@lists.oasis-open.org
Cc: klaskey@mitre.org
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


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 


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