RE: too many extension points (was Re: [Bug 6692] New: Remove Mode from the specification)

+1  I think the Body should contain all of the bits needed by the 
application - where in this case the application is WS-Eventing.   And 
let's not forget this argument in the WS-Transfer fragment support issue - 
which is why the fragment identifier should be in the Body and not a 
header (like wsman does it - or like you proposed in one of your notes).

However, there is a subtlety here that (at least for me) is being missed. 
While I think the bits of data needed by the application should be in the 
Body, that does not mean you can not use SOAP mU header to make sure the 
receiving endpoints understands a certain piece of functionality - at a 
conceptual level.  This means that I think its ok to add an mU header that 
says "I support the foo element" but the actual use of "the foo element" 
is in the Body.  If you look at the RM spec this is exactly what they do 
with the security stuff.  And this is why I liked my solution to Wu's 
proxy feature - it added a soap mU header that ensured the receiver 
understood the proxy feature (which is a pretty mindless check), but it 
added a <proxy> element to the specific EPRs that were supposed to use the 
Proxy.  Thus allowing for far more flexibility because you can turn it 
on/off on a per-EPR basis.  Something you can't do with Mode - or at least 
not withou making things really messy.

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.



Geoff Bullen <Geoff.Bullen@microsoft.com> 
04/13/2009 09:08 PM

To
Gilbert Pilz <gilbert.pilz@oracle.com>, David Snelling 
<David.Snelling@UK.Fujitsu.com>
cc
"Chou, Wu (Wu)" <wuchou@avaya.com>, "public-ws-resource-access@w3.org" 
<public-ws-resource-access@w3.org>, Doug Davis/Raleigh/IBM@IBMUS, Bob 
Freund <bob.freund@hitachisoftware.com>, "Li, Li (Li)" <lli5@avaya.com>
Subject
RE: too many extension points (was Re: [Bug 6692] New: Remove Mode  from 
the specification)






Gil,
 
My basic problem with pushing the mode concept up to the header is that 
since mode is a fundamental concept associated with Eventing and is at 
least an internal state associated with eventing implementations, then its 
manipulation should be part of the message body, not part of the message 
header.  If it is not, then where will it end?  If you wanted, you could 
put all the subscribe elements, attributes, etc in the soap header and not 
have any body at all.
 
While that is clearly silly, it does beg the discussion on where the line 
should actually be drawn.  You are coming from one side which says that 
mode is an extension, thus you should use the extension mechanism already 
defined in SOAP (using mustUnderstand=1) and an extension element in the 
body.  That makes sense from one perspective.
 
But you can look at setting the mode attribute as setting a specific 
eventing value, much in the same way as NotifyTo sets the value of the EPR 
to send events to.  Why is setting the mode any less setting a value than 
setting NotifyTo, or Filter, or ? ?  Why not put NotifyTo in the header? 
Just because mode is a flag and you can thus implement it in a header 
using a neat mustUnderstand concept, does not mean that is the right place 
to put it.
 
First tell me why the value associated with mode should be set in the 
header and not in the message body.
 
--Geoff
 
 
From: public-ws-resource-access-request@w3.org 
[mailto:public-ws-resource-access-request@w3.org] On Behalf Of Gilbert 
Pilz
Sent: Thursday, April 09, 2009 12:33 PM
To: David Snelling
Cc: Chou, Wu (Wu); public-ws-resource-access@w3.org; Doug Davis; Bob 
Freund; Li, Li (Li)
Subject: Re: too many extension points (was Re: [Bug 6692] New: Remove 
Mode from the specification)
 
Another place where @Mode is inferior is in the dynamic support of 
extensions. For example, suppose I am an Event Sink that, for whatever 
reasons, would prefer to acknowledge Notifications but would still be 
willing to create a subscription even if the Event Source didn't support 
acks (you can substitute any flavor of extension here). Using @Mode you 
would have to:

1.) send a Subscribe request with the "PushWithAcks" mode
2.) handle the resulting "mode not understood" fault
3.) send a Subscribe request w/out the "PushWithAcks" mode

You have to do this because of @Mode's "fault on non-understood" 
semantics. Using standard, XML extension mechanisms and our new, "ignore 
extensions you don't understand" model, you could define an extension to 
wse:Subscribe that meant "PushWithAcks" and a corresponding extension to 
wse:SubscribeResponse that meant "AcceptPushWithAcks". Now all you have to 
do to support the optional use of acks is to

1.) send a Subscribe request with the "PushWithAcks" extension
2.) look at the SubscribeResponse - if it doesn't contain a 
"AcceptPushWithAcks" extension then the Event Source  didn't understand 
the request to accept/process acks for Notifications

Same result as above with one less round trip. Of course, as has been 
mentioned numerous times before, if the Event Sink wanted the "don't 
create the subscription if you don't understand this extension" behavior, 
it could include a "UsingPushWithAcks" SOAP Header with 
@mustUnderstand="1".

- gp

David Snelling wrote: 
Gil, 
 
Thanks for this discussion. It also brought something back to my mind that 
has worried me about Mode. If in the end we keep it, it will need to be 
enhanced to provide even the minimal required support. Reasoning follows, 
very incomplete at this stage, but would form the basis of a new issue 
should we retain Mode.
 
So assuming Mode stays, we should encourage (at least SHOLD) ALL 
extensions to the semantics of Eventing to use the same mechanism. As soon 
as this logical step takes place, meeting the simple queuing use case 
becomes problematic not to mention more interesting cases. Where do we put 
queuing limits etc? The Mode attribute is only a URI. As Gil points out 
there are a number of places to stuff extension information, but to 
support Mode properly, we would need a <wse:PutModeExtensionDataHere/> 
element so people could use the extension points consistently.
 
I don't want this can of worms opened at all, as the specification starts 
to become very complicated (folks from the WS-Notification WG will 
remember painful discussions when this kind of bloat was discussed there). 
Eventing is a really good simple specification with clean semantics. 
Retaining Mode in (a clean and functional manner) will probably change all 
that.
 
Please let's get rid of Mode.
 
 
On 03 Apr 2009, at 21:31, Gilbert Pilz wrote:


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 
 
 
Take care:
 
    Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
    Fujitsu Laboratories of Europe Limited
    Hayes Park Central
    Hayes End Road
    Hayes, Middlesex  UB4 8FE
    Reg. No. 4153469
 
    +44-7590-293439 (Mobile)
 
 
 
 
 
 

______________________________________________________________________

Fujitsu Laboratories of Europe Limited
Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
Registered No. 4153469

This e-mail and any attachments are for the sole use of addressee(s) and
may contain information which is privileged and confidential. Unauthorised
use or copying for disclosure is strictly prohibited. The fact that this
e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield 
does
not guarantee that it has not been intercepted or amended nor that it is
virus-free.