Re: The Day Trader application: an example using output-input operations for classic ("true") pub/sub operations.

Good morning, all,

On Wed, 13 Nov 2002 10:22:44 -0800 (GMT-08:00)
"JOYCE.YANG" <JOYCE.YANG@oracle.com> wrote:
> - I also in the same opinion that for certain cases, subscription can be modelled
> by <operation>. There are two flavors of pub/sub (or more?), one use explicit

At least two.

> subscription and publication, and the publisher and subscriber talks to each other.

Well, the subscriber may talk to the (single) publisher, may talk to a (single) administrative address, or may (I don't think this is common) talk to (multiple) publishers.

> The other flovor is that the protocol does the pub/sub, and hence the subscription
> is implicit. For the first case, subscription (and unsubscription) can be modelled
> as <operation> (or <operation>s if more than one subscription methods are
> provided) in one or many <portType>(s).

I agree.  I think it is very important to note that *both* subscription and unsubscription need to be modelled, if one is to be modelled.

I might suggest, though, that the subscription operation and unsubscription operation might be modelled as contained in a separate portType from the operations defined as part of the publication.  For instance, if one wished to model the Java 2 event model, and if one accepts that portType is approximately equivalent to an interface, then it's clear that there are event listeners, but the event sources do not mark themselves as such.  That is, there is no standard means of defining something to be (for instance) a MouseEventSource, although there is a way to define a MouseEventListener, and MouseEvents.  There is a *convention* that provides standard names (addMouseListener, removeMouseListener) which are parameterized by interface (MouseListener, in this case), so that one can figure out what's going on.

This is, I think, more along the model that Sanjiva had suggested (except for the lack of a removeListener, which raises the question as to whether only one event is fired per "subscription", and the fact that the model used an outbound notification, rather than leaving the definition as an incoming one-way on the interface supplied).

> IMHO, WSDL as a interface language should
> has a construct to describe this association between the publish operation(s) and
> subscription operation(s) either first class way or from a
> best practice kind of extension. 

Okay.  This is the big question, in my opinion.

Imagine, if you will, a service published via SOAP over HTTP.  The service includes two portTypes, one marked administrative, the other marked standard (you can also merge these two; I'm separating them only for what clarity it might offer--they can easily be merged in the binding).  This is "The Old Boy Insiders Network."  In the administrative interface, the operations exposed are "register" (request/response) and "unregister" (request/response).  In the standard interface, the operations exposed are "getInsideDope" (request/response, could be modelled with webmethod) and "shareInsideDopeWithOtherSleaze" (request/response, a put operation).

WSDL currently does not provide a way to indicate that a client *must* register (using the registration interface) as an old-boy sleaze before accessing inside dope.

Is this not an analogous situation to publish/subscribe?  Is it really in scope for WSDL to specify connections and relationships between operations, apart from their inclusion in the same portType, or the bundling of multiple portTypes in an operation?  It seems to me that what we are doing, in trying to establish an order of operations (first subscribe, then receive zero or more whatevers, then unsubscribe), is moving (in a very small way, admittedly, only on the margins) into the arena of a choreography/process/flow language.  I think that we should design the spec in such a fashion that a flow language can very easily model all common network idioms (client/server, pub/sub, event notification, peer-to-peer, RPC, and so on and so forth), but I don't think that it's necessarily right for us to introduce support for any of those idioms if it effectively requires specifying the order of access to operations.

To try to be absolutely clear:

1) not all pub/sub services would require explicit (application level, describable in XML) subscription or administration

2) not all event notification services would require explicit (application level, describable in XML) subscription or administration

 -> Therefore, it should not be required, since to do so prevents the use of protocols with built-in subscription/administration semantics.

 -> Should it not at least be allowed?

1) yes, certainly.

2) is it in scope for WSDL to describe relationships between operations?

3) if it is in scope, what are the boundaries of the scope?  That is, if we allow linking administration operations (subscribe and unsubscribe at minimum) to publication interfaces, what else must we then support?  Registration/unregistration?  Login/logout?  The characteristic that I note here is that one operation is called once, then other operations take place in any order, then (possibly, and how do you handle someone who *doesn't* unsubscribe/unregister/logout who is no longer available?) another operation is called once.  It *looks* like process to me, when the stuff reaches the application level.

As another note, I think that we might be able to resolve some of the issues surrounding output operations by simply not blessing *any* MEP.  Instead, we could add operation/@mepURI="anyURI", and let *that* define semantics (this would also allow potentially different semantics for different MEP-identified input/output patterns, for instance).

> - <port>/<address> is overloaded. Semantically, <address> of a outgoing port
> is different from <address> of an incoming port (no matter it's a multicast or
> pulling or callback), and I think a proper indication is required. Besides,what if
> the port has both outbounds and inbounds operation.

Okay.  This one is a bit tricky.  For one thing, I'd prefer to see a wsdl:address (to replace soap:address and http:address), or possibly just wsdl:port/@uri.  This still allows extensions to add anything that they need (as extension elements in wsdl:port), but it makes it clear that each service/port has a single "main" address, expressed as a URI.  I can't imagine a case in which this is not true, so if someone else can, perhaps they'll correct me.

Given that there is only one primary address, then it ought to be the advertised address.  Now, it's *hard* to describe whether this is an "inbound" address or an "outbound" address or both.  In the example day trader application, for instance, it's the all-in-all address; publishers publish to the address (and everyone's a publisher, and thus a service), subscribers subscribe to the address (and everyone is a subscriber).  Whether it is inbound or outbound depends upon which role the participant happens to be playing at the moment.

The situation is much more clear for HTTP, because an HTTP server doesn't initiate connections, and the important address is the address that the server listens to.  A personal email mailbox address (personal for an application) has more-or-less the same semantics (inbound only), except that it is also typically a response address, which adds a slightly interesting flavor.  A mailing list mailbox may be outbound-only (a moderated, announcements-style list) or both inbound and outbound (lists that permit subscribers to publish).

Hmm.  Maybe it could be done, if the indicator is something like addrType, with an enumeration of "inbound", "outbound", "both", and the understanding that this reflects what is possible with that address, not what is required (that is, with the understanding that a subscriber is not *forced* to publish, or in some cases, that a publisher is not *forced* to subscribe).

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Thursday, 14 November 2002 10:47:18 UTC