A Potpourri of Additional Distributed APIs
Beyond XML web services, the Windows OS has historically supported a number of distributed-computing
APIs. By and large, these APIs were only useful if you were building in-house applications where each
machine was running Microsoft Windows. Unlike XML web services, these APIs preferred more limiting
wire protocols such as TCP and strongly typed data such as Win32 data types or .NET data types for
purposes of performance.
The .NET remoting API represented by the System.Runtime.Remoting namespaces shipped with the initial
release of the .NET platform. This API allows multiple computers to distribute objects, provided they are all
running applications under the .NET platform. Using XML-based configuration files, you can declaratively
define the underlying plumbing used by the client and the server software.
.NET remoting offers performance gains over XML web services as strongly typed data can be encoded in a
compact binary format. Consider the following comparison between .NET remoting (TCP bindings) and
XML web services (HTTP binding).
The Microsoft Message Queuing (MSMQ) API allows developers to build distributed systems that need to
ensure reliable delivery of message data on the network. As you know too well, in any distributed system
there is the risk that a network server is down, a database is offline, or connections are lost for mysterious
reasons. Furthermore, a number of applications need to be constructed in such a way that they hold message
data for delivery at a later time, known as queuing data. Using the System.Messaging namespace, .NET
programmers can hook into MSMQ and build software that communicates dependably with intermittently
connected applications.
The COM+ API (exposed to .NET programmers via System.EnterpriseServices) provides a number of out-of-
the-box services common to many distributed systems. Transaction management, object lifetime management,
pooling services, a role-based security system, a loosely coupled event model, and so on are all available.
A major benefit of COM+ is that these settings can be configured in a declarative manner using administrative
tools. Thus, if you wished to ensure an object was monitored under a transactional context or belonged to a
particular security role, you simply needed to select the correct check boxes.
Consider the following illustration of a typical COM+ installation. ‘Application Server’ is the machine (or
farm of machines) that host the COM+ runtime.
In addition to XML web services, .NET remoting, MSMQ, and COM+, you were also provided with the
following:
• Named Pipes: If you are building a distributed system involving a set of applications running on
the same physical machine, you can make use of the named pipes API via the System.IO.Pipes
namespace, which is new to .NET 3.5.
• Sockets and P2P: If you are building an application that requires absolute control over how
network access is obtained and maintained, sockets and P2P functionality can be achieved under
the .NET platform using the System.Net.Sockets and System.Net.PeerToPeer namespaces,
respectively.
Beyond XML web services, the Windows OS has historically supported a number of distributed-computing
APIs. By and large, these APIs were only useful if you were building in-house applications where each
machine was running Microsoft Windows. Unlike XML web services, these APIs preferred more limiting
wire protocols such as TCP and strongly typed data such as Win32 data types or .NET data types for
purposes of performance.
The .NET remoting API represented by the System.Runtime.Remoting namespaces shipped with the initial
release of the .NET platform. This API allows multiple computers to distribute objects, provided they are all
running applications under the .NET platform. Using XML-based configuration files, you can declaratively
define the underlying plumbing used by the client and the server software.
.NET remoting offers performance gains over XML web services as strongly typed data can be encoded in a
compact binary format. Consider the following comparison between .NET remoting (TCP bindings) and
XML web services (HTTP binding).
The Microsoft Message Queuing (MSMQ) API allows developers to build distributed systems that need to
ensure reliable delivery of message data on the network. As you know too well, in any distributed system
there is the risk that a network server is down, a database is offline, or connections are lost for mysterious
reasons. Furthermore, a number of applications need to be constructed in such a way that they hold message
data for delivery at a later time, known as queuing data. Using the System.Messaging namespace, .NET
programmers can hook into MSMQ and build software that communicates dependably with intermittently
connected applications.
The COM+ API (exposed to .NET programmers via System.EnterpriseServices) provides a number of out-of-
the-box services common to many distributed systems. Transaction management, object lifetime management,
pooling services, a role-based security system, a loosely coupled event model, and so on are all available.
A major benefit of COM+ is that these settings can be configured in a declarative manner using administrative
tools. Thus, if you wished to ensure an object was monitored under a transactional context or belonged to a
particular security role, you simply needed to select the correct check boxes.
Consider the following illustration of a typical COM+ installation. ‘Application Server’ is the machine (or
farm of machines) that host the COM+ runtime.
In addition to XML web services, .NET remoting, MSMQ, and COM+, you were also provided with the
following:
• Named Pipes: If you are building a distributed system involving a set of applications running on
the same physical machine, you can make use of the named pipes API via the System.IO.Pipes
namespace, which is new to .NET 3.5.
• Sockets and P2P: If you are building an application that requires absolute control over how
network access is obtained and maintained, sockets and P2P functionality can be achieved under
the .NET platform using the System.Net.Sockets and System.Net.PeerToPeer namespaces,
respectively.
A Potpourri of Additional Distributed APIs
Table of Contents
Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Courseware
Training Resources
Tutorials
|
Services