RE: Proposal for dealing with solicit/response and notification

Another comment on the proposal 
to remove outbound operation patterns.

[proposal omitted]

<JK> The rationale: 
 The only things why we want the outbound operations are 
callbacks and some more complex scenarios like the mentioned GFM 
scenario above. </JK>

<DaleMoberg>
I have been looking at architecture wg use cases to avoid
duplication http://www.w3.org/2002/ws/arch/2/ws-arch-scenarios-20020619

S001,S002 This fire-and-forget describes a "web service" that pushes
out event info (example of stock price change). If I wanted to
browse such a service and see which interface I wanted to
subscribe to, it would be natural to describe this interface
by an output operation to be published in a registry for access.
[How subscription is accomplished for these cases is an important,
but separable, issue. I think this is part of what the "binding"
information items should include for an outbound operation.]

S070 Asynchronous Messaging. The "request" interface advertisement
could benefit by being described using an output operation style
of description. That is, I might seek their service and select one
based on their output operation datatypes that included
the info my 'service' needed for its input...

In general, whenever someone is going to seek a "service" that
is sent to them, they will be interested in discovering an interface
description that could usefully be published using
the output operation polarity. To me, this is really
the crux of the issue about getting rid of the output description
styles. We know that,logically viewed, we could "get by" using
one polarity style. The question is whether, pragmatically
viewed, people can benefit from publishing descriptions of
what they output, and whether potential receivers of these XML payloads
would benefit from being able to get at the output operation
descriptions to select the one(s) they can most effortlessly
consume. 

Also, some in the architecture group 
seem concerned with HTTP GET based
operations. (And presumably not using 
any url-encoded SOAP envelope appended onto
the end of the GET URI!)

If I advertised such a service, and in
signature-speak, it looked something like: 

output-data-type FUNCTION (void)

To me, it would be simpler to advertise
this by using an output-style description. Notice that in
this case there would be a port URL for the service, however!
So quite a different category of use case. Here GET
works as a "polling" mechanism that "solicits" the
payload in a HTTP Reply.

</DaleMoberg>

<JK>
We want some 80/20 division, so we allow description of these
patterns but not more.
</JK>

<Dale>I think this way of viewing things has too much bias
for the status quo, and for a status quo of a very
recently emerged technology profile. 
So far WSDL has not really
given good support for output interface 
description based integrations.
Consequently, no one has tried them, 
and so no one knows how widely they
would be used. I don't think we yet
know how the statistics for use cases are going to
fall out-- the sample is not a fair one yet.
</Dale>

<JK>
Having <serviceType>, there is no inherent need 
to combine the inbound operation patterns with outbound operation 
patterns in one portType (especially since the outbound patterns 
are not even supported in the current bindings). 
<JK>

<Dale>
I am not following how introducing <serviceType> eliminates
the semantic task done in portType by combining inputs, outputs,
and faults. Is there another message
somewhere that explains what I missed?  

However, my other problem understanding this
is why the lack of support in the current bindings
for outbound patterns counts _against_ including outbound patterns,
rather than counting _for_ fixing the bindings.
</Dale>

Received on Friday, 21 June 2002 13:51:37 UTC