Re: [Pub-Sub-Task] initial half-baked proposal from me

Ok. Here is what I sent out eariler --
======================================
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

Sanjiva Weerawarana wrote:

> Since this discussion is moving to the public list let me re-post
> the very rough proposal strawman I threw out. Joyce, please send
> your thoughts as well.
>
> Sanjiva.
>
> ========================
>
> 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 ;-)).

Received on Thursday, 31 October 2002 19:35:28 UTC