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

Hi Prasad,

Yes, it needs to be at the abstract level and not at the binding
level. If we had a service type notion (for which we have a
requirement) one could do it with something like the following:

    <serviceType name="st1">
       <provides portTypes="qname1 qname2 ... qnamen"/>
       <requires portTypes="qname1 ... qnamek"/>
    </serviceType>

where the "provides" portTypes are the inbound portTypes (i.e.,
those that the service offers to its customers) and the "requires"
onces are the ones that the service will require from someone
(potentially its user).

A <service> would of course then have to indicate that it
implements a serviceType. Bindings of provides portTypes would
have the semantics they have now (the service user has to abide
by them) and the bindings of requires portTypes would have the
semantics that the service is indicating a set of constraints
on who can provide that service.

Bye,

Sanjiva.

----- Original Message -----
From: "Prasad Yendluri" <pyendluri@webmethods.com>
To: <www-ws-desc@w3c.org>
Sent: Friday, April 19, 2002 8:37 PM
Subject: Re: issue: remove solicit-response and output-only operations?


> Roberto,
>
> We discussed this in the call yesterday but just to make sure we have this
stated (as it did
> not get catptured by the minutes), the 'direction="inbound|outbound"
attribute addition on a
> port' solution that you suggested pushes this to the binding level. We
really need something
> that captures the description of outbound requests (from the request
initiator perspective)
> at the abstract level as well. In other words the proposed solution is
inadequate.
>
> Regards, Prasad
>
> ------- Original Message --------
> Subject: Re: issue: remove solicit-response and output-only operations?
> Date: Tue, 16 Apr 2002 18:29:01 -0700
> From: Roberto Chinnici <roberto.chinnici@sun.com>
> To: Prasad Yendluri <pyendluri@webMethods.com>
> CC: www-ws-desc@w3c.org
> References:
<F55DFDA7A48DD411AC6A00A0C95D746E039BB22D@fmsmsx63.fm.intel.com>
> <3CBB7CE7.6343E73B@webmethods.com> <3CBC5F90.DA59A681@sun.com>
> <3CBC97B1.6D97EA86@webmethods.com>
>
> Prasad Yendluri wrote:
>
> > 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?
>
> <RRC>
> It would not be different at all, that's exactly my point (see the rest of
my proposal).
> </RRC>
>
> > 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.
>
> <RRC>
> This should be easy to do. If two peers need to play both the client and
the server
> role of the exchange, they would each declare two ports of the same type,
one
> inbound and one outbound. The exact description of the conditions under
which
> one would act as client and the other as server (and viceversa) would be
left to
> the business process description language.
>
> Admittedly, there are some issues with the exact meaning of a binding for
an
> outbound port, but they don't seem to be any worse than those already in
> WSDL 1.1 wrt solicit-response and notification operations, and this hasn't
> prevented other languages from building on WSDL 1.1.
> </RRC>
>
> Roberto
>
> --
> Roberto Chinnici
> Java and XML Software
> Sun Microsystems, Inc.
>
>
> > </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 Wednesday, 24 April 2002 07:34:40 UTC