RE: Issue 6429: proposal 2, related to 6401

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