- From: Doug Davis <dug@us.ibm.com>
- Date: Sun, 5 Apr 2009 21:22:33 -0400
- To: 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, "Chou, Wu (Wu)" <wuchou@avaya.com>
- Message-ID: <OFDC42787C.837D58B5-ON85257590.00053801-85257590.000791D5@us.ibm.com>
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/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?" 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
Received on Monday, 6 April 2009 01:23:24 UTC