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

XLANG, WSFL response on solicit-response and output-only

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Fri, 26 Apr 2002 16:52:49 -0700
Message-ID: <330564469BFEC046B84E591EB3D4D59C05C06333@red-msg-08.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>
I asked the authors of XLANG and WSFL whether they could provide us with
a data point about whether they required solicit-response and
output-only.  Remember this is only a single data point, and we may want
to keep, clarify, or replace these operations for other reasons.

Frank Leymann of IBM (WSFL) indicated that removal of these operations
would not be harmful from an WSFL perspective.

I will simply quote the response from Microsoft's Satish Thatte (XLANG):


It is true that the published XLANG specification
(http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm) uses
ports with outbound operations (notification and solicit/response) to
reflect dependencies on external services.  The external services would
be expected to provide ports with "mirror image" functionality
(corresponding oneway and request/response operations).  This is
certainly a technically viable approach if the semantics of outbound
operations is interpreted in the way it was interpreted in XLANG.  In
particular, it was assumed that ports have defined polarity, i.e., they
contain either all inbound or all outbound operations.

Given polarity, the other way to express dependencies on external
services in the context of orchestration is to make an explicit
declaration that the orchestrated service "requires" a particular type
of service, where the required service is always described from the
provider's viewpoint.  This is technically equivalent and no harder to
understand and use.  So, speaking from an XLANG/orchestration
perspective, service descriptions restricted to only inbound operations
would be workable and would meet our requirements for expressing service

Received on Friday, 26 April 2002 19:53:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:22 UTC