[Pub-Sub-Task] Re: Some thoughts on wsdl pub/sub

I was targeting on 2).

-Joyce

p.s. I'm moving the discussion to the public list since I don't
see any objection during the past few hours.

"Sedukhin, Igor" wrote:

> My original intent and discussions that we had with Sanjiva were about 1) I believe.
>
> -- Igor Sedukhin .. (igor.sedukhin@ca.com)
> -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
>
> -----Original Message-----
> From: Don Mullen [mailto:donmullen@tibco.com]
> Sent: Thursday, October 31, 2002 2:40 PM
> To: 'Sanjiva Weerawarana'; Joyce Yang; sandkuma@cisco.com; Sedukhin, Igor; tuecke@mcs.anl.gov; asakala@iona.com; roberto.chinnici@sun.com; Jonathan Marsh; Steve Graham; Amy Lewis
> Subject: RE: Some thoughts on wsdl pub/sub
>
> It strikes me that we are discussing two use-cases:
>
> 1) Event mechanism for point to point (strong use case in BPEL).  output and output-input not necessarily required.  Better event mechanism for WSDL would be.
>
> 2) Pub/Sub where publisher might not know/care about specific endpoints (netnews example, other messaging systems).  'Subscriber's might dynamically tap into published information without the publisher's knowledge, so from the server's[publisher's] point of view, there *is* no 'subscription'. output and output-input required (with enhancements/clarifications).
>
> I would suggest that we move these discussions onto the public mailing list (or the member list) -- and preface each mailing with [Pub-Sub-Task] or [PST] to easily catch/filter the task force discussion and archiving/referencing is easier.  Any objections?  Preference on which list?
>
> Don
>
> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@us.ibm.com]
> Sent: Thursday, October 31, 2002 10:54 AM
> To: Amelia A Lewis
> Cc: Joyce Yang; sandkuma@cisco.com; igor.sedukhin@ca.com; tuecke@mcs.anl.gov; asakala@iona.com; roberto.chinnici@sun.com; Jonathan Marsh; Steve Graham; donmullen@tibco.com
> Subject: Re: Some thoughts on wsdl pub/sub
>
> (I added Steve Graham to the cc list - he's co-rep'ing GGF with Steve Tuecke and is interested in this area. Also added Don Mullen at Amy's
> request.)
>
> I don't think approach of re-using the outbound ops is good. Yes, its possible to squint funny and make them look like event thingies, but why are we bothering? We are changing WSDL soooo much that we might as well do the right thing now w.r.t. pub/sub. (I consider addining multiple interface inheritance a fundamental change.)
>
> The approach I used does not look at pubsub as just an operation. Its a first-class approach to pub-sub ...
>
> Sanjiva.
>
> Amelia A Lewis <alewis@tibco.com> on 10/31/2002 09:16:38 PM
>
> To:    Sanjiva Weerawarana/Watson/IBM@IBMUS
> cc:    Joyce Yang <joyce.yang@oracle.com>, sandkuma@cisco.com,
>        igor.sedukhin@ca.com, tuecke@mcs.anl.gov, asakala@iona.com,
>        roberto.chinnici@sun.com, Jonathan Marsh <jmarsh@microsoft.com>
> Subject:    Re: Some thoughts on wsdl pub/sub
>
> Heyas,
>
> On Thu, 2002-10-31 at 04:35, Sanjiva Weerawarana wrote:
> > I was thinking of something a bit more direct than what you've written
> > Joyce - same basic concept, but a bit more first class syntax.
> >
> >       <portType name="pt1">
> >             <operation name="normal-op1"> ... </operation>*
> >             <event name="event-1">
> >                   <subscription message="subscription-message"/>
> >                   <notification message="notification-message"/>
> >             </event>
> >       </portType>
> >
> > So event definitions say that they are an event and indicate what
> > subscription message needs to be sent and what notification needs to
> > be sent. A port for this portType would have an address and that
> > address is where the subscription message would have to be sent. How
> > that message flows on the wire is of course (as usual) a matter of the
> > binding. So we need to define a binding .. probably something that
> > wraps the
> subscription
> > message in a wrapper element named event-1, but we can work that out
> later.
> >
> > Now the question is what's in the subscription message? Basically, it
> needs
> > to indicate a service reference to a service that has a portType with
> > the operation via which the service will deliver the notification
> > message to the subscribers. The service reference in the subscription
> > message is of course a reference to the subscriber. The notification
> > message itself is just a regular data message - contents are up to the
> > service designer.
> >
> > What's a service reference? In BPEL we published a service ref format
> which
> > can be the basis of a more thorough service reference. In fact we're
> > finalizing such a beast now and hope to make that available to the WG
> > shortly. I believe such a mechanism will be sufficient to capture this
> > scenario (details TBD ;-)).
> >
> > What do y'all think?
>
> I don't really agree with this approach.  While it is, in principle, possible to define almost any operation in terms of other operations, if you squint right, I think that Joyce's original point here is that pub/sub is more naturally modelled by the use of solicit/response
> (output-input) and notification (output-only) operations.  This is a position with which I strongly agree, and was the basis of the work that we have done on defining features and MEPs (and an example binding) for SOAP, using the extensibility mechanism.
>
> I would like to draw attention to that material, and to the work on modelling features in WSDL, because I think that a good deal of what we need to model for the publish/subscribe paradigm may be accessible through this pattern.  The sample binding provided with the proposals is for email, using what is loosely a publish/subscribe mechanism (mailing lists are not the ideal of pub/sub, but most people to understand how they work).
>
> I also strongly feel that requiring all WSDL interactions to be described as service-to-service is a limitation that we should not introduce.  Subscribers, as much as 'requestors', are easily modeled as clients.
>
> I'll provide a bit more feedback on Joyce's material later, I hope.  I think the basic concepts in the proposal are fairly sound, but I'm not quite clear on why certain distinctions really need to be made.
>
> Amy!
> > Joyce Yang <joyce.yang@oracle.com> on 10/31/2002 02:35:26 PM
> >
> > To:    sandkuma@cisco.com, igor.sedukhin@ca.com, tuecke@mcs.anl.gov,
> >        Sanjiva Weerawarana/Watson/IBM@IBMUS, asakala@iona.com,
> >        alewis@tibco.com, roberto.chinnici@sun.com
> > cc:    jmarsh@microsoft.com, joyce.yang@oracle.com
> > Subject:    Some thoughts on wsdl pub/sub
> >
> >
> >
> > Hi wsdl pub/sub task force,
> >
> > Are we all waiting on each other to start the pub/sub discussion? :-)
> > Since I haven't seen any discussion or proposal on this subject for
> > weeks, I'd like to throw some ideas on pub/sub.
> >
> > First, I'd like to clarify the scope of the pub/sub task.
> > My interpretation is as follows -- wsdl 1.1 supports
> > output and output-input operations without proper
> > binding details and usage examples. They can be
> > pub/sub if the proper plumbing piece are added, and
> > the goal of this task is to identify and propose these missing pieces.
> > All my thinking is based on this interpretation.
> >
> > Started from "output" and "output-input" operations,
> > the wsdl:output message is the message published to the subscriber(s),
> > and wsdl:input message of "output-input" operation is the ack of the
> > published message. Therefore, the role of the "output" or
> > "output-input" operation is both the publisher AND the topic/queue.
> >
> > By far, I don't see any changes required on wsdl:binding. Everything
> > applies to "input" and "input-output" operations can be mirrorred for
> > "output" and "output-input" operations. I also don't see needs to
> > propose new bindings, for example, JMS binding. If such a binding is
> > required, it should be provided by Soap over JMS, instead of a
> > direct JMS binding. Defining a new binding would be
> > out of scope of this AI.
> >
> > However, there will be changes in wsdl:port to indicate whether it's
> > an outgoing or incoming (or both?) port. (This is the proposal Roberto
> > had a while ago.) If it is an incoming port (i.e. for input and
> > input-output operations), soap:address describes the listening
> > endpoint of the wsdl:port. If it's an outgoing port (i.e.
> > output and output-input operations), soap:address
> > doesn't make sense, and instead, wsdl:port should list
> > the subscriber's endpoint (if known).
> >
> > The tricky and fun part is how to describe the "subscribe" and
> > "unsubscribe" mechamism in wsdl v.s. listing the subscriber endpoints
> > in wsdl:port. My current thinking is to describe them as
> > wsdl:operation and then mark them as "subscribe" operation or
> > "unsubscribe" operation to the correspondent pub/sub. A quick example
> > is as follows (please don't quote me on the syntax yet, I
> > just quickly put something together to demonstrate
> > the concept :-) --
> >
> > <portType name="StockQuotePT">
> >     <operation name="StockQuote" pubsub="tns:stockquotepubsub"
> >         <output message="tns:OracleStockQuote"/>
> >         <input message="tns:OracleStockQuoteAck"/>
> >     </operation>
> > </portType>
> >
> > <!-- subscribe() and unsubscribe() -->
> > <portType name="StockQuoteSubscribePT">
> >     <operation name="subscribe" pubsub="tns:stockquotepubsub"
> >         <input message="tns:StockQuoteSubscribe"/>
> >         <output message="tns:StockQuoteSubscribeAck"/>
> >     </operation>
> >
> >     <operation name="unsubscribe" pubsub="tns:stockquotepubsub"
> >         <input message="tns:StockQuoteUnsubscribe"/>
> >         <output message="tns:StockQuoteUnsubscribeAck"/>
> >     </operation>
> > </portType>
> >
> > <pubsub name="stockquotepubsub">
> >     <publish portType="tns:StockQuotePT" operation="StockQuote"/>
> >     <subscribe portType="tns:StockQuoteSubscribePT"
> operation="subscribe"/>
> >     <unsubscribe portType="tns:StockQuoteSubscribePT"
> > operaton="unsubscribe"/>
> > </pubsub>
> >
> > Every wsdl:operation indicates it's a "player" of a pub/sub throught a
> > new "pubsub" property. wsdl:pubsub is a first class wsdl construct to
> > describe the pub/sub relationships.
> >
> > How do you guys think by far? I do have more to say,
> > but I will save them in later discussion. :-)
> >
> > Regards,
> > Joyce
>
> --
> Amelia A. Lewis
> Architect, TIBCO/Extensibility, Inc.
> alewis@tibco.com

Received on Thursday, 31 October 2002 17:11:19 UTC