RE: [soa-rm-ra] [SPAM] [soa-rm-ra] RE: updated service description

["Poulin, Michael" <Michael.Poulin@uk.fid-intl.com>]

Title: RE: [soa-rm-ra] [SPAM] [soa-rm-ra] RE: updated service description

Hi Danny,

When I said 'personalised' I meant to distinguish between impersonal service description and individual service contract. If the contract should be signed always, I would say No - we can represent a 'default contract', which would not require signing. Even more, if the description is simple, e.g. it represents only one service interface and only mandatory policies, the service description may be 'promoted' into the 'default contract'. What do you think?

Not every type of "a change in location/reachability of a service" should cause a change in the version. Your example with failover is exact the case. However, I anticipate that enterprise merges can cause complete different location/reachability for existing services w/o changing the service functionality. So, I have mentioned location/reachability under the version management.

- Michael

Fidelity Investments - Web Delivery
Phone: +44-173-783-6038
E-mail: michael.poulin@uk.fid-intl.com
Web: http://www.fidelity.co.uk/

Important: Fidelity Investments International, Fidelity Investment Services Limited, Fidelity Pensions Management and Financial Administration Services Limited (a Fidelity Group company) are all 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_thornton2@yahoo.com]
Sent: 25 February 2007 21:10
To: soa-rm-ra@lists.oasis-open.org
Subject: [soa-rm-ra] [SPAM] [soa-rm-ra] RE: updated service description

Hi Michael,

The Service Description contains a generalized
meta-model for those things that are publicly
discoverable about a service.  You bring up a good
point about personalized contracts.  This can be a
private affair between two or more parties and not a
public affair.  A question for the RA participants:
Should there always be a signed contract on record
between the agreeing parties? 

At the implementation level, one way to handle a
personalized contract is to store the personalized
contract in a private database.  This would put the
discussion of contracts in the interaction section as
Michael stated. Another way to handle a personalized
contract is to store it as part of a mediated public
registry/repository with access controls.  This puts
the personalized contract back in the Service
Description.

I agree about versioning being a part of identity.
However, I do not see a change in
location/reachability of a service requiring a new
version of the Service Description.  One model for
handling service failure can be to update the location
of the service in the registry so consumers can
transition to the new location of the service.  

Danny

--- michael.poulin@uk.fid-intl.com wrote:

> Hi Ken,
>  I have two notes to the update (actually, to the
> doc as it is with the update):
>
> 1)    There is an entity in the Service Description
> diagram named "Interaction Policies & Contracts". I
> think that Contract belongs to another area than
> service description because it is 'personalized'
> based on consumer/provider agreement. Yes,
> logically, a Contract is a special type of
> description but it would be more comprehensive if we
> put it into Interacting with Services Model
> section.
>
> 2)    You have mentioned <A discussion of how version
> designation/value should be impacted by change of
> version of any of its components (or any
> descriptions?) still needs to be discussed.> To me,
> a version of the service is one of very important
> characteristics of the service description (and,
> respectively, of the service contract). I would
> propose placing version as an entity in the Service
> Description diagram either under Identity or at the
> level of Service Description entity because version
> affects Service Reachability, Service Functionality,
> Interaction Policies, and Service Interface
> entities. I have published a few thoughts about SOA
> service versioning in SOA-WebServices Journal
> (http://java.sys-con.com/read/250503.htm ).
>
> - Michael
>

 
____________________________________________________________________________________
Yahoo! Music Unlimited
Access over 1 million songs.
http://music.yahoo.com/unlimited