Re: [Bug 6692] New: Remove Mode from the specification

While I'm not 100% sure we can remove 'mode' entirely (I'm getting close 
though) I do agree with David on the notion of moving the transport logic 
out of the WSRA specs. WSAddressing has provided us a means to represent a 
destination for messages - an EPR.  Is a wsa:ReplyTo really that different 
from wse:NotifyTo ?  In previous discussions on this topic I've hear 
arguments both ways but I tend to side with "no its not different" - 
mainly because I do believe in the composable architecture that WS is 
suppose to be promoting.  For example, if notifications can be broadcast 
then why not responses?  I have a hard time imagining why a usecase for 
one EPR could not just as easily apply to all EPRs.  So, I'd like to 
understand the usecases for why WS-Eventing might require more than just 
an EPR and why those needs would never also apply to wsa:ReplyTo. 

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.



David Snelling <David.Snelling@UK.Fujitsu.com> 
Sent by: public-ws-resource-access-request@w3.org
03/17/2009 04:55 AM

To
public-ws-resource-access@w3.org
cc

Subject
Re: [Bug 6692] New: Remove Mode from the specification






Folks,

On 17 Mar 2009, at 05:13, Geoff Bullen wrote:

> Issue 6692 - WS-Eventing: Remove Mode from the specification
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6692
>
> It seems the intent here is to remove the "mode" element from the 
> specification.  The main reason behind this seems to be that the WG 
> can't think of any reason to have it.  Mode seems to refer to 
> "transport" kinds of concepts - how things are delivered, whereas 
> Format refers to the format of what is delivered.  This makes 
> sense.  So the question is, do we need to be able to specify 
> transport concepts in Eventing, or do they all just compose in nicely?

Agreed, this is basically the question.

> The issue description mentions that complex queuing and distribution 
> can be supported without Mode, as can MakeConnection.  In terms of 
> MakeConnection, we should specifically talk about that as part of 
> issue 6432.  Certainly we cannot close on this issue before we close 
> on 6432.

To close (as proposed) on this one first, might simplify the decision 
on 6692, but they are not really linked. As long as there is a 
solution to 6432 that does not require a "Mode", the two issues are 
independent. MakeConnection is one solution and I can think of another 
following the pattern of PullPoint published in WS-Notification.

> As for the general need for a Mode, it is not clear to me at all 
> that other specs will just compose nicely on top of Eventing and 
> work without having to specify anything specific about them to the 
> Eventing Environment.

The basic reason for confidence here is that the delivery concept 
should be dealt with at a lower level in the stack, e.g. transport etc 
rather than in the eventing application.

>  Exactly how do you propose that a queuing system will interact with 
> Eventing?

A higher level specification (e.g. WS-BrokeredNotification) implements 
the queueing infrastructure and subscribes to the eventing source. The 
EPR simply contains the address to the queue input and the rest is 
done by queue implementation. This keeps the complexity out of the 
eventing spec, which I assume we want as simple as possible. Leaving 
Mode in encourages more complexity. Fore example, if we define a Mode 
for queuing, we would need a stack of parameters to control it.

>  How would a multicast solution work?

Again, the key is in the infrastructure. I subscribe to the source 
with an EPR specifying the multicast port I wish to use. The eventing 
application is completely protected from this complexity.

>  Can you provide a basic example of how you would imagine both of 
> these scenarios would compose (without using Mode)?

The rough guide is above, but you get the drift. The main aim is to 
simplify eventing. Leaving Mode in invites us to define a few common 
modes to ensure interoperability. This in turn encourages a lot of 
potential complexity, queuing parameters etc. When we have parallel 
composable technologies to handle these, why not use them. Mostly I am 
thinking WS-Addressing here.

> We believe that both of these (and also MakeConnection) will require 
> some knowledge and configuration during the Subscribe Request, and 
> if that is true, then the Mode element is the right place for those 
> extensions to be placed.

I think all that information should be invisible to the eventing level 
of the application. The transport layer should handle this and the EPR 
contains all the facilities we need. I will admit some guidance in a 
primer might be advisable. Simple specs (where there isn't a knob for 
every use case) have this need sometimes.

Geoff, thanks for the prompt. I was expecting to write this email at 
some time, now it's done :-) Talk to you all tonight.

>
>
> --Geoff
>
> -----Original Message-----
> From: public-ws-resource-access-notifications-request@w3.org 
[mailto:public-ws-resource-access-notifications-request@w3.org 
> ] On Behalf Of bugzilla@wiggum.w3.org
> Sent: Thursday, March 12, 2009 8:37 AM
> To: public-ws-resource-access-notifications@w3.org
> Subject: [Bug 6692] New: Remove Mode from the specification
>
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6692
>
>           Summary: Remove Mode from the specification
>           Product: WS-Resource Access
>           Version: CR
>          Platform: PC
>        OS/Version: All
>            Status: NEW
>          Severity: major
>          Priority: P2
>         Component: Eventing
>        AssignedTo: public-ws-resource-access-notifications@w3.org
>        ReportedBy: david.Snelling@UK.Fujitsu.com
>         QAContact: public-ws-resource-access-notifications@w3.org
>
>
> The concept of Mode is redundant in the current version of the 
> specification.
> All events can be thought of as being delivered. There is no actual 
> definition
> of "Push Mode" and no other recommended modes. We even have a 
> MakeConnection
> strategy to allow clients behind NATs to fetch events. Likewise, 
> strategies for
> complex queuing and distribution are supportable without adding 
> additional
> modes and are outside the scope of this specification.
>
> Proposal: Remove /s:Envelope/s:Body/*/wse:Delivery/@Mode from the 
> specification
> and all references to Push Mode. A simple explanation of the 
> delivery idea and
> a pointer to some of the techniques available will be needed.
>
>
> -- 
> Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the QA contact for the bug.
> You are the assignee for the bug.
>
>
>

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.