Steve Graham wrote:
David Hull <dmh@tibco.com> wrote on
08/26/2004
02:38:01 PM:
> (This is a shorter and more concrete intro to the general WSDL
issue
from my
> previous message).
>
> If I produce notifications, how do I tell potential consumers what
they look like?
<sgg>
Implement the wsnt:Topics resource
property.
Requestor can do a GetResourceProperty on this rp, examine the contents
determine which topics are
supported,
inspect the topic metadata (ws-topics) for more information.
</sgg>
This seems like every bit as good a candidate for the "heavyweight"
label as adding an entry in a WSDL.
Personally, I'm not against either approach. I'd like to be able to
advertise a Notification in a WSDL, or advertise topic-based filtering
in WSN metadata, or both. Different approaches will be appropriate in
different situations.
>
> One approach (taken from the WSRF interop scenario document :-) is
to say something like "
> [...] the notification message generated will
contain:
> <widget:TestNotification/>"
> in a text document.
> This seems somewhat informal. The obvious
machine-readable format is WSDL. If I
> produce, say, stock quote notifications, I should advertise a
Notification
> operation with an appropriate message type. Note that this WSDL
is associated with
> the producer and not with the consumer.
<sgg> and per my response to your last
email,
I am against requiring the use of
Notification MEP because it violates WS-I BP 1.1
</sgg>
> Also note that the WSDL need not be
associated
with a service that handles
> Subscribe operations. There are two reasons for this
> 1. There is no reason to require that WSN be
the only way to subscribe to
> notifications advertised in a WSDL -- the binding might just as
well
give
> information for some native MOM.
<sgg>I thought that non-web
services
interactions are outside the scope of this TC.
</sgg>
They are. Am I bringing them into scope in some way?
> 2. Even if WSN is the mechanism, the WSN
"NotificationProducer"
might not be the
> same service as the, erm, producer of notifications.
<sgg>How does the requestor
know,
and why does the requestor care that these components are different.
The
requestor goes to an NP, says to it,
hey you, I am interested in getting messages from you at this given
topic.
The fact that the NP delegates to
another
component is encapsulated away from the requestor.
</sgg>
I'm going by port types. In the scenario I'm describing
- Someone advertises a notification in a WSDL. Yes, I know this is
currently prohibited by WS-I.
- In the binding for that Notification is enough information to
know what "Notification Producer" to send a Subscribe message to.
- However, that "Notification Producer" may be some other service
entirely. Why not?
In this scenario, it seems sensible to call the service that is
advertising the Notification a "notification producer", and call the
service that accepts the subscribe request something else.
Here's a real-world analog: Magazines advertise themselves as
available by subscription, but many contract out the actual
subscription processing. If I buy a magazine at the newsstand and fill
out the little card stuck in the middle, I may not send it off to the
magazine, but to the contractor.
> This seems like further evidence that
"NotificationProducer"
is actually more like
> "SubscriptionFactory," and it even gives a place to put
the GetCurrentMessage
> operation: A (proposed) NotificationProducer advertises a
Notification
operation
> with a given message type, and may also advertise a
GetCurrentMessage
> Request/Response operation with the same message type as its
response.
The binding
> information for the Notification operation might include and
endpoint
for a
> (proposed) SubscriptionFactory implementing WSN, or it might
specify
some other mechanism.
<sgg>It should come as no
suprise
that I disagree.
</sgg>
|