Steve Graham wrote:
<sgg>Per
WS-I Basic Profile 1.1:
.5.2 Allowed Operations
Solicit-Response and Notification operations are
not well
defined by WSDL 1.1; furthermore, WSDL 1.1 does not define bindings for
them.
R2303 A DESCRIPTION MUST NOT use
Solicit-Response and
Notification type operations in a wsdl:portType
definition.
Therefore, I am very nervous
about violating
WS-I BP 1.1, without really compelling reasons.
As far as I can tell, WS-I is just making the sensible recommendation
not to use facilities for which standard definitions do not yet exist.
I don't see it as warning against defining those standards. WSDL 1.1
specifically says "It is expected that specifications that define the
protocols for Solicit-response or Notification would also include WSDL
binding extensions that allow use of these primitives." So far, no one
has done this, thus the prohibition in WS-I.
With respect to WSDL 2.0, we
should consider
this when we consider WSDL 2.0 related items.
</sgg>
<sgg>
Advertising which "message stream"
(your term, not mine) in static WSDL is problematic for several reasons:
a) the set of possible streams may
change
over the course of the lifetime of the Web service or WS-Resource
and
b) WSDL 1.1 is extremely awkward way
to describe this. You would need to define the xsd type of the message,
the wsdl:message and wsdl:part
elements, then the wsdl:operation and the wsdl:output element. This
is too much.
I don't see how either of these argues against advertising Notification
specifically. If advertising in WSDL is too expensive, we need to
revisit WSDL (but you didn't hear that here :-).
c) WS-I BP 1.1 forbids
notification
and solicit-response MEPs in wsdl 1.1 portTypes.
See above.
</sgg>
>
> In this view, WSN would be one option for the "how to connect"
information in the
> WSDL binding. Further, many of the issues we're currently
discussing
-- security,
> scheduled termination, QoS, spam mitigation, pause/resume/queuing,
push vs. pull,
> etc. -- appear more and more to be independent of whether a
message
stream is
> initiated via a WSN Subscribe operation or some other means.
Different
bindings
> will vary in how to handle all this. Some issues won't even
apply to a particular
> binding. It's at least logically possible that a message stream
initiated via WSN
> Subscribe would not need a SubscriptionManager to control it, or
that
the control
> operations of SubscriptionManager could be used for message
streams
initiated by other means.
>
> If we somehow manage to push all these issues out to WSDL binding
(where they would
> still have to be dealt with), what's left in the core? As I've
argued before,
> there is still the very central issue of the decoupled binding of
producers and
> consumers, and possibly the issue of 1-of-N delivery.
>
> In this view, NotificationProducer and SubscriptionManager still
exist
(though
> perhaps not under those names). The question is how (or whether)
to relate these
> concepts to WSDL's existing but underused concepts of MEPs and
bindings.
>
> WSN itself can potentially use out-only port types. We don't
currently have a
> means of notifying a Subscriber when a Subscription dies
prematurely
(or expires).
<sgg>
WS-ResourceLifetime suggests a
standard
subscription topic for expiration (or death) of Ws-Resources, why can't
this be used for Subscriptions?
I agree. That should be one way of picking up that notification, just
as subscribing to a topic should be one way of picking up any
notification.
The driving argument here is that notification is a more primitive
concept than WSN.
</sgg>
> One way to do this would be to include "party to notify in case
of my death"
> endpoint in the Subscribe request. Another way would be for
SubscriptionManager to
> include an out-only SubscriptionDeath operation for the Subscriber
to bind to by
> any means appropriate. This could have an "implicit"
option meaning "use the
> address I gave in the Subscribe request."
>
> The two basic mechanisms here -- supplying an EPR and advertising
an output
> operation -- may look very different, but my growing intuition is
that they are
> essentially different facets of the concept of notification. If
this is true, it
> will be useful to consider carefully how the respective
WS-specifications
-- WSN
> and WSDL -- interrelate.
|