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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

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


Subject: Re: [ws-caf] [Bug 134] New: mustUnderstand needs moving and defining


Alastair,

My intuition would be to keep it out of the context, and at the meta level where it is now.
Besides, it is not entirely clear to me how an application can be ignorant of context but still be expected to look inside and see the "must be understood" part?

If there are other, future transports then those should also have similar mechanisms to SOAP headers (and, I guess, similar ways of specifying mustUnderstand).

Best,
Guy

On vrijdag, jun 4, 2004, at 14:46 Europe/Brussels, Green, Alastair J. wrote:

I have already advocated the dropping of mustPropagate.

If we can assume SOAP headers then mustUnderstand is a property of the
header.

The conclusion would then be: there is no role for WS-Context as a base
class reflecting these two relationship attributes.

* * *

However, to be stringent: can we assume SOAP headers? WSDL is our
starting point: presumably at some point (in a future fully-specified,
architecturally-articulate world) our WSDL message parts can map to
unknown encodings and unknown transfer protocols.

Therefore, if we are to state: "this context must be understood" then
there must be a way of doing that without relying on the SOAP header.
(As you may guess, I'd love to be argued out of that conclusion!)

This would indicate that WS-Context contexts, viewed as a base class,
contain a must understand element.

It would also indicate that there must be a "did not understand" fault,
defined by WS-Context.

What do other TC members think? I have had great trouble trying to find
a coherent general statement on how to create a WSDL binding that maps
to any arbitrary encoding and any underlying protocol. It seems that
there are strong practical, tools-based assumptions, which are not
properly codified.

Do we define Web Services as SOAP+WSDL, or just WSDL, in other words?

Alastair

-----Original Message-----
From: bugzilla-daemon@arjuna.com [mailto:bugzilla-daemon@arjuna.com]
Sent: 30 May 2004 17:45
To: ws-caf@lists.oasis-open.org
Subject: [ws-caf] [Bug 134] New: mustUnderstand needs moving and
defining

http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=134

Summary: mustUnderstand needs moving and defining
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 mustUnderstand and mustPropagate attributes should be moved to
context and
don't belong on the service list.

Since a context is (commonly) a soap header, the SOAP:mustUnderstand
attribute
is available, and mustUnderstand could be considered superfluous.

However, the SOAP:mustUnderstand attribute could be interpreted as
meaning the
ws-context-specified aspects must be understood, and the
wsctx:mustUnderstand
means the context type must be understood. Thus SOAP:mustUnderstand="1"
wsctx:mustUnderstand="0" wsctx:mustPropagate="1" would mean the receiver
was
guaranteed to propagate the context unchanged if it did not recognise
the
context type (or through a soap fault). (if it did recognise the context
type,
it could sort out the propagation for itself)

This latter approach seems to add necessary functionality to support the
two-
level function identification of ws-context (context namespace of whole
header;
context type as particular protocol). It may be better to rename
wsctx:mustUnderstand to avoid (human) confusion with the SOAP attribute.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



Dr. Guy Pardon ( guy@atomikos.com )
Atomikos: Your Partner for Reliable eBusiness Coordination
http://www.atomikos.com/

The information in this email is confidential and only meant for the addressee(s). The content of this email is informal and will not be legally binding for Atomikos.



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