OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

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


Subject: Re: [soa-rm] Policies and Contracts - notes for currently posted document


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


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