Re: issue: remove solicit-response and output-only operations?

It seems to me that if we remove solicit-response and notification operations
from interfaces (portTypes), we'll remove a major source of confusion in WSDL.

Both mechanisms described in Prasad's email can be recovered by putting what
used to be solicit-response and notification operations in their own port type
and reversing them, making them request-response and one-way operations.
A future event-notification description language or an upper-layer business
process language could then use this new port type for its own purposes.

If we need to capture the fact that a WSDL 1.next service defines some
outbound operations, which I'm guessing is what Pallavi is hinting at in
her message, we can allow adding "outbound ports" to a service (and
later to a service type). It could be as simple as adding a new attribute
direction="inbound|outbound" (with inbound as default value) to <port/>.
The full specification of an event/callback registration mechanism can
then be done later. Notice also that it's much easier for a tool to match
up a client and a server if they both declare ports of the same type
but with opposite directions, as opposed to identifying conjugate
operations in different portTypes.

Roberto

--
Roberto Chinnici
Java and XML Software
Sun Microsystems, Inc.


Prasad Yendluri wrote:

> We discussed this briefly during F2F last week also but to expand a little more
> on this, I see a need for both types of mechanisms. That is,
>
> 1) A solid event-notification mechanism (that is service initiated) that
> Sanjiva proposes as the replacement. This would however call for the
> specification of the complete details including the event subscription
> mechanism etc. as we had discussed in the f2f. This is to facilitate a server
> to generate events (subsequent to a request).
>
> 2) A way to describe things from a request initiator perspective. Revised and
> completed versions of Solict-Response and Notification that "fix" the abstract
> definitions and provide full details of the concrete definitions.
>
> I personally would be willing to go with the removal of these patterns if there
> is a clear way to capture both sides of an exchange (e.g. in a business
> process) say by an upper layer mechanism (analogous to WSFL or XLANG). However
> both seem to (XLANG I know for sure) rely on Solicit-Response / Notification
> type patterns to accomplish this. It is not clear to me how else this could be
> accomplished...
>
> Regards, Prasad
>
> -------- Original Message --------
> Subject: RE: issue: remove solicit-response and output-only operations?
> Resent-Date: Mon, 15 Apr 2002 20:19:41 -0400 (EDT)
> Resent-From: www-ws-desc@w3.org
> Date: Mon, 15 Apr 2002 17:18:28 -0700
> From: "Malu, Pallavi G" <pallavi.g.malu@intel.com>
> To: "'Sanjiva Weerawarana'" <sanjiva@watson.ibm.com>, www-ws-desc@w3c.org
> CC: "'pyendluri@webmethods.com'" <pyendluri@webMethods.com>
>
> Sanjiva,
>
> For representing Rosettanet PIPs we need solicit-response operations.
> e.g. PIP3A4 - is a PurchaseOrderRequest ans PurchaseOrderConfirmation
> scenario between the buyer and the seller.
>
> buyer:
>             <operation name="submitPO">
>    <output message="PORequest"/>
>    <input message="POResponse"/>
>   </operation>
>
> and corresponding seller:
>   <operation name="processPO">
>    <input message="PORequest"/>
>    <output message="POResponse"/>
>   </operation>
>
> So unless we have some first-class description of an event mechanism in
> place, I suggest we leave the "solicit-response" and "output-only" as is in
> WSDL1.2.
>
> -Pallavi
>
> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
> Sent: Friday, April 12, 2002 9:14 PM
> To: www-ws-desc@w3c.org
> Subject: issue: remove solicit-response and output-only operations?
>
> The WG would like to solicit your comments on whether we should
> eliminate WSDL 1.1's "solicit-response" and "output-only"
> operations as we produce WSDL 1.2.
>
> Here are the two issues from the latest part1 document. Note that
> I have posted these together as the decisions obviously need to
> be coupled.
>
>   <issue id="issue-remove-solicit-response-operations" status="open">
>     <head>Should we remove solicit-response operations?</head>
>     Solicit-response operations are not fully defined in WSDL
>     1.1. There are multiple interpretations of these in the community:
>     event, callback etc.. Also, there is little evidence that anyone
>     is actually using them.  We could consider replacing this with
>     a first-class description of an event mechanism.
>     <source>Sanjiva Weerawarana</source>
>   </issue>
>
>   <issue id="issue-remove-notification-operations" status="open">
>     <head>Should we remove notification operations?</head>
>     Notification operations are also not fully defined in WSDL
>     1.1. There are multiple interpretations of these in the community:
>     event, callback etc.. Also, there is little evidence that anyone
>     is actually using them. We could consider replacing this with
>     a first-class description of an event mechanism.
>     <source>Sanjiva Weerawarana</source>
>   </issue>
>
> Thanks,
>
> Sanjiva.

Received on Tuesday, 16 April 2002 13:33:46 UTC