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

["Green, Alastair J." <Alastair.Green@choreology.com>]

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.