Robust In-Only
Even though the specification leaves the decision of synchronicity to the concrete bindings and service implementation, this pattern is intended for services that desire asynchronous invocation, but needs notification that a fault was generated. Because this pattern follows the "Message Triggers Fault" ruleset, the node generating the fault is responsible for attempting to send the fault message to the sender. Potential concrete implementations may involve a duplex channel to accomplish the fault notification.

In-Out
This pattern is the traditional request-response pattern prevalent in many services currently in production. Its use of the "Fault Replaces Message" ruleset indicates that if the "In" message generates a fault, then the "Out" message would be replaced by the Fault message. This behavior is consistent with the existing generation of services described by WSDL 1.1. These patterns provide a way of describing those same services in WSDL 2.0.

In-Optional-Out
This pattern is a variation of the In-Out pattern where the Out message is optional. It uses the "Message Triggers Fault" ruleset, so faults would be returned to the message sender; however, the Out message may or may not be sent to the sender. Potential concrete scenarios include, but aren't limited to, services bound to a duplex channel so that the sender isn't required to block guessing whether or not a message will be returned.

Out-Only
The outbound patterns aren't obviously applicable and most certainly generate a number of questions. However, large enterprises that face the challenge of data subscribers and dynamic composability of services might find significant value here. This specific pattern can be implemented concretely as a fire-and-forget service. A potential scenario can include wiring up a packaged application to an enterprise logging solution.

Robust Out-Only
As another outbound pattern, this pattern is much like Robust In-Only. It's intended for scenarios where the main interaction will be implemented asynchronously, but the generator of the first message in the pattern has to be notified of the fault.

Out-In
This pattern is the outbound representation of the traditional request-response pattern. In essence, the contract is saying that "clients" have to provide an endpoint for the "service" to invoke. Like its inbound counterpart, it returns the fault to the message sender.

Out-Optional-In
This pattern uses the "Message Triggers Fault" ruleset so that faults will be returned to the message sender, but the response, indicated as the "In" message, may or may not be sent. Integration scenarios are likely to be the primary users of this pattern if implementations follow an asynchronous messaging approach.

Conclusion
The Component Model and Message Exchange Patterns found in WSDL 2.0 are promising additions to the language. Even though implementations of the WSDL 2.0 specification aren't readily available, service development and service deployment are expected to become much easier with the next generation of platforms and tools built with the specification in mind.