Issues 6340 and 6425

Wu,
  In issues 6340 and 6425 you talk about "dynamic event sources" and the 
notion of filtering notifications based on sessions created by clients. In 
these cases you talk about using a ref-parameter of the Event Source to 
indicate which session this Subscribe is for. I decided to go and read the 
WS-Session specification that you referenced and a couple of things come 
to mind:

- The idea of having a user of an EPR (the subscriber in this case) tweak 
the EPR of a service (the event source) violates WS-Addressing by no 
longer treating the ref-params of EPRs like opaque entities. So, this part 
of WS-Session is a very large concern for me.  This, in essence, pretends 
that there are multiple EPRs out there - one EPR for each Session created. 
 However,.... (see next bullet)

- based on the document, it appears that the endpoint to which the 
StartSession() is sent is the same endpoint to which the Subscribe() is 
sent - modulo the tweaking of the EPRs.  This means that you really only 
have one endpoint/service - not multiple.  In particular, if you were to 
generate WSDL for the service you would only have one WSDL and one EPR in 
there.

- If I could take ownership of the spec for a moment (pretend to be king 
;-), there are two possible ways I would address this:
1 - make StartSession create an implicit subscription under the covers.  I 
think WS-Session says that the client must create a subscription anyway 
(to the same service provider), so why not just have them pass in the 
Subscriber's notification EPR on the StartSession and avoid the overhead 
of another message exchange.  The EndSession can terminate the 
subscription too.  This has the other benefit that it avoid the WS-E vs 
WS-N discussion and lets each impl make their own choice.  Both WS-E and 
WS-N can be configured to send the same Notifications (soap messages) so I 
believe that the client would be unaware of the choice being made.  If I'm 
wrong and the client doesn't have to create a subscription, then just make 
the notification EPR optional and use that as a signal to decide whether 
to create the implicit subscription.

2 - If the StartSession and Subscribe really do need to be separate 
operations, then I would move the SessionID stuff to be a filter.  For 
example:
<s:Envelope>
 <s:Header>
 </s:Header>
 <s:Body>
  <wse:Subscribe>
   <wse:Delivery> ... </wse:Delivery>
   <wse:Filter Dialect="urn:aps:WSSessionID">
    <aps:sessionID> 1234 </aps:sessionID>
   </wse:Filter>
  </wse:Subscribe>
 </s:Body>
</s:Envelope>

When I compare this what WS-Session currently recommends:
<s:Envelope>
 <s:Header>
  <aps:sessionID xmlns:aps="..."> 1234 </aps:sessionID>
 </s:Header>
 <s:Body>
  <wse:Subscribe>
   <wse:Delivery> ... </wse:Delivery>
  </wse:Subscribe>
 </s:Body>
</s:Envelope>

The difference really isn't that big.  In both cases the client would need 
to know about something 'special'.  In my version they need to know about 
a dialect, in yours they need to know about a special reference parameter. 
 I think you can get the same end result but do so w/o violating 
WS-Addressing and by using the natural extension points in WS-Eventing and 
WS-Notification.  From the server perspective, yes you need to know about 
a new filter but that's really no different than what you have today.  In 
either case you need have to special code to look for the sessionID - 
instead of looking for it as a SOAP header, just look for it as a child of 
the wse:Filter element.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com