TIBCO Software Inc.
Position Paper for the W3C WSDL Workshop
11-12 April, 2001
San Jose, California

For further information, please contact Frank J DeRose, TIBCO's primary member on the
W3C XML Protocol Working Group. Frank's particulars are:

Frank DeRose
Software Architect
TIBCO Software Inc.
3165 Porter Dr
Palo Alto, CA 94303
650-846-5570 (vox)
650-846-1267 (fax)
frankd@tibco.com
www.tibco.com

TIBCO shares the conviction that the development of web services is a critical next step in
the realization of the potential of the World Wide Web. In July, 1999, TIBCO was spun off
from Reuters, a global distributor of real-time news and financial data. Through its
web-hosting division, tibco.net (http://www.tibco.net/about.html), TIBCO hosts a suite of
“web services” that serve up Reuters financial and news content to large groups of Internet
users. For example, Yahoo! utilizes TIBCO’s “quote web service” to provide stock quotes to
their users. By accessing TIBCO’s web services, portal builders can easily obtain real-time
news and financial information, and then aggregate, personalize, and format it for
presentation through a custom portal.

In order for our partners to be able to access TIBCO's web services more easily, these
services need to be fully described in some kind of standard web service definition
language. Hence, our interest in participating in the development of WSDL. Our goal would
be to work together with other interested parties to arrive at a mutually acceptable
specification for WSDL. Toward that end, we would like to discuss several potential problems
we see with the WSDL spec. These problems are discussed in detail below. If we can arrive
at a consensus, TIBCO and Reuters could begin to describe their global financial and news
web services in terms of the spec. Acceptance of WSDL by TIBCO and Reuters could only
serve to accelerate acceptance by others.

The rest of this document consists of comments from TIBCO engineers on the Web Services
Definition Language (WSDL) 1.0 (http://msdn.microsoft.com/xml/general.wsdl.asp). We have
divided our comments into two parts:

1.) A list of problems we see with the WSDL spec.
2.) A proposal for changes to WSDL that we feel would remedy the problems.

POTENTIAL PROBLEMS WITH THE WSDL SPEC

PROBLEM 1: MESSAGE PARTS SHOULD BE DROPPED
Given the types T, t1, t2, … tn defined in XML Schema, there seems to be no difference
between:

-- a message of type T, where T has multiple named elements e1, e2, ... en, each with its
corresponding type t1, t2, ... tn

-- a message with multiple named message parts m1, m2, ... mn, each with its corresponding
type t1, t2, ..., tn

Take a look at Don Box's article "A Young Person's Guide to The Simple Object Access
Protocol: SOAP Increases Interoperability Across Platforms and Languages" in the February
2000 issue of MSDN Magazine (http://msdn.microsoft.com/msdnmag/issues/0300/soap/soap.asp).
In the section "Inside the SOAP Payload," Don writes:

"SOAP promotes the method request and method response to first class status. In SOAP, the
request and response are actually instances of types."

This suggests that Don had in mind a direct mapping from a single request (or response)
message to a single type without the indirection of message parts. Message parts are an
artifact of a parameter-centric approach. If a method signature is defined in terms of a
set of parameters (as in a traditional IDL), then the notion of message parts is required
to represent these individual parameters. We may contrast the parameter-centric approach
with a message-centric approach, where a method signature is defined in terms of messages
(input, output, and fault messages).

Based on such considerations we move that message parts be dropped from WSDL.

PROBLEM 2: PORT TYPE ALLOWS INCOMPATIBLE OPERATIONS
Unless we’re mistaken, the WSDL spec allows for port types that can consist of a collection
of "incompatible" operations. For example, the spec would seem to allow for a port type
that is a collection of one notification-operation and one request-response-operation. This
would seem to us to be a very strange port indeed.

PROBLEM 3: OPERATIONS ARE SPLIT INTO 2 OPERATION HALVES
WSDL splits request-reply operations (as defined in traditional IDL's) into two halves: a
client half (the WSDL solicit-response-operation) and a server half (the WSDL
request-response-operation). It seems to us there should be one and only one definition of
an operation and that a client/server pair should share this definition (or, rather,
should share the definition of an interface containing a set of such operations; see below
on interfaces and channels). More specifically, operation halves are objectionable because
they are 1.) redundant and 2.) prone to getting out of sync. They are redundant because you
have to define two half operations instead of one whole operation and you have to define
the same messages in both halves. For example, take the request-reply operation Doit as
defined in a traditional IDL. In WSDL, Doit would be divided into two operation halves:
SRO_Doit (the solicit-response-operation) and RRO_Doit (the request-response-operation).
SRO_Doit must define the output message foo, the input message bar, and the fault message
flt. RRO_Doit must redundantly define the input message foo, the output message bar, and
the fault message flt. Also, the meanings of the terms "input" and "output" in WSDL depend
on whether they are relative to SRO_Doit or to RRO_Doit. By making these terms relative to
the operation half, WSDL ignores the traditional meaning of these terms as used by various
IDL's for a long time now. In the IDL tradition, "input” means “traveling from the client
to the server, and "output" means traveling from the server back to the client: they are
absolute terms that are not relative to an operation half. In WSDL "input" means
"traveling from the client to the server" only if it is construed relative to RRO_Doit. If
it is construed relative to SRO_Doit, it means "traveling from server to the client." This
is very confusing. Operation-halves are prone to getting out of sync because you can change
one operation-half definition without changing the other. That is, I can change the input
message of SRO_Doit from bar to xyz without changing the output message of RRO_Doit from
bar to xyz.

