Export (0) Print
Expand All

Distributed Application Communication

Visual Studio .NET 2003

Establishing communication between objects that run in different processes — whether on the same computer or across the Internet — is a common development goal, especially when building widely distributed applications. Traditionally, this has required in-depth knowledge not only of the objects on either end of the communication stream, but also of a host of lower-level protocols, application programming interfaces, and configuration tools or files. In short, it was a complex task demanding substantial consideration and experience. The .NET Framework and technologies such as ATL Server provide several ways to communicate with objects in different application domains in a simple and scalable manner.

Programming Models

When designing your distributed application, you can choose between several new programming models to enable communication across the application:

  • ASP.NET - You can create XML Web services using the ASP.NET page framework, enabling these XML Web services to access the many features of the .NET Framework, such as authentication and caching. For more information, see XML Web Services in Managed Code.
  • ATL Server – You can also create XML Web services using ATL Server, which offers a set of classes that extend the Active Template Library (ATL) for accessing the full functionality of IIS through ISAPI. ATL Server provides classes that make it possible for the developer to easily handle issues such as caching, thread pooling, and session state. For more information, see XML Web Services Created with ATL Server.
  • .NET Remoting – You can use .NET Remoting to create a loosely coupled solution using XML Web services or to create a tightly coupled solution using a binary protocol. For more information, see .NET Remoting Overview.

XML Web services are applications that provide the ability to exchange messages in a scalable, loosely coupled, and stateless environment using standard protocols such as HTTP, XML, XSD, SOAP, and WSDL. XML Web services make possible the building of modular applications within and across companies in heterogeneous environments making them interoperable with a broad variety of implementations, platforms and devices. The SOAP-based XML messages of these applications can have explicit (structured and typed), or loosely defined parts (using arbitrary XML). The ability of the messages to evolve over time without breaking the protocol is fundamental to the flexibility and robustness of XML Web services as a building block for the future of the Web. For more information, see Programming the Web with XML Web Services.

.NET remoting provides a framework that makes it possible for objects to interact with one another across application domains. The framework provides a number of services, including activation and lifetime support, as well as communication channels that are responsible for transporting messages to and from remote applications. Formatters are used for encoding and decoding the messages before the channel transports them. Applications can use binary encoding where performance is critical, or XML encoding where interoperability with other remoting frameworks is essential. All XML encoding uses the SOAP protocol in transporting messages from one application domain to the other. For more information, see Accessing Objects in Other Application Domains Using .NET Remoting.

Considerations

When examining each programming model to determine which to choose, it is important to consider your application requirements because they impact or sometimes even dictate which one you use. You can use the following considerations as a guide when making your decision.

Wide Client Reach

Applications achieve wide client reach by making component access available to the broadest assortment of clients by utilizing technologies that are not limited to a particular platform or object model. For more information, see XML Web Services Overview.

  • Because XML Web services use standard protocols and are platform neutral, they enable communication with the widest variety of SOAP implementations, platforms and devices.
  • Both .NET Remoting and ATL Server are capable of providing XML Web services, but neither SOAP implementation is as flexible as that of XML Web services created using ASP.NET. This is because both implementations use remote procedure call (RPC) style, encoded messages.

Tightly or Loosely Coupled

A tightly coupled application uses communication methods that impose custom interdependencies between the distributed parts of the application, such as requiring a platform-specific technology or foreknowledge of proprietary protocols to communicate. Alternatively, a loosely coupled application uses methods that impose a minimum set of requirements for communication to occur, such as using self-describing data and ubiquitous protocols like HTTP and XML.

  • XML Web services provide an inherently loosely coupled programming model. XML Web services must be agnostic regarding the choice of operating system, object model and programming language to succeed in the heterogeneity of the Internet.

    Furthermore, XML Web services created using ASP.NET can use messages with a mix of strongly typed fields and arbitrary XML. Such messages enable the exchange of unstructured data or data that was note defined in advance at run time.

  • .NET Remoting can provide a tightly coupled, object-based programming model between client and server because it can pass objects in the following ways: as parameters in method calls, as the return value of a method call, or as values resulting from property or field access of a .NET component.

    In cases where the client and server objects are in different application domains, all method call parameters on the stack are converted into messages and transported to the remote application domain where the messages are turned back into a stack frame and the method call is invoked. .NET Remoting uses the same procedure for returning results from the method call.

Message Formatting and Encoding

