RE: ISSUE 3564: Optional Assertions may not be usable in all circumstances

> In this case, a client sending a message 
> can not ensure that the outbound message will 
> be sent using MTOM optimization, by engaging the 
> capability as there are two alternatives.

Providers and requestors rely on wire messages that conform to prescribed data formats and protocols for interoperability. If a requestor wants to signal to a provider that the requestor stack chose to engage MTOM code the requestor may indicate this by sending an MTOM encoded message. Another possibility is to send an HTTP Accept Header [1][2][3]. That is,

Accept: application/soap+xml, Multipart/Related

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1 
[2] http://www.w3.org/TR/soap12-part2/#httpmediatype
[3] http://www.w3.org/TR/soap12-mtom/#xop-serialization

This is protocol negotiation. This is not metadata.

> MTOM and Reliability are good examples that 
> will be hindered if optionality is provided

The above description covers the MTOM case. The behavior indicated by the Reliability assertion manifests on the wire as a Create Sequence message.

> When a capability is only possible on message 
> level subjects and expressed to apply to 
> outbound messages only as optional assertions.

If there are policies associated with a message policy subject for an outbound message, a provider is informing potential requestors that they must be open to engaging any of the policy alternatives in the effective policy of the message policy subject for an outbound message. It is up to the provider to make the choice on the outbound message. A provider may choose an alternative based on an inbound message (as defined by protocol bits - as illustrated above). The choice is still at the provider's discretion. Providers should consider this when expressing multiple alternatives on outbound messages. BTW, this is a good point to highlight in the Primer.

Regards,
 
Asir S Vedamuthu
Microsoft Corporation


________________________________________
From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Yalcinalp, Umit
Sent: Wednesday, August 02, 2006 3:32 PM
To: public-ws-policy@w3.org
Subject: ISSUE 3564: Optional Assertions may not be usable in all circumstances 

Title: Optional Assertions may not be usable in all circumstances 
Description: Typically providers express capabilities by attaching assertions 
that are declared as "optional' on web service artifacts. Marking assertions 
optional allow representation of capabilities which may or may not be engaged 
although the capability is provided on the provider side. This is due to the 
fact that the presence of an optional assertion leads into two separate 
alternatives, one containing the assertion and one that does not. 
There are certain cases where the client of a web service can not ensure the 
engagement of an optional capability since the mechanism of choosing among the 
alternatives can not be ensured as there is no explicit mechanism to enable 
this. The following situations are detailed examples for this case: 
(a) When a capability may be assigned to an endpoint thus governing both 
inbound and outbound, but the incoming message can not be self describing to 
ensure the engagement of the capability. 
A typical example is to provide MTOM capability on an endpoint. Although the 
presence of an optional MTOM assertion indicates that MTOM optimization is 
possible, a client may not be able to engage MTOM. This situation will occur 
when the inbound message does not require optimization (i.e. may be a normal 
payload) and the outbound message may include an attachment and may provide 
MTOM optimization per WSDL definition. In this case, a client sending a message 
can not ensure that the outbound message will be sent using MTOM optimization, 
by engaging the capability as there are two alternatives. 
(b) When a capability is only possible on message level subjects and expressed 
to apply to outbound messages only as optional assertions. Again, the client 
can not engage the capability expressed by optional assertions, as the inbound 
messages will not include additional information to engage the capability 
expressed by the optional assertion that apply to outbound messages only. 
Note that case (a) the scoping may be apply to the endpoint, but the definition 
of messages may not allow the determination to be made based on the input 
message. In case (b), the granularity of attachment directly may prevent the 
determination. Therefore, there are two distinct cases. 
Without the presence of additional metadata exchange between the client and the 
provider, the engagement of optional assertions (more precisely the selection 
of one of the alternatives), engagement of a capability is only possible when 
the capability pertains to the input message and can be inferred. However, this 
is also a limited view, because on message level policy subjects, it is also 
not possible to disengage a capability on an outbound message. 
Justification: 
Non-uniform treatment of optional assertions leads to interoperability problems 
as proven by the interop event [InteropPresentation]. It will lead providers to 
(1) assume either a particular treatment of optional assertions (always enforce 
or never use). Vendors may enforce an capability although an assertion is 
expressed to be optional. For example, if a client who is not capable of using 
MTOM were to use an endpoint with the capability and would always get MTOM 
optimized messages back from a service, the client can not use the service 
although the service "advertises" that MTOM is optional. 
(2) never use optional assertions. This is a limiting factor for being able to 
express capabilities that may be engaged but not required. MTOM and Reliability 
are good examples that will be hindered if optionality is provided. 
Proposal: 
There are several ways to solve this problem. Below here are three sketches. 
Complete proposals will need to be developed. 
(A) Provide additional binding specific mechanisms (such as specific SOAP 
headers) that allow clients to engage capabilities that may optionally apply to 
a message exchange. 
(B) b1. Disallow alternatives to exist for each subject after normalization as 
a design time constraint. Hence, disallow optionality at the endpoint level. 
    b2. Disallow optionality completely. (Very much against this option) 
For b1, suggest in primer if a capability is to be expressed, always require 
the provider two separate endpoints, one that requires and one that does not in 
a WSDL. This is a design consideration that would need to be captured by 
primer, etc. but goes against the current design of the framework. I believe 
this is a very short term option and does not really yield to the usage of the 
framework to its fullest. 
C. Develop guidelines in primer about the utility of optionality and illustrate 
when optional assertions may require additional support from the environment 
(as in A) 
My preference: 
A, worst case C. 
Option B. has two major drawbacks and is only a short term solution until a 
full solution that addresses the framework intent is developed as mentioned in 
(A). Some of the techniques may go into the primer but optionality should not 
be disallowed. Further, this approach does not solve fine granular engagements 
of capabilities on a message level (see b)in the description). It separates the 
conceptional aspect (capability vs. constraint) from the framework and reduces 
WS-Policy to express only constraints. 
We should not hinder the framework at this stage and discourage optionality. 
[InteropPresentation] 
http://lists.w3.org/Archives/Public/public-ws-policy/2006Jul/0039.html 

---------------------- 
Dr. Umit Yalcinalp 
Architect 
NetWeaver Industry Standards 
SAP Labs, LLC 
Email: umit.yalcinalp@sap.com Tel: (650) 320-3095 
SDN: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238

Received on Friday, 11 August 2006 23:56:22 UTC