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 interface element

The interface element has two optional attributes: styleDefault and extends. The 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.

The optional 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.

The interface operation element has a required name attribute, while pattern, safe, and 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

---

---