Re: [ws-caf] [Bug 131] New: semantics of mustPropagate need to be defined

["Mark Little" <mark.little@arjuna.com>]

BTW, I'm on vacation today so will try and transcribe this discussion
(probably via links to the mail archive) into the bugzilla entry next week.

Mark.

----
Mark Little,
Chief Architect, Transactions,
Arjuna Technologies Ltd.

----- Original Message ----- 
From: "Mark Little" <mark.little@arjuna.com>
To: "Green, Alastair J." <Alastair.Green@choreology.com>;
<ws-caf@lists.oasis-open.org>
Sent: Friday, June 04, 2004 12:00 PM
Subject: Re: [ws-caf] [Bug 131] New: semantics of mustPropagate need to be
defined


> I'm not convinced the criticism applies to OTS for the same reason (though
> it does apply) because of the specific circumstances in which it arose in
> that spec: to retain distribution transparency because certain
> implementations and readings of that spec. and others within the OMG
enabled
> transaction contexts to propagate automatically "through"
non-transactional
> objects in a purely local environment because the thread-to-transaction
> association couldn't be changed within a single address space. If I
remember
> correctly, in terms of the OTS we were caught between a requirement for
> distribution transparency and POA/PI not being finalised. The end result
was
> definitely less than ideal.
>
> That said, I tend to agree with you that at the level of basic context
> mustPropagate doesn't make sense. If there is a need for it in a
referencing
> specification, then you'd hope that that specification would understand
the
> semantics and provide it itself on that basis.
>
> Mark.
>
> ----
> Mark Little,
> Chief Architect, Transactions,
> Arjuna Technologies Ltd.
>
>
> ----- Original Message ----- 
> From: "Green, Alastair J." <Alastair.Green@choreology.com>
> To: <ws-caf@lists.oasis-open.org>
> Sent: Friday, June 04, 2004 10:31 AM
> Subject: RE: [ws-caf] [Bug 131] New: semantics of mustPropagate need to be
> defined
>
>
> > I now have three items on my personal WS-Context value proposition list
> > (by way of answering another of Peter's issues)
> >
> > 1. base class for attributes like mustPropagate
> > 2. a general, interoperable factory interface for creation of contexts
> >
> > and
> >
> > 3. (possibly) WSDLized REST (by-ref, requiring access control to be
> > useful, in my opinion).
> >
> > With respect to this specific issue 131, which relates to value item 1.,
> > I am not convinced of the need for mustPropagate. (This criticism
> > applies to e.g. OASIS BTP and CORBA OTS as well).
> >
> > If I send a context to a service, then it is not generally possible for
> > me to know whether it has propagated that context, or whether it has
> > not, by examination of its reply or the result of any further
> > interaction. In other words, external observation cannot detect whether
> > the "instruction" was followed, or violated.
> >
> > By additional specification, mandating some kind of context reply and
> > mandating that it contain the "route-map" of must-do propagations, we
> > could create a meaning for mustPropagate. But I think that we would all
> > agree that such an apparatus is hardly basic.
> >
> > It is not my business, as a service consumer, to know how far the
> > service provider delegates or lays off the work of an operation
> > invocation. And indeed, its actions in support of an operation might
> > vary from service instance to instance (new versions etc).
> >
> > Is "mustPropagate" relevant to conversational protocols (the "response"
> > must hold the same context as the "request")? This a reasonable, common
> > protocol (message correlation: Jim's case). You cannot state this need
> > using the blunt instrument of "mustPropagate". The words "must
> > propagate" imply that the recipient must forward the context to anyone
> > who is participating in the same activity (instance of use of a
> > referencing protocol). But the very notion of an activity is *defined*
> > by the domain of propagation of the context. The statement mustPropagate
> > is tantamount to: communicate the context to all those whom you believe
> > to be interested in or involved in this activity. To add mustPropagate
> > to a context adds nothing to the knowledge of the recipient as to its
> > "activity participants". It is an overstatement of the notion of
> > activity.
> >
> > The important specification is not the "must propagate" protocol (too
> > general to be useful). It is the usage (referencing, consuming) spec: in
> > this case correlation. It identifies the parties to the activity (the
> > interlocutors in the conversation).
> >
> > My proposed solution would be: drop mustPropagate.
> >
> > Alastair
> >
> > -----Original Message-----
> > From: bugzilla-daemon@arjuna.com [mailto:bugzilla-daemon@arjuna.com]
> > Sent: 30 May 2004 17:25
> > To: ws-caf@lists.oasis-open.org
> > Subject: [ws-caf] [Bug 131] New: semantics of mustPropagate need to be
> > defined
> >
> > http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=131
> >
> >            Summary: semantics of mustPropagate need to be defined
> >            Product: WS-Context
> >            Version: 1.0
> >           Platform: PC
> >         OS/Version: Windows 2000
> >             Status: NEW
> >           Severity: normal
> >           Priority: P2
> >          Component: Text and diagrams
> >         AssignedTo: ws-caf@lists.oasis-open.org
> >         ReportedBy: peter.furniss@choreology.com
> >          QAContact: mark.little@arjuna.com
> >
> >
> > The behaviour required by the "mustPropagate" attribute needs to
> > defined. (it
> > is assumed the attribute will be moved to context itself.
> >
> > The semantics need to define which outbound messages the propagation
> > applies
> > to - in particular, which of:
> >
> > - the response if a soap message is received over request/response;
> > - an out message of an operation defined as in/out in wsdl
> > - other messages sent to the original sender (which will require some
> > definition of that)
> > - other messages sent to any party (which may require some limitations
> > to allow
> > the receiving system to invoke other services "privately" - not to be
> > visible
> > to the originator)
> >
> > It will make no sense to leave this definition to a referencing
> > specification,
> > since the propagating system does not know of the referencing
> > specification -
> > if it did, it could sort out for itself what needed to be propagated
> > (possibly
> > after modification of the context)
> >
> > It may be that examination of the issue shows that it cannot be properly
> >
> > defined in the ws-context, in which case it should be removed.
> > Alternatively,
> > it may require some sub-parameterisation to give flexibility among the
> > choices
> > above, in which case this should be included.
> >
> >
> >
> > ------- You are receiving this mail because: -------
> > You are the assignee for the bug, or are watching the assignee.
> >
>
>