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


Help: OASIS Mailing Lists Help | MarkMail Help

soa-blueprints message

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

Subject: Re: [soa-blueprints] WS-TX

Sure, I'm in agreement with what Ken and Dan have said as well. 

On 11/21/05, Miko Matsumura <mmatsumura@infravio.com > wrote:
This is really important stuff, thanks for bringing it up. John, do you
want to take a crack at this? How to begin to deal with these issues?

-----Original Message-----
From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: Monday, November 21, 2005 11:51 AM
To: marchadr@wellsfargo.com; jharby@gmail.com;
Subject: RE: [soa-blueprints] WS-TX

Agree.  The descriptive metadata for all entities involved in SOA, e.g.
content as well as services, should adequately describe that entity so a
user (both providers and consumers) knows what the entity is, when it is
applicable, and how to apply it.  Context is obviously a big part
because the details of what is described may change with changing


At 02:19 PM 11/21/2005, marchadr@wellsfargo.com wrote:
>I would also add that there may be options to include some of the work
>done in the WS-CAF TC for context.
>It is not as rich as it should be but feedback to that group might be
>worthwhile anyway.
>My 2 cents.
>- Dan
>-----Original Message-----
>From: Ken Laskey [mailto:klaskey@mitre.org]
>Sent: Monday, November 21, 2005 10:24 AM
>To: John Harby; soa-blueprints@lists.oasis-open.org
>Subject: Re: [soa-blueprints] WS-TX
>I would expect the service metadata to include, or more likely
>prominently link to, representations of policies under which the
>service wishes to perform.  Per the SOA-RM, policies represent a "wish
>list" for the service, where some items may be negotiable and some not.

>Establishing the "execution context" is the mechanism by which provider

>and consumer policies are aligned and conflicts resolved;  it may be
>thought of as a negotiation of policies resulting in a contract between

>the parties.  A service invocation becomes possible and may occur
>within an established execution context.  The transaction semantics
>would not be changed, but some level of semantic mediation may be
>necessary in the process of creating the contract, including
>documenting what mediation has occurred.
>At 12:28 PM 11/21/2005, John Harby wrote:
> >I joined the WS-Transactions TC and attended their F2F last week.
> >Although I don't think we have the sort of liason requirements that
> >we may have in other SOA related TCs, the notion of SOAs and services

> >did come up in the discussion. One particular example was
> >compensation (e.g. in a rollback scenario), certain services may be
> >compensatable and others may not. It wasn't too certain whether this
> >property should be expressed in the service metadata or some
> >policies. It was extremely undesirable to that group for the
> >transaction semantics or protocol to be modified though.
>    /   Ken
>Laskey                                                                \
>   |    MITRE Corporation, M/S H305    phone:  703-983-7934   |
>   |    7515 Colshire Drive                    fax:      703-983-1379
>    \   McLean VA 22102-7508


   /   Ken
Laskey                                                                \
  |    MITRE Corporation, M/S H305    phone:  703-983-7934   |
  |    7515 Colshire Drive                    fax:      703-983-1379   |
   \   McLean VA 22102-7508


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