So far, I haven't said anything about what happens if something goes wrong. Here are some problems you might encounter:
The service provider detects an error and sends back a fault message instead of a typical response message.
The service provider is unavailable and therefore cannot receive the message.
The transport layer for the messages might not be reliable. That is, messages might get lost over the network.
Dealing with these situations can make message exchange patterns a lot more complicated.
If the service provider (or any other process receiving messages and sending responses) detects an error, instead of sending back the usual response message, it will send back a fault message (see Figure 10-6). Usually, you can define special attributes for these fault messages.
Figure 10-6. Request/response with optional fault
Whether and how faults are handled in special cases has to do with the protocol you use. For example, Web Services allow you to specify and deal with special fault messages that are returned by providers in the event that (expected and modeled) errors occur.
If there is a technical problem that prevents a message from being delivered, the sender must be notified. However, this is more complicated than it sounds. Consider a simple one-way message. If the sender sends a message without expecting any confirmation, ...