- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Wed, 04 Oct 2006 22:49:32 -0700
- To: Ramkumar Menon <ramkumar.menon@gmail.com>
- CC: www-ws-desc@w3.org
Ramkumar Menon wrote: > Gurus, > > I am troubled by a few questions since a few days. Appreciate your > comments in this matter. > > a) What defines "synchronous" or "asynchronous" - Are this > terms normatively defined in any related specification ? Are these > terms "adjectives" for message exchange patterns? That is hard to define in the abstract. I agree with Tony's definition wrt to a synchronous protocol such as HTTP. > b) Does "synchronous" interaction require the caller program to > "block" on the response from the service ? [I know it really depends on > what (a)'s answer is] Never, IMHO. Blocking/non-blocking is quite independent of synchronous/asynchronous. One can block on a synchronous interaction or not; one can block on an asynchronous interaction or not. This is assuming that the response is going to go to the 'same' place. > c) Can't a Request/Response transmission primitive [that wsdl 1.1 > defines] be asynchronous [thru wsdl extensions] ? The specification > does not talk about the relationship between synchronicity and the type > of the transmission primitive. So I assume this does not violate the > conformance requirements. Yes. In the SOAP/HTTP case, one just has to specify the appropriate value for wsa:ReplyTo MAP. > d) Is it correct if I state that synchronicity and asynchronicity of an > interaction cannot be defined at the abstract level of a service > definition and depends purely on the transport bindings being used ? [or > if the user employs extensions for the operation in the abstract portion > of the WSDL] The async task force spend quite a bit of time on this and IIRC there was never any agreement on the definition of what synchronous or asynchronous means. It all depends on which layer you are at. > e) What is the relationship between the transport specified in the WSDL > 1.1 Bindings and the ReplyTo/FaultTo requirements that are imposed on > the service ? - confusing question, aint it ? :-) > Let me explain with an example. > I define a WSDL 1.1 service with a portType with a > request/response/fault operation. I define WS-A headers for each of the > input, output and fault in the binding section. I wish to return faults > from this operation to a FaultTo endpoint that is different from the > ReplyTo endpoint. Shouldnt it be possible to send messages to the > FaultTo endpoint on a different transport ? [ i.e. Lets say I wish to > send faults to an Email Address]. Question is as follows - If so, would > this require separate bindings for the operation to be defined within > the WSDL ?". If this answer to this question is "yes", then, since > transports are specified at the operation level, this would require two > bindings, one for http and one over smtp. And in the second binding, > what does it mean to specify the information for the input and output - > they are unused. :-) I am gonna get killed for making this assumption , > but I am really confused on this last point - I maybe wrong here. Or > maybe WSDL 1.1 is tough to gel in with WSA requirements without relying > on some extension mechanism. > WSDL 1.1 (and WSDL 2.0) does support specifying bindings at the message level. Specifying promiscuous transport bindings is hard. AFAIK, the only way to do this is to specify a binding (i.e., create your own that says input is over HTTP and output over SMTP) or a binding extension that specifies the transports or says that the transport can be SMTP or HTTP. HTH. -Anish -- > Few other points:- > a) I noticed that Figure 2-1 [xml infoset] in Section 2.2.1 in WSDL 2.0 > primer states that an interface should have 1-* number of operations. > This should be changed to 0-*.[since there could be interfaces with zero > operations, for instance, an interface that just defines faults] > b) Section 2.9.1 in the Core Language Spec states that "A Binding > component that defines bindings for an Interface component MUST define > bindings for all the operations of that Interface component". Shouldnt > a similar assertion be made regarding the Faults declared in the > interface as well? i.e. "A Binding component that defines bindings for > an Interface component MUST define bindings for all the faults of that > Interface component" > c) An interesting thought [on wsdl 2.0] - Why cant faults be global to a > description - I have a scenario where the wsdl defines two interfaces - > one for reserving flight tickets for the travel, and one for making > hotel reservations for the travel.Each of these interfaces are served by > two separate endpoints [lets say, outsourced to two different organizations] > Both of them throw a fault namely "CreditCardAuthorizationFault" and a > "InsufficientFundsFault". Why cant this fault be declared globally, and > referenced within each of the interfaces ? [I'm being too impractical, > aint I ? :-) ] - But would definitely appreciate an explanation to this > point. > > rgds, > Ram
Received on Thursday, 5 October 2006 05:51:01 UTC