Re: Issue 6429: proposal 2, related to 6401

Li,

You make some good points. I wonder if we aren't over-complicating our 
solution by insisting on the literal use of WSDL? Can we get Team 6401 
together after today's concall and brainstorm on this a bit?

- gp

On 5/19/2009 7:15 AM, Li, Li (Li) wrote:
>
> Gil,
>
>  
>
> I agree this is a viable model to partition notifications that is 
> inline with WSDL 1.1 usage of port [1].
>
>  
>
> But I have two concerns for "stick to" this approach:
>
> 1)       Due to security, money or modeling constraints beyond WS-E, 
> sometimes different ports bind to the same URI and the event source 
> won't be able to tell to which port a message is sent, because the 
> port names are not conveyed in the SOAP message.
>
> 2)       Even if a port binds to a unique URI, the event source has to 
> use this URI to determine the event delivery format. For 
> implementations, this sorts of creates a dependency from event 
> delivery logic to physical URI, which makes the code less portable 
> when the event source service is redeployed to a different URI.
>
>  
>
> A standard message level format URI seems to be able to avoid these 
> problems. So I feel maybe we should leave both port based and message 
> based options for developers. Thanks,
>
>  
>
> Li
>
>  
>
> [1] http://www.w3.org/TR/wsdl#_services
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
> *Sent:* Monday, May 18, 2009 4:46 PM
> *To:* Li, Li (Li)
> *Cc:* Doug Davis; public-ws-resource-access@w3.org; Chou, Wu (Wu)
> *Subject:* Re: Issue 6429: proposal 2
>
>  
>
> Li,
>
> It seems to me that if we were to stick to a model in which there was 
> a one-to-one correspondence between a Subscription Endpoint and a 
> Notification WSDL (i.e. "if I send a Subscribe to this URI I will get 
> the messages defined in that WSDL and no other") then you don't need 
> to worry about setting the Format parameter to wrapped. If an Event 
> Source links to the "standard Notification WSDL for Wrapped" (the one 
> that includes the definition of GenericSinkPortType), the Event Sink 
> will simply know/expect that the messages will be wrapped as part of 
> the usual processing of Notification WSDLs. In other words, support 
> for "wrapped" will cease to be a special case and will simply fold 
> into the normal processing of Notification WSDLs.
>
> - gp
>
> On 5/18/2009 8:05 AM, Li, Li (Li) wrote:
>
> Hi Doug,
>
>  
>
> For question 1, I think the reason was that wsa:Action is required 
> only if wsa is used via the wsam:Addressing policy assertion. 
> Therefore, we made it optional.
>
>  
>
> For question 2 and 3 plus <way off topic>, I agree that a better place 
> to answer them is 6401 thread which just opened up. The statement in 
> 6429 about sending WSDL in EPR or MEX is prior to the 6401 solution 
> based on Gil's idea. I therefore deleted those statements to make 6429 
> to focus on just defining a static WSDL interface, while leaving the 
> interface binding and discovery to 6401 discussions. The new version 
> with change marks is attached.
>
>  
>
> I think 6401 offers a better solution for these cases and here is how 
> it might work:
>
>  
>
> 1) Support event source WSDL has an event source port p1 that supports 
> the wse:Subscribe, and p1 has a policy assertion (proposed by 6401), 
> linking it to a binding b1 of port type "GenericSinkPortType", in the 
> notification WSDL.
>
>  
>
> 2) the subscriber has to find port p1 to subscribe somehow.  From 
> there it can find the binding b1 and the port type of the wrap interface.
>
>  
>
> 3) the event sink engages the proper module that implements the wrap 
> interface.
>
>  
>
> 4) the subscriber sends a Subscribe message with the format parameter 
> set to select the wrap delivery format.
>
>  
>
> 5) the notifications are delivered accordingly.
>
>  
>
> Please let me know if this makes sense to you.
>
>  
>
> Thanks,
>
>  
>
> Li
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Doug Davis [mailto:dug@us.ibm.com]
> *Sent:* Monday, May 18, 2009 8:48 AM
> *To:* Li, Li (Li)
> *Cc:* gilbert.pilz@oracle.com <mailto:gilbert.pilz@oracle.com>; 
> public-ws-resource-access@w3.org 
> <mailto:public-ws-resource-access@w3.org>; Chou, Wu (Wu)
> *Subject:* Re: Issue 6429: proposal 2
>
>  
>
>
> Hi Li,
>   three questions/comments:
> 1 - any reason why the actionURI on each event is optional?  Since 
> wsa:Action is required (in the raw case) I would have thought that the 
> "actionURI" on each event in the wrapped case would be require too. 
>  That would provide a natural 1-1 mapping between wrapped and unwrapped.
> 2 - this probably isn't specific to issue (I think it might be related 
> to the advertising of notifications issue too), but in the Appendix 
> you talk about how the source can get this WSDL from the NotifyTo EPR 
> or by using MEX against the Sink.  How does the Source know which 
> wsdl/port to look at?  Is the "GenericSinkPortType" name a 
> static/well-defined name that the Source will know to look for?  Is 
> this WSDL static or are runtimes expected to analyze it in real-time? 
> I'm just trying to get my head around how all of this fits together 
> and which pieces are supposed to be programmatically used by the 
> runtime (or tooling) and which are meant to be for informational 
> purposes - and in practice those things will just be implied or 
> hard-coded.
> 3 - related to the previous one... what if there is no NotifyTo EPR?
>
> <way off topic>
> Sometimes I wonder if as part of the SubscribeResponse the Source 
> should include the WSDL of what the Sink is expected to support. 
>  Between all of the various options (extensions) available (format, 
> wrapped, raw, batching...) it seems like the actual WSDL that both 
> sides will use won't be known until all options of a particular 
> Subscribe are analyzed - and its only at that point that the shape 
> (wsdl) of the messages can be determined.  Sure someone could write a 
> WSDL that contains all possible variants but then it is really of any 
> use?  And are we just creating a combinatorial explosion of WSDL's if 
> we even try.  Of course, the other option is to just have "implied 
> semantics/wsdl".
> </way off topic>
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com <mailto:dug@us.ibm.com>
> The more I'm around some people, the more I like my dog.
>
>
> *"Li, Li (Li)" <lli5@avaya.com> <mailto:lli5@avaya.com>*
>
> 05/15/2009 03:59 PM
>
> 	
>
> To
>
> 	
>
> <public-ws-resource-access@w3.org> 
> <mailto:public-ws-resource-access@w3.org>
>
> cc
>
> 	
>
> "Chou, Wu (Wu)" <wuchou@avaya.com> <mailto:wuchou@avaya.com>, Doug 
> Davis/Raleigh/IBM@IBMUS, <gilbert.pilz@oracle.com> 
> <mailto:gilbert.pilz@oracle.com>
>
> Subject
>
> 	
>
> Re: Issue 6429: proposal 2
>
>  
>
>  
>
> 	
>
>  
>
>
>
>
> Reload the complete proposal that fixed a small typo in the WSDL.
>
> Gil proposed an alternative way to represent the current actionURI, but
> this disagreement was resolved and Gil accepted the current proposal.
> Please see the attached email for correspondent.
>
> Thanks,
>
> Li Li
>
> [attachment "wse_6429.doc" deleted by Doug Davis/Raleigh/IBM]
>
>
>
> ----- Message from "Gilbert Pilz" <gilbert.pilz@oracle.com> 
> <mailto:gilbert.pilz@oracle.com> on Thu, 14 May 2009 16:40:44 -0400 -----
>
> *To:*
>
> 	
>
> "Li, Li (Li)" <lli5@avaya.com> <mailto:lli5@avaya.com>
>
> *cc:*
>
> 	
>
> "Doug Davis" <dug@us.ibm.com> <mailto:dug@us.ibm.com>, "Chou, Wu (Wu)" 
> <wuchou@avaya.com> <mailto:wuchou@avaya.com>
>
> *Subject:*
>
> 	
>
> Re: FW: Agenda 2009-05-12 WS-RA distributed meting
>
>  
>
>
> Yes, I can live with the current proposal.
>
> - gp
>
> On 5/12/2009 9:57 AM, Li, Li (Li) wrote:
> Doug, Gil:
>
> I am assigned the following AI:
> -Issue-6429 Eventing: Standardize Wrapped Event Sink
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6429
>  -Li (Action-42)
>
> which is pending on the decision on where to put the notification action
> verb. The current proposal puts it inside the SOAP body whereas Gil's
> proposal puts it in the SOAP header.
>
> We are ok with the current proposal which was based on Doug's
> suggestion. Gil, can you live with the current proposal? If not, can you
> and Doug work out some compromise so we can close this AI?
>
> Thanks,
> Li
>
> -----Original Message-----
> From: member-ws-resource-access-request@w3.org 
> <mailto:member-ws-resource-access-request@w3.org>
> [mailto:member-ws-resource-access-request@w3.org] On Behalf Of Bob
> Freund
> Sent: Tuesday, May 12, 2009 8:40 AM
> To: member-ws-resource-access@w3.org 
> <mailto:member-ws-resource-access@w3.org>
> Subject: Agenda 2009-05-12 WS-RA distributed meting
>
> Distributed meeting
>
> Time: 15:30-17:00 EDT
>
> Dial-in and IRC according to usual practice[5]
>
> Topic: Opening
> Roll
> Selection of scribe, see scribe list[1]
> Approval of this Agenda
> Approval of minutes from the 2009-0-05 distributed meeting[2]
>
> Note that "*" preceding an issue is chair's suggestion of priority  
> discussion
> "#" ought to be quickly closable (But the chair is often surprised)
> Items marked "X" in the chair's opinion need seasoning
>
> Topic: WG Administrivia
> -Reminder to record your frf attendance[4] BEFORE 23:59 Boston time on  
> 5/26
> -Introduction, new WG Member Paul Nolan
>
> Topic: May Snapshot
> -folks ready with review of incorporated issues?
>
> Topic: Task Team Progress
> -Team 6401
> -Activity to consolidate Mode Proposals (Geoff, Gil, Who?) Do we have  
> one list that folks think is "the list"?
>
> Topic: Action Items where are we?
> http://www.w3.org/2002/ws/ra/tracker/actions/open
>
> Topic: New Issues
> -none-
>
> Topic: Issues with proposals
> Common:
> -none-
>
> Enumeration:
> #-Issue-6860 wsen:EnumerationEnd/wsen:EnumerationContext is unusable  
> and unnecessary http://www.w3.org/Bugs/Public/show_bug.cgi?id=6860 -Pilz
>
> Eventing:
>
> X-Issue-6692 WS-Eventing: Remove Mode from the specification
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6692
>  -Snelling
> #-Issue-6696 Eventing: When to check the EPRs
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6696
>  -Davis
> *-Issue-6724 Eventing: define resource representation
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6724
>  -Davis
> #-Issue-6850 Eventing: remove unneeded text in conformance section
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6850
>  -Davis
>
> Transfer:
> #-Issue-6594 Transfer: Add extensibility points for WS-Transfer  
> wrappers http://www.w3.org/Bugs/Public/show_bug.cgi?id=6594 -Davis -
> Bullen (Action-57)
> #-Issue-6672 Transfer: Non deterministic behavior of PutResponse
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6672
>  -Davis -Bullen (Action-57)
> #-Issue-6673 Transfer: Non deterministic behavior of Create
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6673
>  -Davis -Bullen (Action-57)
>
> *-Issue-6712 Transfer: Create is ambiguous
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6712
>  -Davis (Action-59)
> #-Issue-6849 Transfer: remove WSA comment in conformance section
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6849
>  -Davis
>
> Resource-Transfer:
> -Issue-6699 RT: ability to assign metadata during create
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6699
>  -Davis
>
> MEX:
> -Issue-6500 MEX: Wrappers around GetMetadata
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6500
>  -Bullen (6398)
>
> ===
>
> Topic: Issues for general discussion
> All:
> #*-Issue-6694 All: Which specifications have implicit operations?
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6694
>  -Davis
>
> Resource-Transfer:
> -Issue-6422 RT - Introduces An Ad Hoc Boxcarring Mechanism
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6422
>  -Bullen
> -Issue-6575 RT - Fragment Put should allow computed values
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6575
>  -Bullen
> -Issue-6634 RT - Document algorithm for modify
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6634
>  -Bullen
> -Issue-6635 RT - Outer resource with individually addressable inner  
> resources http://www.w3.org/Bugs/Public/show_bug.cgi?id=6635 -Bullen
> -Issue-6636 RT - Add example of resource after the create
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6636
>  -Bullen
>
> Eventing:
> -Issue-6435 WS-Eventing needs state table to fully describe protocol
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6435
>  -Pilz
> -Issue-6642 WS-Eventing does not describe how to advertise policy for  
> Subscription Managerhttp://www.w3.org/Bugs/Public/show_bug.cgi?id=6642  
> -Pilz
>
> MEX:
> -Issue-6406 WS-MEX - define policy
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6406
>  -Davis
> -Issue-6463 MEX-Attaching Policy to WS-Mex GetMetadata
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6463
>  -Warr
> #*-Issue-6674 MEX should reference latest W3C REC versions of WS-
> Policy and WS-PolilcyAttachment
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6674
>  -Pilz
> -Issue-6679 MEX's stance towards metadata scope and semantics needs  
> clarification http://www.w3.org/Bugs/Public/show_bug.cgi?id=6679 -Pilz
> -Issue-6680 MEX Section 3.2 has inconsistent properties
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6680
>  -Pilz
>
> Enumeration:
> -Issue-6436 WS-Enumeration needs state table to fully describe  
> protocol http://www.w3.org/Bugs/Public/show_bug.cgi?id=6436 -Pilz
>
> AOB
> Adjourn
>
> ===
> N.B.
> Issues needing owners
> -Issue-6701 Enumeration: Create Infoset description
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6701
> -Issue-6702 MEX: Create Infoset description
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6702
> -Issue-6703 RT: Create Infoset description
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6703
> -Issue-6704 Transfer: Create Infoset description
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6704
>
> Needing Proposals prior to Discussion:
> Transfer:
> X-Issue-6413 Transfer- Move Fragment support from RT to Transfer
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6413
>  -Davis -Warr
> -Issue-6533 Transfer: Safeness of operations
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6533
>  -Lafon (Action-45)
> -Issue-6551 RT - Message processing time exceeded
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6551
>  -Bullen (Action-13)
> -Issue-6632 RT - Define fault for cases where the GetResult is too  
> large http://www.w3.org/Bugs/Public/show_bug.cgi?id=6632 -Bullen  
> (Action-32)
> -Issue-6633 RT - Namespaces in updates
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6633
>  -Bullen (Action-32)
> -Issue-6691 WS-T/RT - Reconcile faults
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6691
>  -Warr (Action-51)
>
> Enumeration
> -Issue-6403 Enumeration - define policy
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6403
>  -Davis (Action-60) -Bullen
>
> Resource-Transfer:
> -Issue-6407 WS-RT - define policy
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6407
>  -Davis (Action-25)
> -Issue-6549 RT - Create focused on resource fragments
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6549
>  -Bullen
> -Issue-6550 RT - Support for XSLT and XQuery in PUT
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6550
>  -Bullen (Action-11)
> -Issue-6552 RT - Lifecycle metadata for Create
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6552
>  -Bullen (Action-12)
> -Issue-6576 RT - No Fault Defined for Mi6432smatch between  
> ResourceTransfer header and message body
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6576
>  -Bullen (Action-28)
> -Issue-6578 RT - SideEffects applies to other faults
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6578
>  -Bullen (Action-29)
> -Issue-6579 RT - Bad fragment values with Create
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6579
>  -Bullen (Action-30)
> -Issue-6603 RT - Inconsistencies in CreateResponse message
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6603
>  -Bullen (Action-20)
>
> Eventing:
> -Issue-6401 WS-Eventing Notifications violates WS-I BP
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6401
>  -Davis (Action-61) (Task Team Li Pilz)
> -Issue-6402 WS-Eventing - define policy
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6402
>  -Davis (Action-24)
> -Issue-6421 Eventing-Extension point in reply message of Unsubscribe
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6421
>  -Bullen (Action-27)
> -Issue-6429 Eventing: Standardize Wrapped Event Sink
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6429
>  -Li (Action-42)
> -Issue-6700 Eventing: Complete Infoset description
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6700
>  -Wu
>
> MEX:
> -Issue-6411 WS-MEX: no way to create metadata
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6411
>  -Davis (Action-26)
>
> ===
>
> Blocked with dependancy on (issue):
>
> Eventing:
> X-Issue-6430 Eventing-Remove Attribute wse:EventSource
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6430
>  -Li (6401)
> X-Issue-6661 WS-Eventing Appendix I is incomplete and incorrect
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6661
>  -Pilz (6401)
> X-Issue-6432 WS-Eventing Push delivery mode does not work when the  
> subscriber is not
> addressablehttp://www.w3.org/Bugs/Public/show_bug.cgi?id=6432
>  -Pilz -Davis (6692)
> X-Issue-6803 RT: Is this functionality required?
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6803
>  -Bullen (6413)
>
> ===
>
> [1] http://www.w3.org/2002/ws/ra/chair-tools/scribelist.html
> [2] http://www.w3.org/2002/ws/ra/9/05/2009-05-05.html
> [3] http://www.w3.org/2002/ws/ra/wiki/Main_Page
> [4] http://www.w3.org/2002/09/wbs/43088/200906F2FReg/
> [5] http://www.w3.org/2002/ws/ra/admin.html
>  [attachment "smime.p7s" deleted by Doug Davis/Raleigh/IBM]
>