RE: The SOAP and other bindings

[Alex Ceponkus <aceponkus@bowstreet.com>]

> 1) Header attributes: actor and mustUnderstand 
> Do we wish to define an actor for BTP headers, so that we can 
> indicate that a BTP communicator is the intended recipient/processor? 
> eg. 
> SOAP-ENV:actor="http//www.oasis-open.org/BTP/2001/1.0/communicator" 
> Do we wish to set mustUnderstand to "1"? As I read the SOAP 
> spec, either the header entry gets stripped out by the actor, 
> or the actor is not present, in which case the header entry 
> hits the ultimate recipient, who presumably knows he is 
> ultimate and therefore can decide that the actor doesn't 
> exist. At which point, it does what? There is no defined 
> fault for this eventuality that I can detect. 
> What does mustUnderstand add to the picture? Doesn't the 
> presence of an actor attribute essentially allow the same 
> "catch" to be made? 
> It seems to me that we should make the attributes be present 
> in any SOAP Header entry that we use for a BTP message, 
> irrespective of whether we expect the message to be handled 
> by a SOAP server per se. 
> If that is unacceptable (presence of attributes which 
> instruct a SOAP server is deemed to be a strong indication 
> that they must be processed and understood by a 
> SOAP-compliant server) then I believe we should revisit the 
> decision to use a SOAP-ENV: Envelope rather than a BTP 
> relationship mechanism of some kind. 

IMHO, SOAP actors cause quite a bit of confusion and appear to still be in a
"gathering implementation experience" stage.  

Let's say we were to introduce an actor URI as shown above
("http//www.oasis-open.org/BTP/2001/1.0/communicator"), then at first
glance, it appears we are duplicating information that is already contained
in the soap header...

<SOAP:Header>
	<btp:messages xmlns:btp="http://www.oasis-open.org/2001/BTP"
actor="http//www.oasis-open.org/BTP/2001/1.0/communicator">
		...
	</btp:messages>
</SOAP:Header>

What information does the actor URI provide that the namespace URI didn't
already give us?

Here's a note from Henrik from a thread
(http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0128.html) on the
XMLP WG mailing list...
<snip>
When we look at the XML NS URIs and the actor URIs we in fact have two
names in a SOAP message:

  * The actor URI identifies the "name" of the receiving SOAP processor
  * The XML NS URI identifies the "type" of the block.
</snip>

My interpretation: once we have specified the btp URI (the type), the it is
up the BTP processor developer to decide what will process a BTP message
with the btp URI "type."  The pre-defined actor doesn't provide any useful
information in this case (a developer needs to check if two URIs are valid
instead of one.)  If we were to compare to a programming interface .. the
soap endpoint is your API and it takes a BTP message in the header.  Now
it's up to the provider of the API to use whatever facilities are necessary
to process that message.  By specifying an actor, I read that as telling the
service provider to use a particular node to process the request.

This might become necessary if we were to have two BTP processors that both
process btp:messages.  Do we see that happening?


Now onto mustUnderstand...

From an offline conversation, Peter made a good point (well, my
interpretation of what was said): if mustUnderstand is set to 1, then the
BTP processor is being told by the client that it must process this request
in a transactional manner.  If mustUnderstand is set to 0, then the BTP
processor is being told the flip side, you don't need to process this
request transactionally.  Is that decision not up to the service provider?



> 2) mandatory fault messages when using request/response 
> protocols beneath 
> If I'm not mistaken the SOAP spec is vague on the 
> responsibility of a server to return a faultcode message. The 
> statement in "4.1.2 Envelope Versioning Model": 
> ' If the message is received through a request/response 
> protocol such as HTTP, the application MUST respond with a 
> SOAP VersionMismatch faultcode message (see section 4.4) 
> using the SOAP "http://schemas.xmlsoap.org/soap/envelope/" 
> namespace.' 
> could be taken to imply that other defined faultcode classes 
> (Client, Server, MustUnderstand) also MUST be returned when 
> using a "request/response protocol". 
> If this is is the standard interpretation of the 
> responsibility of a SOAP server then BTP-over-SOAP-over-HTTP 
> is different from BTP-over-HTTP. 

The SOAP and BTP processors will return errors independently of each other
.. if a parsing error occurs or if the SOAP namespace is incorrect, then the
SOAP processor will return a SOAP Fault.  However, if an invalid ID is
passed to a Coordinator, then a BTP fault is wrapped inside a SOAP response
(without a soap fault.)

To address Alastair's concern about tying BTP directly to SOAP, we can
overcome this problem by using "bindings" in the messaging spec.  This
technique is commonly used in other specs to keep these two layers decoupled
from each other.  For version 1.0, we provide a BTP binding to SOAP, but
don't preclude the creation of other bindings.  The spec can also include a
list of responsibilities that a binding needs to carry out to assist authors
of additional bindings.  Perhaps future work of this committee will be to
produce new bindings, but the community can also produce bindings
independently of this committee (as has been done with SOAP and WSDL.)


> [Parenthetic dumb XML questions: the encoding as <binding> 
> versus <btp:binding> is a choice open to the instance 
> generator, I assume. In other words, the schema defines 
> elements within the namespace represented here by the prefix 
> btp. The presence or absence of that prefix in element 
> names--what significance does this have? Is the context 
> inherited from the immediate parent element, such that 
> <btp:foo><bar></bar></btp:foo> is equivalent to 
> <btp:foo><btp:bar></btp:bar></btp:foo>? 

No, the two aren't equivalent.  Each XML element must explicitly provide a
prefix.  If a prefix is omitted, then the XML element belongs to the
"default namespace."