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

Pallavi,

This is a great example.

Looking at the WSFL 1.0 spec, I saw that section 8.4.1 contains definitions for
three "service provider types" that use the portType definitions you forwarded:

<definitions name=“totalTravelPortTypes“
    targetNamespace=
    "http://www.TravelLuck.com/WebServices/Messages/TotalTravel"
    xmlns:tio=
    “http://www.TravelLuck.com/WebServices/Messages/TotalTravel”
    xmlns=“”>
    <serviceProviderType name=”airlineFlow”>
        <portType name=”tio:ticketHandler”/>
        <portType name=”tio:ticketDelivery”/>
    </serviceProviderType>
    <serviceProviderType name=”agentFlow”>
        <portType name=”tio:tripHandler”/>
        <portType name=”tio:ticketRequester”/>
    </serviceProviderType>
    <serviceProvider name=”travelerType”>
        <portType name=”tio:ticketBuyer”/>
    </serviceProvider>
</definitions>

(Incidentally, I think there is a typo: the <serviceProvider/> element at
the end should really be <serviceProviderType/>, at least that's what
I get from a quick glance at the WSFL schema. The xmlns="" declaration
seems wrong too, by the way.)

It seems to me that, if we rewrote the definitions for the port types below
so that they only contained request-response and one-way operations,
we could then easily rewrite the serviceProviderType definitions above
to specify a direction flag of the kind I described previously and recapture
all the information in the original document.

I'd also argue that it would make the relationship between the
"requestTicketOrder" operation of portType "ticketRequester" and the
"receiveTicketOrder" operation of portType "ticketHandler" clearer:
it is the same operation seen from two different points of view.

Of course, it's possible that there are better solutions from a WSFL
perspective, but I don't see anything here that would prevent us from
removing solicit-response and notification operations from portTypes.

Roberto

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


"Malu, Pallavi G" wrote:

> WSFL1.0 example :
>
> 8.3 Port Types Externalized by the Flow Models of the Travel Example
> This section provides the definition of all the port types that are
> referenced in the travel agent and airline flow models.Each operation in
> these port types is defined in terms of its input and output messages;each
> of the messages used is a WSDL message as defined in the
> preceding subsection.If needed,import statements could be included to
> provide the actual
> locations where the schema or WSDL definitions can be found.
>
> <definitions name="totalTravelPortTypes"
> targetNamespace=
> "http://www.TravelLuck.com/WebServices/Messages/TotalTravel"
> xmlns:tio=
> "http://www.TravelLuck.com/WebServices/Messages/TotalTravel"
> xmlns="">
> <!--========================================================= -->
> <!-- These are the standalone TravelAgent interfaces -->
> <!--========================================================= -->
> <portType name="tripHandler">
> <operation name="receiveTripOrder">
>                 <input name="receiveTripOrderInput"
>                 message="tio:tripOrderMsg"/>
>                 <output name="receiveTripOrderOutput"
>                 message="tio:tripOrderAck"/>
> </operation>
> <operation name="sendItinerary">
>                 <output name="sendItineraryOutput"
>                 message="tio:itineraryMsg" />
> </operation>
> </portType>
>
> <portType name="ticketRequester">
> <operation name="requestTicketOrder">
>                 <output name="requestTicketOrderOutput"
>                 message="tio:ticketOrderMsg" />
>                 <input name="requestTicketOrderInput"
>                 message="tio:ticketOrderAck" />
> </operation>
> <operation name="waitForConfirmation">
>                 <input name="waitForConfirmationInput"
>                 message="tio:confirmationMsg" />
> </operation>
> </portType>
> <!--============================================================ -->
> <!--This is the standalone Airline interface -->
> <!--============================================================ -->
> <portType name="ticketHandler">
>                 <operation name="receiveTicketOrder">
>                 <input name="receiveTicketOrderInput"
>                 message="tio:ticketOrderMsg"/>
>                 <output name="receiveTicketOrderOutput"
>                 message="tio:ticketOrderAck"/>
> </operation>
> <operation name="sendConfirmation">
>                 <ouput name="sendConfirmationOutput"
>                 message="tio:confirmationMsg"/>
> </operation>
> </portType>
> <portType name="ticketDelivery">
> <operation name="sendETicket">
>         <output name="sendETicketOutput"
>         message="tio:eTicketMsg"/>
> </operation>
> </portType>
> <!--============================================================ -->
> <!--This is the interface required from a ticketBuyer -->
> <!--============================================================ -->
> <portType name="ticketBuyer">
> <operation name="sendTripOrder">
>                 <output message="tio:tripOrderMsg"/>
>                 <input message="tio:tripOrderAck"/>
> </operation>
> <operation name="receiveETicket">
>                 <input message="tio:eTicketMes"/>
> </operation>
> <operation name="receiveItinerary">
>                 <input message="tio:itineraryMsg"/>
> </operation>
> </portType>
> </definitions>
> -----Original Message-----
> From: Malu, Pallavi G [mailto:pallavi.g.malu@intel.com]
> Sent: Wednesday, April 17, 2002 9:37 AM
> To: 'Roberto Chinnici'; Prasad Yendluri
> Cc: www-ws-desc@w3c.org
> Subject: RE: issue: remove solicit-response and output-only operations?
>
> The point I was trying to make is we need mechanism to achieve
> solicit-response and output-only operations. And unless we put some
> alternative to current way of achieving it in place we should not remove
> solicit-response and output-only operation types.
>
> -Pallavi
>
> -----Original Message-----
> From: Roberto Chinnici [mailto:roberto.chinnici@sun.com]
> Sent: Tuesday, April 16, 2002 10:30 AM
> To: Prasad Yendluri
> Cc: www-ws-desc@w3c.org
> Subject: 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 Friday, 19 April 2002 13:50:18 UTC