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

So here is my text again.  [I know Seumas has some good thoughts on  
this that he'll add tomorrow around optional on outbound messages.]

Hi Umit et al,

I'd like to comment on Umit's earlier discussion on the usage on the
optional tag. From what I understand Umit is raising the issue around
what is the expected behavior when a client initiates a request to a
service that has some policy as optional. Specifically should the WG
specify the expected behavior in the Framework or Primer.  I think
Umit raises a good point. (If of course I understand the issue
correctly)

[If this is the wrong way to discuss this please let this novice know
the right way]

At the endpoint level:
The example that seems to be bantered about is regarding MTOM.
Suppose the MTOM is optional. The client knows MTOM and initiates a
request using MTOM. Surely it is a fair enough assumption that the
server would reply using MTOM. I would assume that on an optional
policy the initiator then decides the conversation. And so from then
on, in the conversation, all is MTOM. If the client decides to use
the service again and initiates without using MTOM then the server
should assume that they are not using MTOM (and should assume that
they can't or do not want to) and therefore reply appropriately. (I
know if I am shopping and someone makes a service claim as an option
and I intend to us it then I expect them to behave a certain way -
e.g. advertising that they take AmEX  and then refusing my AmEx card
is NOT good behavior unless of some extra circumstances)

At the message level it seems to me that it would be in very poor
taste for a service to have defined optional on the inbound and
required on the outbound - when you're talking about transports/
protocols etc. e.g. optional encryption on the inbound message and
then require it on the outbound. Why would someone design their
interface like this? And surely the client would see the assertion on
the outbound and go look for this service elsewhere. And if it's
optional on the inbound and the client doesn't use it then the same
behavior of client-is-right holds.

I'm bet I'm missing some other examples or points here. Am I missing
some more complicated issues? But I do think Umit raises a good point
about documenting some best practices at the very least about the use
of optional.

The good news is that practitioners will very quickly come to some
understanding about this when their services don't get used :-)

But should the WG have something to say on the matter? Either
recommendations or requirements?


On Aug 2, 2006, at 4:31 PM, Yalcinalp, Umit wrote:

> 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
>