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

Hi Umit,

 

See my response inline.

 

Prasad

 

  _____  

From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com] 
Sent: Tuesday, September 26, 2006 5:07 PM
To: Prasad Yendluri; Daniel Roth; public-ws-policy@w3.org
Subject: RE: ISSUE 3564: Optional Assertions may not be usable in all cir
cumstances 

 

Hi Prasad, 

 

It seems to me that perhaps the problem is the assumed definition of
capability in the community and lets tease out a bit. You are right, there
is an anomaly, but I am not sure I agree with the term "optional
requirement". 

 

PY>Yes we need a clear definition of what we mean by capability. As clearly
demonstrated by the exchange on this thread, there are multiple (at least
two) interpretations. Your interpretation of capability is not what I was
expecting but, I can grant that it can be considered a capability (of the
provider), in that the provider can do it, if the consumer (client) side
engages it. 

 

When MTOM assertion is present with optional="true" on a msg, I do not
understand why you think it as a requirement. From the perspective of the
service, it is an optimization that is available but NOT necessary to be
engaged. Hence, IMO this fits to a definition of a capability, albeit
inherent at runtime. 

PY>Well like I said, it is one interpretation of capability, something the
service side can handle if the client side engages it. Per another
interpretation, it is a requirement on the client to engage it, even though
the client has the option not to engage it, as it is "optional". I tend to
think of capability as something the provider side declares that it is
capable of doing (like guaranteed under 10 msec. response time). All
assertions that depend on the client (consumer) side doing something, fall
in the "requirement" category from my perspective. Requirements can be
optional or mandatory, based whether the consumer side must do it or not.
Capabilities have no such client side impact. They are pure provider side
declarations, which if the provider does not meet or deliver put the
provider out of policy.

 

The marker to indicate that an interaction will take 10 seconds response
time is more of a property of the service. 

PY>Well we don't have anything called a "property" in WS-Policy. I consider
it a capability; it is a 10msec response time guarantee. 

 

I do not consider this a capability that is selectively engaged. 

PY>By my definition of capability, it may or may not be selective. It is
what the provider declares it can deliver and if the provider does not
deliver it, it is out of policy.

 

In essence, the service does not advertise that "hey I can response to you
in 10 seconds, but you must do sth in order to get this kind of quality of
service". It just says that you will get this behaviour. IMO, this is just
an inherent property of the QoS, not a capability. 

PY>Well we clearly have different view points here. I see that as a clear
declaration of capability (sure a QoS related one in this case).

 

 It is a requirement of the service to provide you this QoS. The burden is
on the provider (or whomever) that advertises this assertion as it is a
requirement on their part. Just like a marker that advertises whether the
interactions with a service guarantees confidentiality ("we won't sell your
information to third parties".). You may be able to take legal action if
they do if they did not comply with the advertised policy which they
advertise. The client does not do or no choice in altering the outcome, but
it is just there. I agree that this expression of this category should be
part of the WS-Policy assertions. I would not call this a capability
however. In this case, the #2 is a requirement, but the requirement is on
the provider where the client does not need to do anything. 

 

In the end it all boils down to what we mean by "capability" and whether we
need a glossary to explain it. The MTOM category IMO is certainly NOT a
requirement. 

PY>The specification states that a "policy assertion" identifies either a
"requirement, or capability of a policy subject." And it does not define a
capability to be an optional assertion, whereas the primer is giving that
interpretation.  I don't think that is accurate explanation of what the spec
states, as it stands now. It is certainly subject to interpretation and
contention.  

 

I am not sure why you don't see MTOM category to be not a requirement? If
there is no "optional" on the assertion that calls for engaging MTOM by the
client, then * it is * a requirement on the client to use MTOM encoding on
the messages it sends and expect to receive and handle MTOM encoded
messages, is it not?

 

Lets see what others think. After we solidify the terminology, it is easy to
fix the guidelines, primer, etc. 

PY> Yep, fine with me, We clearly need a concrete definition of requirement
and capability in the spec, given the demonstarted scope for interpretation
here.

 

Cheers,

 

--umit

 

 

 

 


  _____  


From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Prasad Yendluri
Sent: Friday, Sep 22, 2006 12:18 PM
To: Daniel Roth; Yalcinalp, Umit; public-ws-policy@w3.org
Subject: RE: ISSUE 3564: Optional Assertions may not be usable in all cir
cumstances 

Dan, Maryann, Umit et. al,

 

The spec defines  a policy assertion to be, " A policy assertion
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2006/ws/policy/ws-policy-framework.
html#policy_assertion>  identifies a behavior that is a requirement or
capability of a policy subject
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2006/ws/policy/ws-policy-framework.
html#policy_subject> ."

 

Where as the primer (best practices doc ?) clarifies, "Optional Policy
assertions are assertions that express capabilities."

 

I tend to attributes two types of meaning to capabilities. (1) Things the
provider can do if the requester tries to engage it (e.g use of MTOM/XOP
encoding). That is, optional requirements, which is the interpretation that
the primer has taken. However I can see another kind of capabilities (ii)
capabilities e.g. a service declares it can do but there is no requirement
on the client. For example, this service receives mail for xyz.com domain,
but it also routes mail to domains other than xyz.com (serves as a mail
gateway). Can a service declare that "capability" as an assertion? It is
useful for the (mail) client to know so that, it can send mail addressed to
other domains to this service. Another example is, a service that boasts a10
msec response time. My understanding is that declaration of capabilities
such as these is a valid use of policy assertions. 

 

If so, the primer / best practices doc's interpretation of capability is
incomplete and perhaps misleading? It would be useful to account for the use
case #2 above also. 

 

Honestly, I would like to call optional requirements just that (and not
capabilities), as there may not be any capability implication to a service
in general, if or not a client engages an optional requirement.  E.g. an
optional requirement to follow-on an online Purchase Order request via
hard-copy sent to a USPS address.

 

Regards,

Prasad

 

-----Original Message-----
From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Daniel Roth
Sent: Friday, September 22, 2006 11:36 AM
To: Yalcinalp, Umit; public-ws-policy@w3.org
Subject: RE: ISSUE 3564: Optional Assertions may not be usable in all
circumstances 

 

I have reviewed the primer material on using wsp:Optional that Maryann and
Umit proposed [1].  Other than a few minor edits (see attached) I think the
proposal looks good.  The attached doc contains:

 

- Various small editorial cleanups.

- I believe the mtom assertion in Example 5-2 should be marked
wsp:Optional="true" since it is referred to as an optional assertion.

- The first bullet point seems to indicate that you must engage an optional
behavior.  I think the intention was to state that if a provider decides to
support an optional assertion it needs to have some way of figuring out
which alternative is being used, either by looking at the wire or by some
other means:

 

NEW TEXT FOR BULLET #1:

*       The engagement of the optional behavior must be explicit on the wire
or through some other mechanism so that the provider can determine that the
optional behavior is engaged.

 

I suggest that we accept Maryann and Umit's text with these minor changes as
satisfying proposal option C for this issue.

 

Daniel Roth

 

[1]
http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/att-0054/ws-pol
icy-assertionauthors-V1.html#optional-policy-assertion

 

-----Original Message-----

From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Asir Vedamuthu

Sent: Friday, August 11, 2006 4:56 PM

To: Yalcinalp, Umit; public-ws-policy@w3.org

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