Re: Proposal for dealing with solicit/response and notification

I agree with many points Dale had already made. Please find a few comments
on this from my end below in <PY>

Regards, Prasad

- Proposal:
 1) remove solicit/response and notification operation patterns

<PY>I have not seen a justification for this. Is this because we don't see
the need for it or we think we have alternate ways of accomplishing it? The
core proposal seems to be in line with latter. Is that correct?
</PY>

-> a portType operation will have the following structure (if
there is no <output> element, no <fault> element is allowed,
either):
 <operation>
   <input>
   <output>?
   <fault>*
 </operation>
 2) extend <service> to the following structure (and extend
<serviceType> appropriately):
 <service>
   <port>+
   <requirement>*
 </service>
 3) the structure of the <requirement> element is the following:
 <requirement portType="QName"/>
 i.e. empty element with a mandatory attribute referencing a
portType.

 The semantics of this:
 If a client wants to access a service, it must provide (by any
means) an implementation of the required portTypes.
<PY> The difficulty with this approach is that the Service (provider) loses
control over how exactly it wants to send the message. It has no way to
communicate what bindings (and other concrete details) for that the
portType that the service can support (and hence need to be supported by
the clients). If different clients that access the service support
different bindings for the "requirement" portType is the service required
to support all those? Seems impractical to me.

This also requires the portType to be globally unique? Or is the proposal
to define the portTypes in "requirement" also along with the service
definition? I guess it needs to as it needs to communicate the portType
details fully. Additionally all the clients need to defines the same as
well.

This seems complicating things when the real gap here is to define bindings
for solicit-response and notification message patterns? If there are issues
in accomplishing that perhaps we could discuss them.
</PY>

 This may be used to have a callback (the implementation of the
requirements is the client) or a Gudge->Football service->Mobile
phone (GFM, see footnote) scenario (the implementation of the
requirements is the mobile phone).

 The rationale:
 The only things why we want the outbound operations are
callbacks and some more complex scenarios like the mentioned GFM
scenario above.
<PY> Many practical business uses require both initiating and responding
activities. Any simple B2B scenario would require two parties collaborating
one initiating and the other responding (and very frequently exchanging the
roles).
</PY>

 Some may argue that these more complex scenarios (and in fact
callbacks, too) are orchestration and therefore out of scope of
WSDL;
<PY> WSDL is the foundation upon which higher level specs would be built.
Orchestration may be out of scope for WSDL but not enabling it.
</PY>


Dale Moberg wrote:

> 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>