PROBLEM 4: OPERATIONS ARE ALWAYS REQUIRED
WSDL requires operations even in scenarios where they are not required. Such scenarios are
those that are generally described by such terms as: document-oriented, loosely-coupled,
event-driven, or publish-subscribe. If you want to define a “subscriber to a message” in
WSDL, you must define a WSDL port type with a one-way-operation. At TIBCO, we have a
concept of “sink endpoints” (where an endpoint is similar to a port type). We distinguish
between two kinds of sink endpoints: subscribers and RPC servers. The essence of the
distinction is that an RPC server is associated with operations (actually, an interface
with operations; see below), while a subscriber isn't. The act of sending (publishing) a
message (document, event) is essentially different from the act of invoking an operation
(remote procedure call). When sending a message, one is simply making the data available on
the message bus without any further specification of the operation to be performed on the
data. In fact, in a multicast scenario, different recipients of the message may do
different things with the data.

Now, a contrary argument may be constructed that goes something like this: “A message
received by a subscriber has to be processed. It's not good enough if the subscriber just
receives the message. In order for something useful to happen, the subscriber must pass the
message to some kind of processor. And the only way to define this processor is to specify
some processing entrypoint, or operation.” But this argument only proves that there needs
to be an entrypoint and not that entrypoint must be publicly exposed in WSDL. The
entrypoint can simply be treated as just an internal implementation detail.

The problem with the spec is most evident in Section 3.5 soap:body. In this section, the
WSDL spec states:

“If the enclosing operation’s style is “rpc,” each [message] part is a parameter or return
value and appears inside a wrapper element within the Body (see Section 7.1 of the SOAP
specification). If the style is “document,” each [message] part is a document and appears
directly within the Body.”

Section 7.1 of the SOAP spec states:

“The method invocation is viewed as a single struct containing an accessor for each [in]
or [in/out] parameter. The struct is both named and typed identically to the method name.”

Thus, the “wrapper element” referred to in the WSDL spec is the same as the “struct”
referred to in the SOAP spec as “named and typed identically to the operation.” Thus, SOAP
itself requires an operation name (wrapper element, struct) only in rpc mode, and not for
document mode. WSDL, on the other hand, requires operations for both document and rpc mode.
By always requiring operations, WSDL has implicitly preferred the RPC programming model
over the message-centric programming model. We believe that WSDL ought to be agnostic with
regard to programming model, just as the SOAP spec is (see the comments on "programming
model" in the Section 1 "Introduction" in the SOAP spec).

PROPOSAL FOR CHANGES WITH THE WSDL SPEC
In the previous section we outlined some of the problems we see with the WSDL spec. In this
section, we propose some changes to the spec that we feel would remedy these problems. 

What we would like to see in the WSDL spec is the following set of abstract elements:

-- Types: We are happy with types as currently proposed in the WSDL spec. A type in this
   sense is analogous to a C struct or a COM UDT. In other words, it is a type without
   behavior (methods, operations).

-- Messages: We would be happy with messages as currently proposed in WSDL spec if a
   message were defined directly in terms of a type. In other words, as noted in Problem
   1, we would like to see message parts eliminated from the spec.

-- Operations: Roughly, a tuple consisting of an operation name, an input message type
   (the attributes of whose type would be all the input parameters), an output message
   type (the attributes of whose type would be all the output parameters), and a set of
   fault message types. For example:

     Operation Name: Doit
     Input Message: DoitInMessage
     Output Message: DoitOutMessage
     Fault Messages: FaultMessage (consisting of an error code and human-readable string)

  In the case of a successful operation invocation, the output message would be returned
  to the client. In the case of a fault, the fault message would be returned. One way
  operations would never have output or fault messages.

-- Interfaces: Collection of operations.

-- Port types (or endpoints): Port types are defined in terms of the following two
   dimensions:

     Message-or-RPC Dimension:
      > Message-oriented (one-way, event-oriented, document-oriented, publish-subscribe)
      > RPC-oriented (usually two-way, operation-oriented)

     Source-or-Sink Dimension:
      > Source for published messages or sender of request for RPC's
      > Sink for published messages or recipient of request for RPC's

  Problems 2, 3, and 4 in the previous section focused on problems with port types and
  operations. We believe the source of these problems lies in the fact that the current
  WSDL spec seeks to associate the two dimensions shown above with operations, instead of
  with port types. Combinations of the values in the two dimensions yield 4 kinds of port
  types: a Publisher (message-oriented source), Subscriber (message-oriented sink), RPC
  Client (RPC-oriented source), RPC Server (RPC-oriented sink).

-- Channels. If an even tighter coupling is desired, channels could be defined. There would
   be two kinds of channel: an RPC channel that would consist of an RPC client, an RPC
   server, and the common interface they are using; an event channel that would consist of
   a publisher, a subscriber, and the message (set of messages) that can pass from the
   publisher to the subscriber.

  <NOTE>
  Channels need more discussion. One possibility would be to distinguish between a logical
  channel (as described above) and a physical channel (similar in some respects to the
  "binding" element in the current WSDL spec). Such a physical channel might consist of a
  transport (for example, HTTP or TIBCO’s Rendezvous), an address (for example, URL or
  TIBCO subject), and a payload format (SOAP envelope, or TIBCO’s ActiveEnterprise wire
  format).
  </NOTE>