First, I believe the text you are referring to in section 3 is this,
around line 291:
This means that a NotificationConsumer MAY choose to
implement the Notify Message, or to implement raw Notification(s)
explicitly
(or both). When requesting creation of a Subscription on behalf of a
NotificationConsumer, a Subscriber SHOULD ensure that the
NotificationConsumer
is able to handle the form of Notification it has requested for the
given
Subscription.
The first sentence may be ambiguous. I read it as "The NC MAY (but
need not) do any of the following ...". This is consistent with the
following statement that the Subscriber SHOULD (not MUST) ensure that
the NC is able to handle the form of notification requested.
On the other hand, the very beginning of the section, at line 277, says:
WS-BaseNotification allows a NotificationConsumer to
receive
a Notification in one of two forms:
This implies that there are only two forms possible, and so the
sentence in question might mean "The NC MAY choose to receive
notifications in either form, or both." In other words, does the MAY
apply to whether the NC supports the two formats, or to how
it makes its choice of Raw, Notify or both.
In any case, in the "cookie" scenario, neither raw not notify is
relevant, since delivery happens inside a black box. I'll re-emphasis
that this is orthogonal to the question of pull points per se. A pull
point might be able to act like an ordinary NC to an NP other than the
one that created it, and conversely other kinds of NCs can be treated
as cookies.
I think this is consistent with the SHOULD on line 293 ("a Subscriber
SHOULD ensure that the NC is able to handle ..."), but it runs a little
counter to the implication in line 277 ("WS-BaseNotification allows a
NotificationConsumer to receive
a Notification in one of two forms:").
I would suggest at least rewording this line as:
WS-BaseNotification supports two formats for
Notification messages:
We might go further and say, after line 281,
something like:
The NotificationProducer MAY also arrange for
delivery by some means other than sending a SOAP message, in which case
the question of which format is in use is not relevant.
I don't think this necessarily changes the normative behavior, since
such behavior is already possible. All the NP is required to do is produce
notifications. Delivery is a matter of policy.
I think.
Peter Niblett wrote:
David
I think we'd still want the thing you pointed to by the ConsumerReference
EPR to be a Web service - as you say in your afterthought, in the PullPoint
case it has to implement the pp operations. The question is whether it has
to be a NotificationConsumer Web service or not.
At the beginning of Section 3, we define what it means to be a
NotificationConsumer, you must EITHER support the Notify message, OR the
message type defined by the Topic (if topics are being used), OR both. The
converse to the line 515 (implied by the text at the beginning of 3) is
that if you do specify useRaw, then the thing pointed to the
ConsumerReference EPR has to accept the raw form of the notification. So I
think that the question you raise applies also in the case where useRaw is
there [also I think at the last F2F we agreed that the presence/absence of
useRaw should make no observable difference to what happened when you were
using a pull point instead of a conventional NC]
We could try to twist the interpretation of "implement" and "accept", to
say that the PP could have a "policy" of not accepting requests coming from
anyone other than the NP to which it is subscribed, and in the virtual
cases you mention that NP never actually tries to send it a Web service
message. But I think that is stretching it.
It seems to me that if we want to support the virtual cases, then we need
to adjust the definition of ConsumerReference at 505 et seq to say that it
is an EPR that identifies a NotificaitonConsumer or a Pull Point (or
something that implements both).
Peter Niblett
David Hull
<dmh@tibco.com>
To
18/08/2005 22:27 wsn@lists.oasis-open.org
cc
Subject
[wsn] Virtual consumers
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.
|