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