Both XML Web services and .NET remoting use message-based communication. The formatting of the messages and the encoding of the data those messages contain are predetermined at design time. The formatting and encoding combination you choose can limit which clients can participate.

  • XML Web services always use the SOAP protocol. The Web Services Description Language (WSDL) defines two encoding styles for parameters: Encoded and Literal. Encoded refers to encoding the parameters using the SOAP encoding outlined in Section 5 of the SOAP specification. For the SOAP specification, see the W3C Web site (http://www.w3.org/TR/soap). Literal refers to formatting the parameters using a predefined XSD schema for each parameter. For the WSDL specification, see the W3C Web site (http://www.w3.org/TR/wsdl).

    XML Web services created using ASP.NET have the flexibility to use one or the other. WSDL also defines two styles for how to format the contents of a Body element in a SOAP message: RPC and Document. XML Web services created using ASP.NET support both the Document and the RPC encoding styles, with Document being the default.

    XML Web services created using ATL Server or .NET Remoting are not as flexible in this regard. They can only use the SOAP encoding and RPC message style.

  • .NET Remoting can use either SOAP, binary or a custom protocol you develop. When .NET Remoting uses SOAP, it uses the RPC encoding style outlined in Section 7 of the SOAP specification and the SOAP encoding outlined in Section 5 of the SOAP specification. For the SOAP specification, see the W3C Web site (http://www.w3.org/TR/soap). When .NET Remoting uses the provided binary protocol, both the client and server require the .NET Framework to process messages.

Type System Fidelity

Type system fidelity denotes that type information is not lost in the communication process. For example, when .NET Remoting's binary formatter serializes an object, it preserves the object's type information. Reversing the process, you can deserialize the serialized object to reconstitute an exact duplicate of the original object. To leverage type system fidelity, both participants in the communication must use the same type system. For example, two .NET Framework applications can leverage type system fidelity since each uses the common type system defined by the common language runtime.

Binary serialization preserves type fidelity, which is useful when passing objects between client and server. However, XML serialization serializes only public properties and fields and does not preserve type fidelity. This is useful when you want to provide or consume data without restricting the application that uses the data. Because XML is an open standard, it is an attractive choice for sharing data across the Web. For more information, see Serializing Objects.

  • XML Web services do not expose the server-side types to client applications. The Web service hides the implementation because it uses XML serialization when creating SOAP messages. Instead, XML Web services expose data structures using the standard XSD schema type system. In some cases, this imposes constraints on the types you can expose. However, it makes it possible for a very rich expression of data structures that many platforms and programming systems can understand.
  • .NET Remoting provides remote access to server-side objects with full type system fidelity. However, this is only available when using the binary formatter. When using the SOAP formatter, type system fidelity is not available.

Performance

Disregarding application performance will inevitably result in an application that performs poorly. The responsibility for application performance occurs both at design time and at run time. A prominent consideration when choosing how to access a distributed component is the impact it has on the performance of the application.

  • The basic design principle for XML Web services is wide client reach and therefore the primary design goal is interoperability, not performance. While performance may not be the top priority, in many cases the performance provided is more than sufficient.
  • A managed executable using the .NET Remoting binary protocol over a TCP channel offers the highest performance because the binary formatting is more compact and the system takes less time to serialize and deserialize the stream.

State Management

A component in the business logic layer that must maintain state between calls consumes resources. Multiply this fact by the number of potential clients and the amount of resources consumed increases, along with the likelihood that resource contention will occur. Such a component greatly complicates the ability of the application to scale.

  • XML Web services assume a stateless programming model, and handle each incoming request independently. The only state maintained between requests is anything persisted in a data store, such as SQL Server.

    However, XML Web services created using ASP.NET have access to the same state management options as other ASP.NET applications. For more information, see Managing State in XML Web Services Created Using ASP.NET.

  • .NET Remoting has the option of using a stateless programming model, but it also supports server and client activation of remote objects. .NET Remoting normally uses server activation when remote objects are not required to maintain any state between method calls. However, .NET Remoting also uses server activation when multiple clients call methods on the same object instance and the object maintains state between function calls use server activation.

    On the other hand, for client-activated objects the client manages the lifetime of the remote object by using a lease-based system provided for that purpose. If you use these object lifetime services, client applications will need to be implemented using .NET Remoting as well. For more information, see Object Activation and Lifetimes.

COM Interoperability

Your existing COM components represent valuable resources to your current and future applications. Likewise, you can use a COM client to create an instance of a public class in a .NET assembly and call the public members of that class. Each case uses the .NET Framework's COM interoperability features to enable this communication. For more information, see Interoperating with Unmanaged Code.

Note   COM+ SOAP services in Windows XP uses the .NET Remoting technology when you take an existing component and publish it as an XML Web service using Component Services. For more information, see SOAP Services.
  • You can use XML Web services created using ASP.NET, ATL Server and the SOAP Toolkit to expose existing COM components. Using the .NET Framework, you can expose COM components by first creating a managed component to access the COM component. You can then expose the managed component using an XML Web service created using ASP.NET or .NET Remoting. For more information, see Exposing COM Components to the .NET Framework and Consuming Unmanaged DLL Functions.

    Of course, you can use XML Web services created using ATL Server to readily expose COM components. For more information, see Providing XML Web Services.

  • It is possible to call COM components directly through COM Interop Services. When the .NET Remoting client object creates an instance of a COM object, a runtime callable wrapper (RCW) exposes the unmanaged object and acts as a proxy for it. To the .NET client, this wrapper appears to be just like any other managed class. The wrapper simply marshals calls between managed (.NET) and unmanaged (COM) code. Similarly, you can expose a .NET Remoting server object to classic COM clients. When a COM client creates an instance of the .NET object, a COM callable wrapper (CCW) exposes the object and acts as a proxy for it. It is important to note that both of these scenarios use Distributed COM (DCOM) for communication, which imposes additional configuration requirements. This interoperability is very handy in scenarios where there is a heterogeneous mix of COM and .NET components. For more information, see Interop Marshaling.

Summary

As outlined above, which programming model you choose depends upon the needs of your client application. To make an informed choice, you should first familiarize yourself with each programming model to fully understand each implementation and the associated pros and cons.

See Also

Choosing Tools and Technologies | XML Web Services in Managed Code | XML Web Services Created with ATL Server | .NET Remoting Overview | Choosing Communication Options in .NET

Show:
© 2014 Microsoft