- From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
- Date: Wed, 27 Sep 2006 08:47:44 -0700
- To: "Sergey Beryozkin" <sergey.beryozkin@iona.com>, "Prasad Yendluri" <prasad.yendluri@webmethods.com>, "Daniel Roth" <Daniel.Roth@microsoft.com>, <public-ws-policy@w3.org>
- Message-ID: <2BA6015847F82645A9BB31C7F9D64165023979BE@uspale20.pal.sap.corp>
Hi,
Quick Question. Isn't 5 equivalent in spirit to the wsp:local marker as
proposed?
--umit
________________________________
From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
Sent: Wednesday, Sep 27, 2006 8:37 AM
To: Yalcinalp, Umit; Prasad Yendluri; Daniel Roth;
public-ws-policy@w3.org
Subject: Re: ISSUE 3564: Optional Assertions may not be usable
in all cir cumstances
Hi
IMHO, using 'capability' and 'requirement' as different terms is
confusing.
Personally I see both unoptional and optional assertions as
those marking various capabilities. For ex, optional mtom assertion and
non optional sp:httpstoken assertion are capabilities in that a provider
is capable of supporting optimized mtom serialization and htts security.
I'm sure there can be many more interpretations there.
I believe if following simple assumptions/rules are made clear
in the text, then there won't be a source for any confusions/arguments.
1. wsp:optional can be used to mark an assertion as being
optional. This means a client is free to ignore it. This is backed up by
the spec mandating wsp:optional is not part of the normal form
expression, per every assertion marked as wsp:optional in the compact
form there will be at least two alternatives with one of them including
the optional assertion and with the other one not.
2. wsp:optional marks an assertion which MAY be processed/noted
by a client. By no means it's supposed to give any signals to a
(provider) entity. A provider entity is guaranteed to support all policy
assertions listed in a given policy, those marked as wsp:optional and
those which are not. This is again backed up by the fact that
wsp:optional is not present in the normal expression form.
3. IMHO, reserving wsp:optional as a means to mark only those
assertions which identify behaviours which may be engaged during the
interaction between entities, is confusing. Clearly, there's a range of
policy assertions which have no behavioural requirements on the
consuming entity and these assertions are normal citizens of the
WS-Policy landscape. Such assertions can also be marked optional, see
also 5.
4. Given 1-3 above I believe primer/guidelines shouild be
updated to clearly state 1. and 2. and say that wsp:optional can be used
to mark assertions which identify behaviours which may be engaged and
assertions which identify provider capabilities with no behavioral
requirements on the consuming entity
5. I know it's a controversial one but : given 1-4 and the fact
that capabilities with no behavioral requirements have no effect on the
consuming entity and can only be used for the selection, primer should
recommend marking such capabilities as optional (Apologies for repeating
it all again and again, I'll open an issue for it be properly tracked).
Otherwise unaware (client) entities will unnecessarily fail. I believe
policy authors will put wsp:optional on such assertions anyway, but
first they'll learn the hard way that their services can only be
consumed by a limited set of entities. Should 3 be addressed then I feel
there won't be any disagreement here too.
Cheers, Sergey Beryozkin
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".
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.
The marker to indicate that an interaction will take 10
seconds response time is more of a property of the service. I do not
consider this a capability that is selectively engaged. 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. 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.
Lets see what others think. After we solidify the
terminology, it is easy to fix the guidelines, primer, etc.
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-framew
ork.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-framew
ork.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
-policy-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
Received on Wednesday, 27 September 2006 15:43:32 UTC