W3C home > Mailing lists > Public > www-ws-desc@w3.org > May 2002

[amtf] incoming and outgoing operations? (was: Re: First shot at AbstractModel)

From: Jacek Kopecky <jacek@systinet.com>
Date: Wed, 22 May 2002 16:08:34 +0200 (CEST)
To: Prasad Yendluri <pyendluri@webMethods.com>
cc: fablet@crf.canon.fr, <keithba@microsoft.com>, <ksankar@cisco.com>, <moreau@crf.canon.fr>, <sandkuma@cisco.com>, <sanjiva@watson.ibm.com>, <Waqar.sadiq@eds.com>, Web Services Description mailing list <www-ws-desc@w3.org>
Message-ID: <Pine.LNX.4.44.0205221538160.31247-100000@mail.idoox.com>
 with request/response and oneway operations we are saying what a
service implements and provides. With solicit/response and
notification operations we are saying what a service needs. This
can be done by having only request/response and oneway operations
and have wsdl:Service reference the bindings it requires, like

   <service name="A">
     <port binding="InterfaceOfA">
       <address location="location of A"/>
     <requiredBinding binding="InterfaceOfB"/>
   <service name="B">
     <port binding="InterfaceOfB">
       <address location="location of B"/>
     <requiredBinding binding="InterfaceOfD"/>
   <service name="C">
     <port binding="InterfaceOfC">
       <address location="location of C"/>
     <requiredBinding binding="InterfaceOfB"/>
   <service name="D">
     <port binding="InterfaceOfD">
       <address location="location of D"/>
     <requiredBinding binding="InterfaceOfA"/>

 A deployment tool, while deploying A, can search for known
services implementing InterfaceOfB (just a QName search) and list
those or select one or whatever.

 With solicit/response and notification operations the tool has
to search for services that implement a binding that has
request/response or oneway operations that match the 
solicit/responses and notifications of service A. This is a 
complex search, not just a single QName.
 Now with solicit/response and notification intermixed in binding
Foo with request/response and oneway operations, what does this
situation mean? Should the matching binding have only
request/responses and oneways for the solicit/responses and 
notifications of Foo, or should it also have solicit/responses 
and notifications for the request/responses and oneways of Foo?

 The ordering of requests is the is clearly in scope of an
orchestration/flow language. I believe that the <requiredBinding>
information can and should be in an orch/flow language, too, as 
it is a matter of the concrete deployment and implementation, 

   <orch:node name="A">
     <orch:implements wsdlService="...:A"/>
     <orch:requires wsdlBinding="...:InterfaceOfB"/>

 If you know of anyone inside WG or on the mailing list who might 
be interested in this thread but might miss it because of the 
[amtf] subject, please point them to it. 8-)
 I think that speaking in abstract terms clarifies a lot of 
things it should be easier to argue our points.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)

On Tue, 21 May 2002, Prasad Yendluri wrote:

 > >  2) I don't think we need the "incoming" and "outgoing"
 > > operations. I.e. I don't believe we need solicit/response and
 > > notification operations because they are IMHO just
 > > request/response and one-way operations the other way.
 > <PY>This has been a very contentious issue but, once again I think we
 > need both. I am not sure how do you capture an outgoing operation as
 > reverse of an incoming operation at the abstract level?
 > </PY>
 > >
 > >  An orchestration language can say that a service with
 > > wsdl:binding A needs a service with wsdl:portType B to function
 > > properly
 > <PY>Are you suggesting we mix binding level and abstract level? I am not
 > sure what the above is conveying?</PY>
 > > and this will ease the matching of the second service
 > > (as opposed to looking for equivalent solicit/response and
 > > request/response messages in service descriptions, for example).
 > <PY>I still fail to see how this can work? I think we need a way to
 > capture things from the initiator (invoker perspective) in addition to
 > service provider perspective. It is not all symmetric in the Business
 > process (or flow) level. B receives Req-1 from A and Req-2  from C and
 > sends a Req-3 D, which replies to A and B and B replies to C. How can
 > this be captured all in a symmetric manner?
 > </PY>
Received on Wednesday, 22 May 2002 10:08:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:38 UTC