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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-tx message

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


Subject: Re: Fw: [ws-tx] Issue 030 - consolidated refinement of Proposal 2


Ian,

I agree that we need to put this to bed. The various points are being 
addressed in your solution based on Proposal 2, and altho' I think it 
isn't quite as simple and consistent as it might have been had we been 
starting from a clean slate, we obviously need to move on. It's 
definitely workable.

In addition, it looks like I will not be able to attend the meeting this 
Thursday because of domestic commitments, and I don't want to launch an 
alternative proposal which I won't be able to motivate -- that would 
just make it harder to get a final consensus.

Can I therefore just raise three points that I think the TC might want 
to consider in wrapping this up?

The point about recasting "physical address" as "non-anon, non-none" 
which you have also incorporated in your refinement could usefully be 
added to the description of the three EPR elements 
/CoordinationContext/RegistrationService,  
/Register/ParticipantProtocolService and 
/RegisterResponse/CoordinatorProtocolService, in WS-Coordination.

Also, do you see an issue with inability to deliver Invalid Protocol and 
Invalid Parameters in response to the terminal notification messages? I 
think that in extremis these situations could arise with amnesia, so 
perhaps that needs to be taken into account?

In the interop documents, is it worth saying that failure to deliver 
WS-Addressing predefined faults is not a conformance failure? This is 
the only place where the "silence" decision might need to reflected aloud.

Yours,

Alastair



Ian Robinson wrote:
>
>
> There has been a lot of discussion and some good comments suggesting
> refinement of "Proposal 2" for issue 30. Specifically:
>    Alastair's point that the WS-C spec defines the Coodination faults as
>    "reply messages" but the WS-AT spec defines AT faults as "notification
>    messages". The refined proposal clarifies that the specific messages
>    exchange patterns apply to the protocol rather than to individual
>    messages and that protocol fault messages are constructed according to
>    the rules of the protocol in which they are used.
>    Bob's objection to the use of phrases like ' "one way" pattern as
>    defined in WS-Addressing '. The proposal replaces this with ' The
>    protocols defined in WS-AtomicTransaction use a "one way" message
>    exchange pattern consisting of a sequence of notification messages
>    between a Coordinator and a Participant. '
>    Joe's observation of the inconsistency in specificity between references
>    to WS-A from Coordination on the one hand and AT on the other. These are
>    now uniformly precise. Also the proposed text now refer to the abstract
>    message addressing properties rather than to soap header elements.
>
> Max and I have updated our proposal to address these concerns.
>
> (See attached file: Issue30_Proposal_2_WSBA.doc)(See attached file:
> Issue30_Proposal_2_WSAT_updated.doc)(See attached file:
> Issue30_Proposal_WSCOOR_updated.doc)
>
> In accrodance with the decision of the TC on the last telecon, the text
> remains silent on the handling of non-TX fault messages.
>
> We have been discussing this issue for a month now, and we have other work
> queued up. Could I suggest that any further refinements or
> counter-proposals be written in terms of concrete spec language that the TC
> would be able to vote upon on the next telecon.
>
>
> Regards,
> Ian


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