Re: [soa-rm-ra] Version

[michael.poulin@uk.fid-intl.com]

I agree with Ken on both versions for the service and for the Service Description.

As of EC and Service Description, I suggest that the Service Description must describe/identify the EC it is offered for. This relates as to the technical EC as to the business EC. Change in EC may not lead to a change in the service BUT it compromises the  trust - in new EC service may behave differently. Thus, before using/reusing a service in the changed EC , the service must be re-tested.

Thus, I think, that EC has to be a parameter of the Service Description ( and Service Contract) exactly because it is the property of the service interaction.

- Michael 


===========================

Subject: Re: [soa-rm-ra] Version

    * From: Ken Laskey <klaskey@mitre.org>
    * To: michael.poulin@uk.fid-intl.com
    * Date: Fri, 27 Jun 2008 17:29:17 -0400

The EC is a property of the service interaction, not a particular service participating in the interaction.  Service policies and contracts are part of the EC if they are agreed upon by the Consumer, but it is possible a consumer policy may be used instead of a corresponding service policy if the provider and consumer so agree.

I'm not sure if I have previously spoken of the "parts" included in the service description as service properties but I do refer to properties in section 4.1.2.1 when I talk about assigning values to description.  So I don't think we have a disconnect there.

See my previous response to Duane about the service description supporting multiple versions for a single service, where here there would be a temporal chain for the service description versions, with one superseding its predecessor.

Ken