Defining a Web Service's Abstract Interface
Each operation specifies the
types of messages that the service can send or receive as part of
that operation. Each operation also specifies a message exchange pattern that indicates the
sequence in which the associated messages are to be transmitted between the parties. For
example, the in-out pattern (described below) indicates that if the client sends a message in to the
service, the service will either send a reply message back out to the client (in the normal case) or
it will send a fault message back to the client (in the case of an error).
The XML schema for WSDL 2.0
The interface element has two optional
styleDefault attribute can be used to
define a default value for the
style attributes of all operation sub-elements under this
interface. Interfaces are referred to by
QName in other components such as bindings.
extends attribute allows an interface to extend or inherit from one or more other
interfaces. In such cases, the interface contains the operations of the interfaces it extends, along
with any operations it defines directly. Two things about extending interfaces deserve some
attention. First, an inheritance loop (or infinite recursion) is prohibited: the interfaces that a given
interface extends must not themselves extend that interface either directly or indirectly.
Second, we must explain what happens when operations from two different interfaces have the same target namespace and operation name. There are two cases: either the component models of the operations are the same, or they are different. If the component models are the same (per the component comparison algorithm defined in WSDL 2.0 Part 1 Core Language) then they are considered to be the same operation, i.e., they are collapsed into a single operation, and the fact that they were included more than once is not considered an error. (For operations, component equivalence basically means that the two operations have the same set of attributes and descendants.) In the second case, if two operations have the same name in the same WSDL target namespace but are not equivalent, then it is an error. For the above reason, it is considered good practice to ensure that all operations within the same target namespace are named uniquely.
Finally, since faults can also be defined as children of the
interface element (as described in
the following sections), the same name-collision rules apply to those constructs.
operation element has a required
name attribute, while
style are optional attributes.
WSDL Message Exchange Patterns
Message exchange patterns (MEPs) define the sequence and cardinality of messages within an operation. Eight types of message patterns are defined in the WSDL 2.0 specifications, but this list is not meant to be exhaustive and more patterns can be defined for particular application needs. Depending on how the first message in the MEP is initiated, the eight MEPs may be grouped into two groups: in-bound MEPs, for which the service receives the first message in the exchange, and out-bound MEPs, for which the service sends out the first message in the exchange. A service may use out-bound MEPs to advertise to potential clients that some new data will be made available by the service at run time.
WSDL message exchange patterns use fault generation rules to indicate the occurrence of faults. Message exchange may be terminated if fault generation happens, regardless of standard rule sets. The following standard rule set outlines the behavior of fault generation:
- Fault Replaces Message—any message after the first in the pattern may be replaced with a fault message, which must have identical direction and be delivered to the same target node as the message it replaces
- Message Triggers Fault—any message, including the first in the pattern, may trigger a fault message, which must have opposite direction and be delivered to the originator of the triggering message
- No Faults—faults must not be propagated