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] SOA-Pro & Core Concepts


I have a problem with this, Danny.

OMG Pro choreography definition could describe your choreography but not in the Service Contract. If service does not provide appropriate messages for external choreography, Contract cannot change it. Plus, service should not know if it is used in a choreography of anywhere else. 

If a choreography, assumed by a service consumer, applies special policies on the service interaction, then YES, these policies have to be included into the Service Contract (I talked about this a few months ago) but OMG lists choreography and policies separately. This close to violation SO principle.

- Michael



==============================================
Subject: RE: [soa-rm-ra] SOA-Pro & Core Concepts

    * From: "Danny Thornton" <danny.thornton@scalablearchitectures.com>
    * To: "Ken Laskey" <klaskey@mitre.org>
    * Date: Fri, 25 Jul 2008 17:28:27 -0700

One of the biggest differences I saw between the SOA RA and the OMG Pro was the use of Service Contract vs Service Description.  Ken eloquently captured the difference in his notes. 
 
The Choreography definition does not cause me problems.  If I have a choreography that describes the temporal relationship and types of exchanges of messages between two to many services where the service providers are to be filled in by an orchestration, then the OMG Pro choreography definition could describe my choreography.  Can someone provide a counter argument for a (choreography to orchestration) as being similar to (xml schema to a xml message) or more basically a (data type to a data element)? 
 
Danny Thornton


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