Message Design in Service-Oriented Applications
| Retired Content |
|---|
The Web Service Software Factory is now maintained by the community and can be found on the Service Factory site. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. Retired: November 2011 |
The patterns used for integrating applications have evolved over time, from File Transfer or database-based Data Integration to the Functional Integration patterns, in which applications integrate by sharing functionality. Approaches to providing functional integration include distributed object invocation and service-oriented integration.
Distributed object invocation employs remote procedure calls (RPCs). This approach seems natural to most developers because it allows them to work with remote objects as if they were simply local objects, and sometimes it supports passing objects by reference or passing callback delegates. However, the use of distributed object-based technologies (such as .NET remoting, Java RMI, DCOM, and CORBA) results in tightly coupled applications that are difficult to integrate with. Typically, applications designed using this approach are not resilient to interruptions in network connectivity or to the loss of service at the client or server.
Because of these shortcomings, developers increasingly use service-oriented integration to accomplish functional integration. Using service-oriented integration provides a number of advantages. Applications can be more loosely coupled, with interactions based on various message exchange patterns, such as request-response, simplex (one-way), duplex, and solicit response. In addition, messages that conform to known schemas can be routed through intermediaries that process parts of the message (for example, to perform message validation or authentication and authorization) before they are delivered to the service that processes the message. More advanced message exchange patterns, such as Publish/Subscribe, can also be used to notify subscribers when a message is available to be processed.
In a service-oriented environment, interactions between services are explicitly specified in terms of platform independent messages that are defined by a contract (otherwise known as an interface). This contract is completely independent of each service's design and implementation.
Note
Four tenets have been established for designing service-oriented applications. For more information about these tenets, see Code Name Indigo: A Guide to Developing and Running Connected Systems with Indigo by Don Box on MSDN.
This topic provides guidance for designing messages in a service-oriented architecture with information that applies to both the .NET Framework 2.0 and .NET Framework 3.5.