Explained: Web Services, Enterprise Services and Remoting

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Srinath Vasireddy, Ashish Babbar, and Alex Mackman


Prescriptive Guidance for Web Services, Enterprise Services, and .NET Remoting

Services are the preferred communication technique to use across application boundaries, including platform, deployment, and trust boundaries. You can implement services today by using Web services or Web Services Enhancements (WSE). Although WSE provides a rich set of features, you should evaluate whether or not you can accept the WSE support policy. Enterprise Services provides component services such as object pooling, queued components, a role-based security model and distributed transactions, and should be used as an implementation detail within your service when you need those features. .NET remoting is preferred for cross-application communication within the same process.

Object Orientation and Service Orientation

When you design distributed applications, use the services approach whenever possible. Although object orientation provides a pure view of what a system should look like and is effective for producing logical models, an object-based approach can fail to consider real-world factors, such as physical distribution, trust boundaries, and network communication, as well as nonfunctional requirements, such as performance and security.

Table 10.1 summarizes some key differences between object orientation and service orientation.

Object Orientation

Service Orientation

Assumes a homogeneous platform and execution environment.

Assumes a heterogeneous platform and execution environment.

Shares types, not schemas.

Shares schemas, not types.

Assumes cheap, transparent communication.

Assumes variable cost, explicit communication.

Objects are linked: object identity and lifetime are maintained by the infrastructure.

Services are autonomous: security and failure isolation are a must.

Typically requires synchronized deployment of both client and server.

Allows continuous, separate deployment of client and server.

Is easy to conceptualize and thus provides a natural model to follow.

Builds on ideas from component software and distributed objects. Dominant theme is to manage/reduce sharing between services.

Provides no explicit guidelines for state management and ownership.

Owns and maintains state or uses the reference state.

Assumes a predictable sequence, timeframe, and outcome of invocations.

Assumes message-oriented, potentially asynchronous, and long-running communications.

Goal is to transparently use functions and types remotely.

Goal is to provide inter-service isolation and wire interoperability based on standards.

Table 10.1: Object Orientation vs. Service Orientation

Application Boundaries

Common application boundaries include platform, deployment, trust, and evolution. (Evolution refers to whether or not you develop and upgrade applications together.) When you evaluate architecture and design decisions that affect your application boundaries, consider the following:

Objects and remote procedure calls (RPC) are appropriate within boundaries. Services are appropriate across and within boundaries.

Recommendations for Web Services, Enterprise Services, and .NET Remoting

When you are working with ASP.NET Web services, Enterprise Services, and .NET remoting, Microsoft recommends that you:

  • Build services by using ASP.NET Web Services.
  • Enhance your ASP.NET Web services with WSE if you need the WSE feature set and you can accept the support policy.
  • Use object technology, such as Enterprise Services or .NET remoting, within a service implementation.
  • Use Enterprise Services inside your service boundaries in the following scenarios:
    • You need the Enterprise Services feature set (such as object pooling; declarative, distributed transactions; role-based security; and queued components).
    • You are communicating between components on a local server and you have performance issues with ASP.NET Web services or WSE.
  • Use .NET remoting inside your service boundaries in the following scenarios:
    • You need in-process, cross-application domain communication. Remoting has been optimized to pass calls between application domains extremely efficiently.
    • You need to support custom wire protocols. Understand, however, that this customization will not port cleanly to future Microsoft implementations.


When you work with ASP.NET Web services, Enterprise Services, or .NET remoting, consider the following caveats:

  • If you use ASP.NET Web services, avoid or abstract your use of low-level extensibility features such as the HTTP Context object.
  • If you use .NET remoting, avoid or abstract your use of low-level extensibility such as .NET remoting sinks and custom channels.
  • If you use Enterprise Services, avoid passing object references inside Enterprise Services. Also, do not use COM+ APIs. Instead, use types from the System.EnterpriseServices namespace.


Personal tools