Evolution of Remoting

Evolution of Remoting

The scenarios presented thus far have only been possible due to the constant evolution of remoting frameworks. The implementation of large-scale business applications in a distributed manner has only been practicable after the technical problems have been taken care of by the frameworks. CORBA, COM+, and EJB started this process several years ago, and .NET Remoting simplifies this process even more.

To underscore how far remoting has evolved from its cumbersome beginnings, the following sections give you a brief history of the various remoting frameworks.

DCE/RPC

Distributed Computing Environment (DCE), designed by the Open Software Foundation (OSF) during the early 1990s, was created to provide a collection of tools and services that would allow easier development and administration of distributed applications. The DCE framework provides several base services such as Remote Procedure Calls (DCE/RPC), Security Services, Time Services, and so on.

Implementing DCE is quite a daunting task; the interfaces have to be specified in Interface Definition Language (IDL) and compiled to C headers, client proxies, and server stubs by an IDL compiler. When implementing the server, one has to link the binary with DCE/Threads, which are available for C/C++. The use of programming languages other than these is somewhat restricted due to the dependence on the underlying services, like DCE/Threads, with the result that one has to live with single-threaded servers when refraining from using C/C++.

DCE/RPC nevertheless is the foundation for many current higher-level protocols including DCOM and COM+. Several application-level protocols such as MS SQL Server, Exchange Server, Server Message Block (SMB), which is used for file and printer sharing, and Network File System (NFS) are also based on DCE/RPC.

CORBA

Designed by the Object Management Group (OMG), an international consortium of about 800 companies, CORBA's aim is to be the middleware of choice for heterogeneous systems. OMG's CORBA, which stands for Common Object Request Broker Architecture, is only a collection of standards; the implementation of object request brokers (ORBs) is done by various third parties. Because parts of the standard are optional and the vendors of ORBs are allowed to include additional features that are not in the specifications, the world has ended up with some incompatible request brokers. As a result, an application developed to make use of one vendor's features could not easily be ported to another ORB. When you buy a CORBA-based program or component, you just can't be sure if it will integrate with your CORBA applications, which probably were developed for a different request broker.

Aside from this potential problem, CORBA also has quite a steep learning curve. The standard reads like a complete wish list of everything that's possible with remoted components—sometimes it simply is too much for the "standard business." You'll probably end up reading documents for days or weeks before your first request is ever sent to a server object.

Nevertheless, when you have managed to implement your first CORBA application, you'll be able to integrate a lot of programming languages and platforms. There are even layers for COM or EJB integration, and apart from SOAP, CORBA is the only true multiplatform, multiprogramming language environment for distributed applications.

DCOM

Distributed Component Object Model (DCOM) is an "extension" that fits in the Component Object Model (COM) architecture, which is a binary interoperability standard that allows for component-oriented application development. You'll usually come in contact with COM when using ActiveX controls or ActiveX DLLs.

DCOM allows the distribution of those components among different computers. Scalability, manageability, and its use in WANs pose several issues that need to be addressed. DCOM uses a pinging process to manage the object's lifetimes; all clients that use a certain object will send messages after certain intervals. When a a server receives these messages it knows that the client is still alive; otherwise it will destroy the object.

Additionally, reliance on the binary DCE/RPC protocol poses the need for direct TCP connections between the client and its server. Use of HTTP proxies is not possible. DCOM is available for Microsoft Windows and for some UNIX dialects (ported by the German Software AG).

MTS/COM+

COM+, formerly Microsoft Transaction Server (MTS), was Microsoft's first serious attempt to reach into the enterprise application domain. It not only serves as a remoting platform, but also provides transaction, security, scalability, and deployment services. COM+ components can even be used via Microsoft Message Queue Server to provide asynchronous execution of methods.

Despite its advantages, COM+ does not yet support the automatic marshalling of objects to pass them by value between applications; instead you have to pass your data structures using ADO recordsets or other means of serialization. Other disadvantages that keep people from using COM+ are the somewhat difficult configuration and deployment, which complicates its use for real-world applications.

Java RMI

Traditional Java Remote Method Invocation (Java RMI) uses a manual proxy/stub compilation cycle. In contrast to DCE/RPC and DCOM, the interfaces are not written in an abstract IDL but in Java. This is possible due to Java being the only language for which the implementation of RMI is possible.

This limitation locked RMI out of the game of enterprise application integration. Even though all relevant platforms support a Java Virtual Machine, integration with legacy applications is not easily done.

Java EJB

Enterprise Java Beans (EJB) was Sun's answer to Microsoft's COM+. Unlike CORBA, which is only a standard, EJB comes with a reference implementation. This allows developers to check if their products run in any standard-complying EJB container. EJB has been widely accepted by the industry, and there are several container implementations ranging from free open source to commercial implementations by well-known middleware vendors.

One problem with EJB is that even though a reference implementation exists, most vendors add features to their application servers. When a developer writes a component that uses one of those features, the application will not run on another vendor's EJB container.

Former versions of EJB have been limited to the Java platform because of their internal reliance on RMI. The current version allows the use of IIOP, which is the same transfer protocol CORBA uses, and third parties already provide commercial COM/EJB bridges.

Web Services/SOAP/XML-RPC

Web Services provided the first easy to understand and implement solution to true cross-platform and cross-language interoperability. Web Services technically are stateless calls to remote components via HTTP POST with a payload encoded in some XML format.

Two different XML encodings are currently in major use: XML-RPC and SOAP. XML-RPC can be described as a poor man's SOAP. It defines a very lightweight protocol with a specification size of about five printed pages. Implementations are already available for a lot of programming environments, ranging from AppleScript to C/C++, COM, Java, Perl, PHP, Python, Tcl, and Zope—and of course there's also an implementation for .NET.

SOAP, or Simple Object Access Protocol, defines a much richer set of services; the specification covers not only remote procedure calls, but also the Web Services Description Language (WSDL) and Universal Description, Discovery, and Integration (UDDI). WSDL is SOAP's interface definition language, and UDDI serves as a directory service for the discovery of Web Services. Those additional protocols and specifications are also based on XML, which allows all SOAP features to be implemented on a lot of platforms.

The specifications and white papers for SOAP, WSDL, UDDI, and corresponding technologies cover several hundred pages, and you can safely assume that this document will grow further when topics like routing and transactions are addressed. Fortunately for .NET developers, the .NET platform takes care of all issues regarding SOAP.

.NET Remoting

At first look, .NET Remoting is to Web Services what ASP has been to CGI programming. It takes care of a lot of issues for you: contrary to Web Services, for example, .NET Remoting enables you to work with stateful objects. This single fact allows it to be the base of tomorrow's distributed applications.

In addition to the management of stateful objects, .NET Remoting gives you a flexible and extensible framework that allows for different transfer mechanisms (HTTP and TCP are supported by default), encodings (SOAP and binary come with the framework), and security settings (IIS Security and SSL come out of the box).

With these options, and the possibility of extending all of them or providing completely new implementations, .NET Remoting is well suited to today's distributed applications. You can choose between HTTP/SOAP for the Internet or TCP/binary for LAN applications by literally changing a single line in a configuration file.

Interface description does not have to be manually coded in any way, even though it's supported if you like to design your applications this way. Instead, metadata can be extracted from running servers, where the WSDL is automatically generated, or from any .NET assembly.

本文地址：http://com.8s8s.com/it/it41517.htm