- From: Chou, Wu (Wu) <wuchou@avaya.com>
- Date: Tue, 7 Apr 2009 14:17:47 -0400
- To: "Doug Davis" <dug@us.ibm.com>, "Gilbert Pilz" <gilbert.pilz@oracle.com>
- Cc: "Bob Freund" <bob.freund@hitachisoftware.com>, "Li, Li (Li)" <lli5@avaya.com>, <public-ws-resource-access@w3.org>
- Message-ID: <F81BDFA28AE48D4793E253362D1F7A740112AB25@300813ANEX2.global.avaya.com>
Doug,
There is another side of equation that should not be ignored, when
discussing removing Mode attribute in Delivery from WS-Eventing.
1. SOAP header with mU (mustUnderstand) is an extension given by SOAP.
If the Mode extension in WS-E is still not enough, people can use
everything you described , e.g. using SOAP mU , without any change to
WS-E specs. Mode attribute in WS-E will not harm or limit the use of
SOAP mU, since it is "&" relation of A&B&C... In other words, it is the
implementation choice, and an implementation can choice one or use both.
There is no "have to" part of your second point.
2. On the contrary, removing Mode attribute/fault of WS-E is to force
implementation to only use SOAP header, and break the existing WS-E
implementation that follows the current specs. I am not convinced that
we should remove more and more items from WS-E specs to rely on SOAP
header, even we talk about moving the same piece XML around.
3. There is a semantic difference between Mode/fault in WS-E spec vs.
removing them to rely on SOAP mU header. Mode/fault in WS-E is part of
WS-E semantics, and if they are removed to rely on SOAP mU header, it is
not a WS-E standard defined option. Surely, it can generate a different
SOAP mU fault, but it is different from a wse: fault. In other words, if
WS-E is implemented without using SOAP, its semantics will have holes.
4. There is a good reason to define semantics in the specs, not to use
SOAP extension as a mechanism to cut things off from the specs, due to
some SOAP extension alternatives.
5. We have to be sensitive that Mode attribute is in WS-E specs, and
used in many critical applications. WS-E spec is widely implemented and
we should not break/interrupt the WS-E applications and implementations,
especially when Mode attribute of WS-E can accommodate both cases.
The above comments also apply to the removal of entire Delivery element
of WS-E. In addition, there is a reason to have multiple extension
points to reflect the structure of the spec semantics. When discussing
flat/simple, it should not overlook the issue of maintaining the spec
structure and avoiding the unnecessary disruptions to existing
applications/implementations.
Thanks,
- Wu Chou.
________________________________
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Sunday, April 05, 2009 9:23 PM
To: Gilbert Pilz
Cc: Bob Freund; Li, Li (Li); public-ws-resource-access@w3.org; Chou, Wu
(Wu)
Subject: Re: too many extension points (was Re: [Bug 6692] New: Remove
Mode from the specification)
Huge +1 to the end result.
However, to be fair to the poor little picked on Mode attribute - I
don't think its an extensibility point the same way a normal xs:any is.
While it can be 'extended' to allow for new Modes, you must pick exactly
one when you Subscribe. So, in that sense its slightly different. But
nonetheless I think its still a point of confusion, not only for the
reason that have been pointed out so far, but for a whole new set that
make it unusable (ie. fundamentally flawed).
First, let's not forget about what this WG has already decided. In
issue 6425 [1] we decided that all messages are to be addressed to an
EPR - and this includes Notifications. So this, as Gil suggested,
should force us to move the wse:NotifyTo out from under the Delivery
element since it MUST always be there per 6425.
Second, there's an additional confusion point around Mode that we
haven't talked about yet: how usable is it? Let's look at Wu's "Proxy"
example. He chose to define a new Mode to add some additional
processing semantics to how Notifications are sent. However, since the
SubscriptionEnd message could need the same type of special processing,
and since the EndTo doesn't have a Mode, we need to three (3) Modes: 1)
apply Proxy to just Notifications, 2) apply Proxy to just
SubscriptionEnd messages, 3) apply Proxy to both. Let's take this one
step further. Say that someone else wanted to define another
'additional processing semantic' Mode. Following the same pattern they
would need to define their own three (3) Modes. Now, here's the really
bad part, what if someone wanted to use them both at the same time?
Someone would have to define nine (9) different Modes to cover all
possible combinations. This "extensibility point" just isn't scalable
or usable. It doesn't allow for independent "modes" to be used even
though they could be defining totally non-overlapping semantics.
In Gil's note he actually missed another extensibility point - the SOAP
envelope itself - in particular the use of mU headers. In one of my
previous notes to Wu I pointed out that through the use of mU headers he
could add his Proxy support and get the same functional end result. He
can either put all of the semantics in the mU header or he could add
some additional elements to one of the extensibility points under the
wse:Subscribe and use an mU header just to make sure those new elements
aren't ignored. Either way, this allows for any number of extensions to
specified without each needing to know about the other and without the
explosion of Modes I talked about above. This is a much cleaner,
feasible and scalable solution than what Mode currently provides.
[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=6425
thanks
-Doug
______________________________________________________
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
The more I'm around some people, the more I like my dog.
Gilbert Pilz <gilbert.pilz@oracle.com>
04/03/2009 04:31 PM
To
"Chou, Wu (Wu)" <wuchou@avaya.com>
cc
public-ws-resource-access@w3.org, Doug Davis/Raleigh/IBM@IBMUS, Bob
Freund <bob.freund@hitachisoftware.com>, "Li, Li (Li)" <lli5@avaya.com>
Subject
too many extension points (was Re: [Bug 6692] New: Remove Mode from the
specification)
Let's look at the schema for the wse:Subscribe message and it's included
DeliveryType element (I've taken the liberty of highlighting the
existing extension points - you need to view this as HTML to see what
I'm talking about):
<xs:element name="Subscribe">
<xs:complexType>
<xs:sequence>
<xs:element name="EndTo" type="wsa:EndpointReferenceType"
minOccurs="0" />
<xs:element name="Delivery" type="tns:DeliveryType" />
<xs:element name="Expires" type="tns:ExpirationType"
minOccurs="0" />
<xs:element name="Filter" type="tns:FilterType"
minOccurs="0" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax" />
</xs:complexType>
</xs:element>
<xs:complexType name="DeliveryType" mixed="true">
<xs:sequence>
<xs:element ref="wse:NotifyTo" minOccurs="0" maxOccurs="1" />
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="Mode" type="xs:anyURI" use="optional"
default="http://schemas.xmlsoap.org/ws/2004/08/eventing/DeliveryModes/Pu
sh <http://schemas.xmlsoap.org/ws/2004/08/eventing/DeliveryModes/Push> "
/>
<xs:anyAttribute namespace="##other" processContents="lax" />
</xs:complexType>
If I was a developer interested in extending WS-Eventing, I would find
this situation confusing. Ignoring the fact that the wse:NotifyTo
element is an EPR and can itself be extended, there are five (5)
different ways I can extend the wse:Subscribe message (or, if you count
element/attribute extension of the same element as a "single way", there
are three (3)). What makes this even more confusing is that not all of
these extension points have the same processing rules. The XML extension
points (in black-bold) are subject to the following, recently accepted,
language:
The elements defined in this specification MAY be extended at the points
indicated by their outlines and schema. Implementations MAY add child
elements
and/or attributes at the indicated extension points but MUST NOT
contradict the
semantics of the parent and/or owner, respectively. If a receiver does
not
recognize an extension, the receiver SHOULD ignore that extension.
Senders MAY
indicate the presence of an extension that has to be understood through
the use
of a corresponding SOAP Header with a soap:mustUnderstand attribute with
the
value "1".
Whereas the WS-Eventing specific extension point (in blue-bold) is
subject to the following:
If the event source does not support the requested delivery mode, the
request MUST fail, and the event source MAY generate a
wse:DeliveryModeRequestedUnavailable fault indicating that the requested
delivery mode is not supported.
I think the common reaction to this situation would be "WTF
<http://thedailywtf.com/Default.aspx> ?" This needs to be simplified so
that, if you want to extend WS-Eventing, you aren't required to navigate
through a maze of different extension points that may or may not result
in different processing behavior (i.e. "What is the difference between
extending /wse:Subscibe/wse:Delivery or just /wse:Subscribe?").
Clearly the "Mode" attribute, with its conflicting semantics, should be
removed. In addition to this, we need to remove the "Delivery" element
and it's extension points (obviously we would move the wse:NotifyTo
element up into the wse:Subscribe element). What we would be left with
would look like this:
<xs:element name="Subscribe">
<xs:complexType>
<xs:sequence>
<xs:element ref="wse:NotifyTo" minOccurs="0" maxOccurs="1" />
<xs:element name="EndTo" type="wsa:EndpointReferenceType"
minOccurs="0" />
<xs:element name="Expires" type="tns:ExpirationType"
minOccurs="0" />
<xs:element name="Filter" type="tns:FilterType"
minOccurs="0" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax" />
</xs:complexType>
</xs:element>
What you have now is really two ways to extend the wse:Subscribe
request. You can extend the wse:Subscribe message (through either an
attribute or an element) if you want an extension that is specific to
WS-Eventing, or you can extend the NotifyTo EPR if you want an extension
that operates at the WS-Addressing level (i.e. across any technology
that uses WS-Addressing).
- gp
Chou, Wu (Wu) wrote:
Doug,
Mode attribute in WS-E is to specify the additional required event
delivery behavior or required application/business logic extensions that
the event source must understand/support before being allowed to accept
the event subscription.
My understanding is: "push_event_thru_proxy" is for all events delivery
from the Subscribe. As such, it covers SubscriptionEnd event. The Mode
attribute also allows to specify fine grained application logic to
control the event delivery. If you want, more fine grained event
delivery logic/procedure can be easily added to Mode attribute to
control the event delivery, e.g.
"push_thru_proxy_for_subscriptionend_event_only",
"push_thru_proxy_for_non_subscriptionend_event", etc.
Mode attribute in WS-E provides a standard extension point to add
application specific logic and behavior to event delivery, so that it
can enforce the required procedure/logic for business applications when
using WS-Eventing for event delivery.
Thanks,
- Wu Chou.
>Wu,
> since its too easy for things to get lost in these long messages, let
me
focus on one particular aspect of this.
>Surely the idea of using a proxy
for sending messages is not WS-Eventing specific. How do you support
sending any other asynchronous message (non-NotifyTo messages) thru a
proxy?
>Need a clarification on th, e.g. a general question, a question for
WS-E or a question for WS-E plus Mode.
>For example, the SubscriptionEnd message.
thanks
-Doug
Wu Chou, IEEE Fellow, Ph.D. | Director |Dialogue System Research | AVAYA
| 233 Mt. Airy Road| Rm. 2D48 | Basking Ridge, NJ 07920 | Voice/Fax:
908-696-5198 / 908-696-5401 | wuchou@avaya.com
<blocked::mailto:wuchou@avaya.com>
Received on Tuesday, 7 April 2009 18:18:43 UTC