Virtual consumers

[David Hull <dmh@tibco.com>]

After a bit of pondering, it seems to me that the main source of difficulty surrounding pull points is that the relationship between NotificationProducer and NotificationConsumer needs to be just slightly more abstract.

Right now we assume that notifications are physically delivered to a consumer by sending them to the address given in the ConsumerReference EPR.  In the case of pull points -- and any of several other devices that could follow the same pattern -- this need not be the case.  As discussed, the CreatePullPoint operation may or may not produce an EPR valid for direct delivery of notifications.  All the NP really needs -- and again, this is not specific to pull points per se -- is enough information to know how to dispatch the notifications properly.

This dispatch may consist of sending a SOAP message, in which case the port types of the consumer and the UseRaw subscription policy are relevant, or it may consist of updating an internal data structure, as in the case of one anticipated realization of pull points, or it might consist of publishing messages via an existing MOM platform, allowing a WS-style "gateway" into that world, or it might consist of something else entirely.  Again, UseRaw and such are only relevant in the first case.  In the case where the communication between the NP and the pull point is internal, it's not meaningful to say that messages were produced in any particular form at all.

Unfortunately, the current description of ConsumerReference is somewhat at odds with what I just said.  For example, on line 515 and following, we say:

In cases where the optional wsnt:UseRaw policy component is not specified, the Web Service identified by the endpoint reference MUST implement the message exchanges defined by NotificationProducer (i.e., the Notify message).

(italics mine).  Normatively, the MUST just means that if we're doing anything purely "virtual" we have to include UseRaw, which is a wart, but not fatal.  Non-normatively, though, we say very explicitly that the ConsumerReference is a "Web Service" (whatever that may be), which tends to discourage less strict interpretations like the above.

I believe that we had decided that "Web Services" need not be described by WSDL, but it seems reasonable to think that a web service at a bare minimum should be capable of communicating over the web.

I'm currently contemplating what tweaks to the text in section 4 and elsewhere are needed to make the description a bit more flexible to allow for ConsumerReferences that don't actually denote physical web services.  I don't think that this would require any substantive changes to the NP semantics.  You still make a subscription by giving an EPR to an NP, you still get back an EPR you can use to manage the subscription, you still specify filters, etc.  In any case, there's not really any way to enforce a restriction that ConsumerReferences must be "Web Services".

Afterthought: Technically, a pull point as described is  a web service anyway, since it supports the pull point operations.  However, this is definitely stretching the intent of the text as it stands, and it would be best to back away from the current approach a bit, not just in section 5, but in section 4 and a few places elsewhere as well.