W3C home > Mailing lists > Public > www-ws-desc@w3.org > October 2006

Synchronous v/s Asynchronous, a WSA question, and few suggestions

From: Ramkumar Menon <ramkumar.menon@gmail.com>
Date: Wed, 4 Oct 2006 17:09:17 -0700
Message-ID: <22bb8a4e0610041709u3716f0cdk976a80a0fecbcd5b@mail.gmail.com>
To: www-ws-desc@w3.org

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?
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]
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
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
e) What is the relationship between the transport specified in the
WSDL 1.1Bindings 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.

Few other points:-
a) I noticed that Figure 2-1 [xml infoset] in Section 2.2.1 in WSDL
2.0primer 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.

Received on Thursday, 5 October 2006 00:09:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:07:02 UTC