Re: [soa-rm] Policies and Contracts - notes for currently posteddocument

[Duane Nickull <dnickull@adobe.com>]

Frank:

Can we put Michael on the agenda for another upcoming RA call?

Duane


On 2/19/07 1:47 PM, "michael.poulin@uk.fid-intl.com"
<michael.poulin@uk.fid-intl.com> wrote:

> Duane,
> 
> The reviewed document is from SOA-RA Wiki  from the ServiceView section. This
> certainly may not be a part of SOA-RM (in my response  message about David
> Linthicum, I mentioned one article I wrote in Sys-Con when considered SOA-RM
> for actual SOA development).
> 
> I think that Service Description is the thing which distinguish SOA Service
> from a Web Service and adds business meaning to the former. Since Service
> Contract is based on the Service Description, it becomes a concrete artifact
> in RA. What I try to achieve with this is to close the door (at least, shut it
> a little) to the populistic use of Web Services that expose non-service
> oriented IT artifacts into  SOA. That is, Web Services should not be equal to
> SOA because they do  not have business meaning, execution context, are not
> responsible for the business behavior of the service implementation and do not
> oblige service provider to agile with the business needs.
> Plus, Service Contract may be treated in similar way as Service Description
> (not a Policy) with regard to service discovery and invocation. Talking about
> SOA services that reflect business services, I would not invoke a service
> blindly, only because it is announced until I am sure it does not represent a
> risk to my business, i.e. I need a Service Contract in place.
> 
> As of Policies and Service Description/ Service Contract, I agree that
> Policies might not be the part of the Description/Contract text ( an
> preferably if they do not) but rather referenced in there. This does not
> preclude using them in WS-Policy and WS-PolicyAttachment. However,  WS != SOA
> Service, and SOA may treat as providers as consumers policies, I think.
> 
> Now, service versioning is not the same as execution context though it is used
> to reflect the specific of the context. That is, particular version of the
> service may be used in the context A. However, the same version may be used in
> the context B but not in the context C. This totally depends on the consumers
> needs. Here (http://java.sys-con.com/read/250503.htm ) I tried to describe the
> SOA service versioning.
> 
> I would be happy to present to discuss my notes in a telcon (I am in London,
> UK) but cannot do it on 28 Feb. (I will be on vacations).
> 
> Cheers,
> - Michael

-- 
**********************************************************
Sr. Technical Evangelist - Adobe Systems, Inc.           *
Chair - OASIS SOA Reference Model Technical Committee    *
Blog: http://technoracle.blogspot.com                    *
Music: http://www.mix2r.com/audio/by/artist/duane_nickull*
**********************************************************