- From: Li, Li (Li) <lli5@avaya.com>
- Date: Tue, 19 May 2009 10:15:21 -0400
- To: "Gilbert Pilz" <gilbert.pilz@oracle.com>
- Cc: "Doug Davis" <dug@us.ibm.com>, <public-ws-resource-access@w3.org>, "Chou, Wu (Wu)" <wuchou@avaya.com>
- Message-ID: <7DC6C0F0E8D7C74FB4E1E73CC371280AFDFA4B@300813ANEX2.global.avaya.com>
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; 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 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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <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 <http://www.w3.org/2002/ws/ra/9/05/2009-05-05.html> [3] http://www.w3.org/2002/ws/ra/wiki/Main_Page <http://www.w3.org/2002/ws/ra/wiki/Main_Page> [4] http://www.w3.org/2002/09/wbs/43088/200906F2FReg/ <http://www.w3.org/2002/09/wbs/43088/200906F2FReg/> [5] http://www.w3.org/2002/ws/ra/admin.html <http://www.w3.org/2002/ws/ra/admin.html> [attachment "smime.p7s" deleted by Doug Davis/Raleigh/IBM]
Received on Tuesday, 19 May 2009 14:16:13 UTC