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

Right, I always took solicit-response as the mirror of request-response.
When you want to match two services A and B, A would have 
solicit-response and B request-response. If all else is
equivalent, then you are off to the races with A sending the
message to B and B responding.

If you are going to play connect-the-dots with some higher-level
choreography mark-up like WSFL, WSCL, ETC, you need some means
of making these connections.

Cheers,

Chris

Prasad Yendluri wrote:

> This goes to prove that there is confusion around this. This is totally
> different from subscribing messages/reponses/events that a server sends. What is
> perhaps missing is how do we capture the specification that "I initiate and send
> you this request and I expect you to send me this response message" as opposed
> to "If you send me this request you will get this response" as captured by the
> request/response type
> 
> Regards, Prasad.
> 
> -------- Original Message --------
> Subject: RE: issue: remove solicit-response and output-only operations?
> Date: Tue, 16 Apr 2002 14:32:37 -0700
> From: "Sandeep Kumar" <sandkuma@cisco.com>
> To: "Prasad Yendluri" <pyendluri@webMethods.com>,"Roberto Chinnici"
> <roberto.chinnici@sun.com>
> CC: <www-ws-desc@w3c.org>
> 
> Hi,
> 
> Solicit-Response is nothing but a degenerate case of per message/request
> subscription.
> So if you have first-class subscription support, solicit-response is easy to
> support.
> Am I missing something?
> Sandeep
> 
> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of Prasad Yendluri
> Sent: Tuesday, April 16, 2002 2:29 PM
> To: Roberto Chinnici
> Cc: www-ws-desc@w3c.org
> Subject: Re: issue: remove solicit-response and output-only operations?
> 
> 
> Hi Roberto,
> 
> Roberto Chinnici wrote:
> 
> 
>>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.
>>
> 
> <PY>
> I am not sure if I understand what is being proposed above. How would this
> portType
> be different from a request-response/oneway port type?
> 
> What I am looking for is exactly what Pallavi is looking for also. That is,
> how do we
> capture outbound requests (from the request initiator perspective) in
> addition to the
> current service provider (request-receiver / responder) perspective, so that
> we can
> capture both client and server views of the exchanges (as in a business
> process).
> 
> </PY>
> 
>>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.
>>
> 
> <PY> This I think would  be an alternate way of capturing what we are
> looking for.
> So, we will have two ports with the same (type and) binding but, for the
> port
> representing request-initiating (client) end-point have the direction
> attribute set
> to "outbound" (and "inbound" for the server side). Seems reasonable to me.
> However I
> see some difficulty in representing an exchange that goes back and forth
> where the
> client and server switch roles back and forth in realizing a business
> process. That
> is one side is sometimes a client to the other and vice-versa.
> 
> </PY>
> 
> Regards, Prasad
> 
> 
>>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 18:21:16 UTC