Advanced .NET Remoting

INGO RAMMER

252FM.qxp 3/11/02 2:52 PM Page i

Advanced .NET RemotingCopyright ©2002 by Ingo Rammer

All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any informationstorage or retrieval system, without the prior written permission of the copyright owner and the publisher.

ISBN (pbk): 1-59059-025-2Printed and bound in the United States of America 12345678910Trademarked names may appear in this book. Rather than use a trademark symbol with everyoccurrence of a trademarked name, we use the names only in an editorial fashion and to thebenefit of the trademark owner, with no intention of infringement of the trademark.Technical Reviewer: Kent SharkeyEditorial Directors: Dan Appleman, Peter Blackburn, Gary Cornell, Jason Gilmore, KarenWatterson, John ZukowskiManaging Editor: Grace WongProject Manager: Alexa StuartCopy Editor: Ami KnoxProduction Editor: Julianna Scott FeinCompositor and Illustrator: Impressions Book and Journal Services, Inc.Indexer: Valerie Haynes PerryCover Designer: Tom DebolskiMarketing Manager: Stephanie Rodriguez

Distributed to the book trade in the United States by Springer-Verlag New York, Inc., 175 FifthAvenue, New York, NY, 10010 and outside the United States by Springer-Verlag GmbH & Co. KG,Tiergartenstr. 17, 69112 Heidelberg, Germany.In the United States, phone 1-800-SPRINGER, Email orders@springer-ny.com, or visithttp://www.springer-ny.com.Outside the United States, fax +49 6221 345229, Email orders@springer.de, or visithttp://www.springer.de.

For information on translations, please contact Apress directly at 2560 Ninth Street, Suite 219,Berkeley, CA 94710.Email info@apress.com, or visit http://www.apress.com.The information in this book is distributed on an “as is” basis, without warranty. Although everyprecaution has been taken in the preparation of this work, neither the author nor Apress shallhave any liability to any person or entity with respect to any loss or damage caused or alleged tobe caused directly or indirectly by the information contained in this work.The source code for this book is available to readers at http://www.apress.com in the Downloads section.

252FM.qxp 3/11/02 2:52 PM Page ii

CHAPTER 1

Introductionto Remoting

THIS CHAPTER GIVES YOU a short introduction to the world of distributed applicationdevelopment and its respective technologies. Here you get a chance to examinesome scenarios in which .NET Remoting can be employed and learn some histor-ical background on the progress and development of various remotingframeworks during the last ten years.

What Is Remoting?

Remoting is the process of programs or components interacting across certainboundaries. These contexts will normally resemble either different processes ormachines.1 In the .NET Framework, this technology provides the foundation fordistributed applications—it simply replaces DCOM.

Remoting implementations generally distinguish between remote objects andmobile objects. The former provides the ability to execute methods on remoteservers, passing parameters and receiving return values. The remote object willalways “stay” at the server, and only a reference to it will be passed aroundamong other machines.

When mobile objects pass a context boundary, they are serialized (mar-shaled) into a general representation—either a binary or a human readableformat like XML—and then deserialized in the other context involved in the pro-cess. Server and client both hold copies of the same object. Methods executed onthose copies of the object will always be carried out in the local context, and nomessage will travel back to the machine from which the object originated. In fact,after serialization and deserialization, the copied objects are indistinguishablefrom regular local objects, and there is also no distinction between a serverobject and a client object.

1

1 .NET extends this concept to include the ability to define additional contexts within onerunning application. Object accesses crossing these boundaries will pass the .NETRemoting Framework as well.

252ch01.qxp 3/11/02 2:52 PM Page 1

Scenarios for .NET Remoting

At the beginning of the client/server era, remoting was mostly used for accessinga server’s resources. Every database or file server is an implementation of sometechnique that allows code to be executed remotely. Programming these olderframeworks was so difficult a task that few products except for these server-sidecore services implemented remoting.

Nowadays the building of distributed applications has gotten a lot easier sothat it’s quite feasible to distribute business applications among various machinesto improve performance, scalability, and maintainability.

Centralized Business Logic

One of the key scenarios for implementing remoting is the concentration of busi-ness logic on one or more central servers. This considerably simplifies themaintainability and operability of large-scale applications. Changes in businesslogic do not entail your having to roll out an application to your organization’s10,000 worldwide users—you just have to update one single server.

When this centralized business logic is shared among different applications,this labor-saving effect multiplies considerably; instead of patching several appli-cations, you just have to change the server’s implementation.

Physical Separation of Layers

The security of a company’s vital databases represents a common concern in this time of Web-enabled businesses. The general recommendation is againstdirectly connecting from the Web server to the database because this setupwould allow attackers easy access to critical data after they have seized control of the Web server.

Instead of this direct connection, an intermediate application server is intro-duced. This server is placed in a so-called demilitarized zone (DMZ), locatedbetween two firewalls. Firewall #1 only allows connections from the Web server to the app server, and Firewall #2 only allows connections from the app server tothe databases.

Because the application server doesn’t allow the execution of arbitrary SQLstatements, yet provides object-oriented or function-based access to businesslogic, a security compromise of the Web server (which can only talk to the appserver) is noncritical to a company’s operations.

2

Chapter 1

252ch01.qxp 3/11/02 2:52 PM Page 2

Accessing Other Platforms

In today’s mid- to large-scale enterprises, you will normally encounter a hetero-geneous combination of different platforms, frameworks, and programminglanguages. It is not uncommon to find that a bunch of tools have been imple-mented: Active Server Pages (ASP), Java Server Pages (JSP), PHP, or ColdFusionfor Web applications, Visual Basic or Java for in-house applications, C++ forserver-side batch jobs, scripting languages for customizing CRM systems, and so on.

Integrating these systems can be a daunting task for system architects.Remoting architectures like CORBA, SOAP, and .NET Remoting are an absolutenecessity in large-scale enterprise application integration. (CORBA and SOAP areintroduced and compared later in this chapter.)

Third-Party Access

Opening systems to third parties in a business-to-business environment is quitecommon nowadays. This process started with hard-to-implement EDI docu-ments, transferred via proprietary networks, and is recently opening up forsmaller companies due to the possibility of using SOAP, which is fairly easier to implement.

Order-entry applications, which allow your business partners to directlyplace orders from one ERP system to the other, constitute one example of anapplication utilizing this kind of remoting. More sophisticated applications arestarting to be developed—address verification, customer creditworthiness rat-ings, and online price-comparison systems are just the beginning.

Evolution of Remoting

The scenarios presented thus far have only been possible due to the constantevolution of remoting frameworks. The implementation of large-scale businessapplications in a distributed manner has only been practicable after the techni-cal problems have been taken care of by the frameworks. CORBA, COM+, and EJBstarted this process several years ago, and .NET Remoting simplifies this processeven 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.

3

Introduction to Remoting

252ch01.qxp 3/11/02 2:52 PM Page 3

DCE/RPC

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

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

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

CORBA

Designed by the Object Management Group (OMG), an international consortiumof about 800 companies, CORBA’s aim is to be the middleware of choice for het-erogeneous systems. OMG’s CORBA, which stands for Common Object RequestBroker Architecture, is only a collection of standards; the implementation ofobject 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 addi-tional features that are not in the specifications, the world has ended up withsome incompatible request brokers. As a result, an application developed tomake 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 itwill integrate with your CORBA applications, which probably were developed fora different request broker.

Aside from this potential problem, CORBA also has quite a steep learningcurve. The standard reads like a complete wish list of everything that’s possiblewith remoted components—sometimes it simply is too much for the “standardbusiness.” You’ll probably end up reading documents for days or weeks beforeyour first request is ever sent to a server object.

4

Chapter 1

252ch01.qxp 3/11/02 2:52 PM Page 4

Nevertheless, when you have managed to implement your first CORBA appli-cation, 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 isthe only true multiplatform, multiprogramming language environment for dis-tributed applications.

DCOM

Distributed Component Object Model (DCOM) is an “extension” that fits in theComponent Object Model (COM) architecture, which is a binary interoperabilitystandard that allows for component-oriented application development. You’llusually come in contact with COM when using ActiveX controls or ActiveX DLLs.

DCOM allows the distribution of those components among different com-puters. Scalability, manageability, and its use in WANs pose several issues thatneed 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 certainintervals. When a a server receives these messages it knows that the client is stillalive; otherwise it will destroy the object.

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

MTS/COM+

COM+, formerly Microsoft Transaction Server (MTS), was Microsoft’s first seriousattempt to reach into the enterprise application domain. It not only serves asa remoting platform, but also provides transaction, security, scalability, anddeployment services. COM+ components can even be used via MicrosoftMessage Queue Server to provide asynchronous execution of methods.

Despite its advantages, COM+ does not yet support the automatic mar-shalling of objects to pass them by value between applications; instead you haveto pass your data structures using ADO recordsets or other means of seriali-zation. Other disadvantages that keep people from using COM+ are thesomewhat difficult configuration and deployment, which complicates its use forreal-world applications.

5

Introduction to Remoting

252ch01.qxp 3/11/02 2:52 PM Page 5

Java RMI

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

This limitation locked RMI out of the game of enterprise application inte-gration. 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+. UnlikeCORBA, which is only a standard, EJB comes with a reference implementation.This allows developers to check if their products run in any standard-complyingEJB container. EJB has been widely accepted by the industry, and there are sev-eral container implementations ranging from free open source to commercialimplementations 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 writesa component that uses one of those features, the application will not run onanother vendor’s EJB container.

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

Web Services/SOAP/XML-RPC

Web Services provided the first easy to understand and implement solution totrue cross-platform and cross-language interoperability. Web Services technicallyare stateless calls to remote components via HTTP POST with a payload encodedin some XML format.

Two different XML encodings are currently in major use: XML-RPC andSOAP. 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, andZope—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

6

Chapter 1

252ch01.qxp 3/11/02 2:52 PM Page 6

Services Description Language (WSDL) and Universal Description, Discovery, andIntegration (UDDI). WSDL is SOAP’s interface definition language, and UDDIserves as a directory service for the discovery of Web Services. Those additionalprotocols and specifications are also based on XML, which allows all SOAP fea-tures to be implemented on a lot of platforms.

The specifications and white papers for SOAP, WSDL, UDDI, and corre-sponding technologies cover several hundred pages, and you can safely assumethat this document will grow further when topics like routing and transactionsare addressed. Fortunately for .NET developers, the .NET platform takes care ofall issues regarding SOAP.

.NET Remoting

At first look, .NET Remoting is to Web Services what ASP has been to CGI pro-gramming. It takes care of a lot of issues for you: contrary to Web Services, forexample, .NET Remoting enables you to work with stateful objects. This singlefact allows it to be the base of tomorrow’s distributed applications.

In addition to the management of stateful objects, .NET Remoting gives youa flexible and extensible framework that allows for different transfer mechanisms(HTTP and TCP are supported by default), encodings (SOAP and binary comewith 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 providingcompletely new implementations, .NET Remoting is well suited to today’s dis-tributed applications. You can choose between HTTP/SOAP for the Internet orTCP/binary for LAN applications by literally changing a single line in a config-uration file.

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

Summary

This chapter provided a short introduction to the world of distributed appli-cation development and the respective technologies. You now know about thevarious scenarios in which .NET Remoting can be applied and understand how itdiffers from other distributed application protocols and techniques.

7

Introduction to Remoting

252ch01.qxp 3/11/02 2:52 PM Page 7

Index

393

NUMBERS2xx-5xx SMTP response code classes,

explanations of, 318

Aabstract base classes

creating in shared assemblies, 78role in sample multiserver configu-

ration, 70, 72<activated> property, role in con-

figuration files, 107–108, 110

Activator.GetObject() callcalling for nonwrapped proxy meta-

data, 84–85examining in MarshalByRefObject in

Singleton mode, 21using with client in factory design

pattern, 46–47algorithms for encryption,

producing with keygenerators, 269–271

anonymous use, deploying server applications for, 120–123

APOP command, RFC for, 320architecture of .NET Remoting,

illustration of, 10assemblies

displaying strong names for, 166

types of, 15assemblyBinding entry in con-

figuration files, resolvingassembly versions with,173–174

AssemblyVersion attribute, changing forversioned SAOs, 169

asynchronous callsexample of, 58–60explanation of, 52first stage of, 227role in compression sinks, 254using, 179–185

asynchronous delegatesadvisory about implementation of,

180–181

advisory about using events with,187, 190

declaring for asynchronous calls,58–59

example of, 60–61explanation of, 58invoking without [OneWay] methods,

197–198managing with .NET Remoting mes-

sages, 340–341shipping destination assemblies

to callers for, 191–196

using for asynchronous calls, 179

using with new clients, 61–63

using with SoapSuds-generatedDLLs, 180–181

using with wrapper methods,184–185

asynchronous IClientChannelSink pro-cessing, performing, 224–226

asynchronous IMessageSink processing, performing,222–224

asynchronous messaging, performing,222

asynchronous one-way calls, exampleof, 63–67

asynchronous requests, generating,226–230

asynchronous responses, handling,230–233

AsyncProcessMessage() function, imple-menting, 287

AsyncProcessResponse() functionrole in creating sinks for clients,

352–354role in server sinks, 364sample implementation for server-

side asynchronousprocessing, 235

using with compression sinks,257–258, 264–265

252indx.qxp 3/11/02 4:35 PM Page 393

AsyncResponseHandler class, imple-menting for client sinks,354–355

attributesfor <channels> tag in configuration

files, 101for <lifetime> tag in configuration

files, 99for HTTP channels, 101

authenticated use, deploying for, 125–133authentication entries, checking for

URLs of current messages,302–305

authentication methods, configuring foranonymous-use deployments,120–121

Bbase objects, role in .NET Remoting, 12Base64, RFC for, 321BaseRemoteObject, role in sample mul-

tiserver configuration, 73Basic Authentication scheme

advisory about, 125enabling, 132explanation of, 131

BeginInvoke() method, using with dele-gates, 179

binary encoding via HTTP, using withconfiguration files, 105

BinaryFormatter, introduction to, 211BinaryServerFormatterSink, explanation

of, 219bindTo attribute, role in HTTP channels

for configuration files, 102BroadcastEventWrapper, using with

shared assemblies, 192–193BroadcastMessage() method,invoking

for refactored event handling,194–195

business logicchecking constraints for, 391documenting at metadata level, 378rejecting constraints for, 390

business rules for servers, implementingfor MarshalByRefObject inSingleton mode, 23–24

byte arrays, encoding with Base 64, 321ByValue objects

explanation of, 14using, 27–28

CC# code

generating with SoapSuds, 94for versioning client-activated

objects, 172–173

calls, intercepting withContextAttributes, 379

CAOs (client-activated objects)enabling for server-side channels, 360explanation of, 38implementing different lifetimes for,

49–50and ObjRef object, 204, 206–207versus SAOs, 206specifying in server-side configu-

ration files, 107–108using <client> property with, 109using with server-side sponsors, 160

chains of providerscreating sinks from, 241role in client-side sinks, 239

chains of sinks, defining in configu-ration files, 237–238

channelsexamining basic implementation of,

347–348registering for clients in

MarshalByRefObject inSingleton mode, 20

returning base URLs for, 359wrapping, 366–369

<channels> tag, using with configu-ration files, 100–102

character encoding, essentials of, 321classes

locating, 137client-activated objects, versioning,

172–174client assemblies, explanation of, 15client channels, implementing, 346–350client-side keepalive thread, starting, 160client-side messaging. See also mes-

sages, server-side messagingexamples of, 214–216versus server-side messaging, 217

client-side PriorityEmitterSink code, 289–292

client-side sink providers, creating,258–260

client-side sinks. See also server-sidesinks, sinks

configuring for encryption, 281creating, 239–243diagram with compression sink, 250implementing for compression

sinks, 251–255versus server-side sinks, 257

client-side sponsorsadvisory about, 149, 155registering to avoid premature termi-

nation of objects, 154–155using, 150–155, 150–155

394

Index

252indx.qxp 3/11/02 4:35 PM Page 394

client-side synchronous message han-dling, diagram of, 205

<client> property, role in configurationfiles, 108–109

ClientChannelSinkStackappearance before call to SOAP

formatter, 233appearance before first sink is

called, 232contents in asynchronous

requests, 229clientConnectionLimit attribute

role in HTTP channels for configu-ration files, 101

using with delegates, 179ClientContextTerminatorSink, expla-

nation of, 215ClientProviders and ServerProviders

properties, role in configu-ration files, 102–106

clientsaccessing client-activated objects

with, 41advisory about distributing SAO

implementations to, 44advisory when using events with, 187building for versioned SAOs, 167calling timed-out CAO with, 50–51creating for synchronous calls, 55–57creating providers for, 350–355creating sinks for, 350–355developing for versioned SAOs,

170–172enabling connections to assemblies,

170example for SingleCall SAO, 32implementing for asynchronous one-

way calls, 64–67implementing for

MarshalByRefObject inSingleton mode, 20–22, 24–25

implementing for nonwrapped proxymetadata, 84–86

implementing for SoapSuds-generated metadata, 81–82

implementing with asynchronouscalls, 61–63

pinging server-side sponsors with,157–158

role in configuration files, 96–98role in sample multiserver configu-

ration, 70–71using binary encoding via HTTP

with, 105using factory design pattern with,

46–47using wrapper functions with, 184

command-line operations, advisoryabout, 40, 163

compressed streams, creating class for,253–254

compression library, Web site for, 251compression of request streams, verify-

ing, 263compression sinks

creating, 250–251extending, 263–268implementing client-side sinks for,

251–255configuration filenames, defaults for, 89configuration files

benefits of, 87changing after using SoapSuds -gc

with SAO, 182defining chain of sinks in, 237–238effect of typos on, 97example for lifetime management,

147–148placing sinks in, 261–262role of <client> property in, 108–109role of versioning behavior in,

104–105using, 88–89, 95–98using <activated> property with,

107–108, 110using <channels> tag with, 100–102using <lifetime> tag with, 99using <service> property with, 106using <wellknown> property with,

106–107, 109–110using binary encoding via HTTP

with, 105using formatters and providers

with, 103–104using HTTP channel with, 101–102using with Windows services, 115

configuration options, standards for, 99–102

console applications, deploying servers as, 111

ConstructionCall messages versusMethodCall, 207

content replies, role in POP3 con-versions, 320

ContextAttribute, intercepting callswith, 379

ContextBoundObject class code,383–384

contextscreating, 378–387explanation of, 246

CORBA (Common Object RequestBroker Architecture) remotingframework, evolution of, 4–5

395

Index

252indx.qxp 3/11/02 4:35 PM Page 395

396

Index

core modules, preparing for transport-channel examples, 372

CreateMessageSink()calling on client-side channels, 242role in implementing client

channels, 349CreateSink() method, implementing,

258–260CrossContextChannel, explanation

of, 220csc.exe command-line compiler, advi-

sory about, 94custom proxies, using, 308–315Customer Class, creating for

MarshalByRefObject inSingleton mode, 16–17

Customer data, validating, 22–25

DD units for <lifetime> tag attributes,

explanation of, 99, 137DATA code, role in SMTP, 319data objects, defining for

MarshalByRefObject inSingleton mode, 16–17

data serialization, role in .NETRemoting, 13

DateTime instance variables, benefits ofadding to server-side spon-sors, 156

DCE/RPC (Distributed ComputingEnvironment)/RemoteProcedure Calls remotingframework, evolution of, 4

DCOM (Distributed Component ObjectModel) remoting framework,evolution of, 5

DELE message_number command, rolein POP3, 321

delegatesadvisory about implementation of,

180–181advisory about using events with,

187, 190declaring for asynchronous calls,

58–59example of, 60–61explanation of, 58invoking without [OneWay] methods,

197–198managing with .NET Remoting mes-

sages, 340–341shipping destination assemblies to

callers for, 191–196using for asynchronous calls, 179using with new clients, 61–63

using with SoapSuds-generatedDLLs, 180–181

using with wrapper methods,184–185

DeleteMessage() method, using withPOP3, 330

dictionary keys for sample method callmessage, list of, 209

DispatchChannelSink, explanation of,220

displayName attributerole in <channels> tag for configu-

ration files, 101using with <client> property for

configuration files, 109using with <wellknown> property for

configuration files, 107,109–110

distributed reference counting, expla-nation of, 135

.dll extension, advisory regardingconfiguration files, 97

DLLs (dynamic link libraries), using withSAOs, 29

DomainSpecificRemotingData, using withServerContextTerminatorSin,221

dynamic sinksfunctionality of, 215using, 246–247

E-ERR messages, using with POP3, 320e-mail addresses, parsing for incoming

requests, 345e-mail headers, creating, 322–323e-mail, types of, 341ease of implementation, advantage of

.NET remoting, 9–10encrypted HTTP traffic, displaying TCP

trace of, 285encrypted use, deploying for, 133–134encryption helpers, creating, 272–274EncryptionClientSink versus

EncryptionServerSink,274–280

EncryptionClientSinkProvider code,282–283

EncryptionServerSinkProvider code,283–285

EndInvoke() method in asynchronouscalls

advisory about, 60, 63using with delegates, 179

event handling, refactoring, 191–196

252indx.qxp 3/11/02 4:35 PM Page 396

EventInitiator, callingBroadcastMessage() methodwith, 195

eventsensuring optimal performance with,

198explanation of, 185–187problems with, 187–191

exception handling, performing duringIClientChannelSink pro-cessing, 233

.exe extension, advisory regardingconfiguration files, 97

expired objects, calling methods for,150–155

ExtendedMBRObject, role in lifetimemanagement example,145–148, 158

extensible architecture of .NET remot-ing, advantage of, 10–11

Ffactory design pattern, using, 42–48formatters

role in configuration files, 103–104role in messages, 207serializing Message objects through,

211–212Freeze() method, role in

IContextProperty interface,380

GGAC (global assembly cache)

contents after installing assembliesfor versioned SAOs, 170

manipulating contents of, 164role in exposing MarshalByRefObject

in Singleton mode, 17, 19general assemblies

explanation of, 15group memberships, verifying for users,

128–130

HH units for <lifetime> tag attributes,

explanation of, 99, 137HashTables in SMTPHelper class, types

of, 336–337HELO localhost code, role in SMTP, 319HTTP Basic Authentication scheme

advisory about, 125enabling, 132explanation of, 131

HTTP channelsattributes for, 101

creating for MarshalByRefObject inSingleton mode, 18, 20

specifying for port 1234, 102wrapping channels with, 366

HTTP headers for SOAP remoting call,example of, 212–213

HTTP requests, compressing, 268HTTP responses, compressing, 268HTTP/SOAP connection, example of TCP

trace without using sinks, 262HttpClientChannel, functionality of, 216HttpServerChannel

default sink chain for, 244explanation of, 218

HttpServerTransportSink, explanationof, 218

IIChannel and IChannelReceiver code,

role in implementing serverchannels, 356–357

IChannel and IChannelSender code,347–349

IChannel, implementing server methodsand properties for, 359

IChannel with populated sink providers,example of, 239–240

IChannelSinkBase andIServerChannelSink code, 361

IClientChannelSink interface for mes-sage links

advisory about, 307example of, 210–211performing exception handling for,

233role in implementing compression

sinks, 251–253IContextProperty interface code, imple-

menting, 380–381IContributeDynamicSink property, dis-

playing, 246IContributeObjectSink interface code,

380ICustomerManager

extending for MarshalByRefObject inSingleton mode, 22–23

implementing forMarshalByRefObject inSingleton mode, 17–18

IDE (integrated development environ-ment), trying to startWindows services from, 115

IDictionary, role in server-side sinks, 244IDynamicProperty interface

displaying, 246registering with current context, 247

397

Index

252indx.qxp 3/11/02 4:35 PM Page 397

398

Index

IIS (Internet Information Server)deploying server applications with,

117–123using authentication within, 126–127,

130ILease interface

adding sponsors with, 150location of, 136

IMessage, advisory about changing con-tent in IClientChannelSink,286

IMessageSink interfacechecking parameters with, 387–391connecting to TransparentProxy, 243example of, 209–211role in server-side asynchronous pro-

cessing, 233–235includeVersions attribute for formatters

and providers in configu-ration files, using, 104–105

InfinitelyLivingSingleton, calling in life-time example, 144

InitializeLifetimeService() method, over-riding, 51–52, 138–139

InitialLeaseTime property, explanationof, 136

installutil.exeinstalling Windows services with, 115uninstalling Windows services with,

117interface definitions for .NET Remoting,

explanation of, 10–13invocation, types of, 52IPrincipal interface, verifying group

memberships for users with,128–130

ISerializable interface, examining, 176IServerChannelSink interface

displaying, 218role in compression sinks, 255–257role in server-side asynchronous pro-

cessing, 233–235ISponsor interface, implementing,

149–150IV (initialization vectors), using with

symmetric encryption, 272

JJava EJB (Enterprise Java Beans) remot-

ing framework, evolution of, 6Java RMI (Remote Method Invocation)

remoting framework, evo-lution of, 6

KKeepAlive() method, calling for server-

side sponsors, 161–162

key pairsadvisory about, 163generating for assemblies, 163

KeyGenerator.exe, role in encryptingnetwork traffic, 271

LlastKeepAlive, comparing for server-side

sponsors, 158lease-based object lifetime service,

explanation of, 48–50, 135. Seealso lifetime management

Lease class, location of, 136lease times

changing defaults for, 137–138changing on per-class basis, 138–139

LeaseManageradvisory about calling server-side

sponsors from, 156, 158role in lifetime management,

135–136, 137leaseManagerPollTime attribute, role in

<lifetime> tag for config-uration files, 99

leases, understanding, 136LeaseSink, explanation of, 221leaseTime attribute, role in <lifetime>

tag for configuration files, 99lifetime management, 13. See also lease

entriesexample of, 48–52, 139–144extending example of, 145–148introduction to, 135–136for Singletons, 33

<lifetime> tag, using with configurationfiles, 99

LifetimeService, getting for objects, 150LIST command, role in POP3, 321listen attribute, role in HTTP channels

for configuration files, 102listening clients

broadcasting messages to, 194–195role in refactored event handling,

193–194Locals window, locating ObjRef in, 207

MM units for <lifetime> tag attributes,

explanation of, 99, 137machineName attribute, role in HTTP

channels for configurationfiles, 102

MAIL FROM code, role in SMTP, 319MarshalByRefObjects

defining data object for (in Singletonmode), 16–17

defining remote interface for, 15–16

252indx.qxp 3/11/02 4:35 PM Page 398

executing remote method calls onserver side with, 14

exposing in Singleton mode, 15–22functionality of, 28implementing server for, 17–19refactoring event handling with,

191–196role in basic lifetime example,

139–144role in multiserver configuration, 68

marshalling objects by value, expla-nation of, 27

Mercury/31 e-mail server, downloading,371

Mercury core configuration, changingto, 372

Message objects, serializing through formatters, 211–212

message sinksexamining, 209–211role in .NET Remoting Framework

layers, 103messages. See also client-side messag-

ing, server-side messagingcontents of, 208–209creating, 203–204moving through transport channels,

212–214understanding role of, 207–209

metadataadvisory regarding configuration

files, 89–95extracting with SoapSuds

command, 92metadata-assembly generation, role in

.NET Remoting, 12metadata level, working at, 377–378MethodCall messages

versus ConstructionCall, 207partial definition of, 208–209

methodscalling for expired objects, 150–155calling on remote objects, 52executing asynchronously, 179

MMC (Microsoft Management Console)creating groups and assigning users

with, 129creating virtual roots with, 119

mobile objects versus remote objects, 1mode attribute, using with <wellknown>

property, 107MS units for <lifetime> tag attributes,

explanation of, 99–100, 137MTS/COM+ (Microsoft Transaction

Server)/Component ObjectModel) remoting framework,evolution of, 5

MulticastDelegate, basing server-sideevents on, 194

multiserver configurationexample of, 69–77fundamentals of, 68

multiserver/multiclient management,performing with .NETRemoting, 14

Nname attribute, role in HTTP channels

for configuration files, 101name parameter

for SMTPClientChannel, 346for SMTPServerChannel, 356

nested objects, using with ISerializable,177

.NET console applications, deployingservers a, 111

.NET Remotingadvantages of, 9–14binding to custom transfer

protocols, 321ease of implementation of, 9–10extensible architecture of, 10–11five elements of, 201–202functionality of, 7handling reply messages with,

341–343handling responses with, 340interface definitions for, 11–12managing object encoding/decoding

with, 13mapping POP3Msg objects to,

343–344performing lifetime management

with, 13performing multiserver/multiclient

management with, 14role generated metadata assembly

in, 12role of base objects in, 12role of message sinks in, 103role of shared assembly in, 11–12role of shared interfaces in, 12scenarios for, 2serialization of data in, 13

.NET Remoting connectionshandling reply messages with,

341–342handling responses for, 340making, 336–345role of asynchronous delegates in,

340–341network traffic, encrypting, 269new operator, using with configuration

files, 89

399

Index

252indx.qxp 3/11/02 4:35 PM Page 399

400

Index

nonwrapped proxy metadata, generat-ing, 84–86

O+OK messages, using with POP3,

320–321object encoding/decoding, manage-

ment of, 13objects

registering as Singletons, 33–34serializing their state, 27–28types of, 14

objectUri attribute, using with <well-known> property, 107

ObjRef objectexplanation of, 14functionality of, 204, 206–207role in multiserver configuration, 68

one-way asynchronous calls, exampleof, 63–67

one-way relaxed versioning schema,enabling, 175

[OneWay] attribute, removing fromasynchronous one-way calls,66

[OneWay] events, advisory about,196–198

ORBs (object request brokers), role inCORBA, 4

organization names, establishing char-acter limitations for, 376–377

Organization object, first version of,375–376

PPASS password code, role in POP3, 320playback attacks, explanation of, 131POP (Post Office Protocol)

encapsulating for channel source,325–327

RFC for, 318POP3

checking for new mail with, 331–333using DeleteMessage() method

with, 330using Disconnect() method with,

330–331using GetMessage() method with,

328–330using MessageCount property with,

328using SendCommand() method with,

327–328port 1234, configuring HTTP channel

on, 18, 95, 102, 244port 1235, opening HTTP channel on,

74–75

port attribute, role in <channels> tag forconfiguration files, 101

port numbersadvisory when running two servers

on one machine, 75specifying for server applications,

100–102port= attributes, creating in channels of

configuration files, 150–151priority attribute, role in HTTP channels

for configuration files, 101ProcessMessage() function

role in creating sinks for clients,352–353

sample implementation for server-side asynchronousprocessing, 235

using with compression sinks,257–258, 264–265

properties, setting on per-host basis,299–301

protocol considerations for transportchannels, 317–323

provider chainscreating sinks from, 241role in client-side sinks, 239

provider chains, role in client-side sinks,239

providerscreating for clients, 350–355creating for encryption, 280–285role in configuration files, 103–104

proxiescreating, 202–203customizing, 308–315role in .NET Remoting architecture,

202proxy assemblies, role in versioning

client-activated objects,172–173

proxy objectsdefault combination of, 308role in MarshalByRefObject in

Singleton mode, 20role in remoting applications, 14

proxyName attribute, role in HTTPchannels for configurationfiles, 101

proxyPort attribute, role in HTTPchannels for configurationfiles, 101

published objects, example of, 36–37

QQUIT command

role in POP3, 321, 330–331role in SMTP, 319

252indx.qxp 3/11/02 4:35 PM Page 400

RRCPT TO: <e-mail address> command,

role in SMTP, 319RealProxy, extending, 309

role in .NET Remoting architecture,203–204

ref attributefor formatters and providers in

configuration files, 103role in <channels> tag for config-

uration files, 101reference counting, explanation of, 135RegisterServer() method, role in .NET

Remoting connections, 344rejectRemoteRequests attribute, role in

HTTP channels for config-uration files, 102

remote components, hosting withWindows services, 113–114

remote events, troubleshooting, 195–196remote interface, defining for

MarshalByRefObject inSingleton mode, 15–16

remote objectsactivation example, 40–41advisory about, 391calling methods on, 52creating with RemotingHelper class,

185–186instantiating, 186–187managing with .NET remoting, 11versus mobile objects, 1

remote SAOs, creating references to, 187remote sponsors, explanation of, 156remoteable types, sharing information

about, 78remoting

evolution of, 3–7explanation of, 1five elements of, 201–202scenarios for implementation of, 2

remoting applications, preparing fordevelopment of, 14–15

remoting behavior, reasons for changingof, 249

remoting configuration files, structureof, 99

remoting eventsexplanation of, 185–187problems with, 187–191

remoting proxies, customizing, 309–310Remotingonfiguration.Configure()

method, calling, 88–89RemotingHelper class, creating remote

objects with, 185–186RemotingServices.Marshal(), using with

published objects, 36–37

renewOnCallTimeproperty, explanation of, 136

reply messages, handling with .NETRemoting Framework, 341

replySink, role in asynchronousIMessageSink processing, 223

request and response message contents,dumping with custom prox-ies, 312–314

request streams, verifying compressionof, 263

responses, handling with .NETRemoting Framework, 340

RETR message_number command, rolein POP3, 321

RFCs (Requests for Comment), 318for APOP command, 320for Base64 character encoding, 321for SMTP protocol, 318

roles, checking, 128–131runtime information, passing, 286–299

SS units for <lifetime> tag attributes,

explanation of, 99, 137SAOs (server-activated objects)

accessing versions of, 170–172calling with different delays for

clients, 143–144versus CAOs, 206explanation of, 28–30passing runtime information with,

296–297presenting with servers, 80–81registering on clients with <well-

known> property, 109–110server-side implementation for IIS,

118–119using asynchronous calls with, 183

SDLChannelSink, explanation of, 219serializable objects, generating first

version of, 177–178[Serializable] objects

using in shared assemblies, 90versioning, 174–179

serializationbenefits to versioning, 178implementing, 14–15

serializing objects, 27–28server-activated objects, versioning,

162–164server applications, deploying, 111server assemblies, explanation of, 15server channels, implementing,

355–361server-side asynchronous processing,

performing, 233–235

401

Index

252indx.qxp 3/11/02 4:35 PM Page 401

server-side HTTP channel’s sink stack,diagram of, 245

server-side messaging, examples of,216–218. See also client-sidemessaging, messages

server-side objectsdesigning and developing for IIS,

118–119using ObjRefs with, 68

server-side PriorityChangerSink code,293–296

server-side sink chain with compressionsink, diagram of, 250

server-side sink providers, creating,258–260

server-side sinks. See also client-sidesinks, sinks

creating, 244–245, 361–366implementing for compression sinks,

255–258initializing for encryption, 281

server-side sponsorscreating, 160keeping alive, 156pinging with clients, 157–158using, 156–162

server-side transport sinks versus con-ventional channel sinks, 362

ServerContextTerminatorSink, expla-nation of, 220–221

server.cs file, generating with SoapSuds,94, 183

ServerObjectTerminatorSink, expla-nation of, 221

ServerProviders and ClientProvidersproperties, role in config-uration files, 102–106

serversadvisory when running on same

machine, 75advisory when using events with, 187creating for synchronous calls, 53–57enhancing for versioned SAOs,

168–170example for SingleCall SAO, 30–33example with client-activated object,

39–40implementing for

MarshalByRefObject inSingleton mode, 17–19, 22–25

implementing for SoapSuds-generated metadata, 80–81

implementing in sample multiserverconfiguration, 73–76

implementing IServerChannelSinkon, 287–288

role in configuration files, 90–91, 95role in sample multiserver config-

uration, 70sample factory design pattern imple-

mentation for, 44–46sample implementation for lifetime

management, 140–142, 145using binary encoding via HTTP

with, 105–106ServerStartup class, role in Singleton-

object example, 34, 36<service> property, role in configuration

files, 106shared assemblies

advantage of, 11–12creating abstract base classes in, 78implementing for sample multiserver

configuration, 72–73management of, 77–86

shared base classes, functionality of, 78shared implementations, functionality

of, 78shared interfaces

for factory design pattern, 44functionality of, 78role in .NET Remoting, 12

sign-on process, securing, 131–133single sign-on, enabling, 132–133SingleCall SAOs

example of, 30–32explanation of, 28role in sample multiserver config-

uration, 74–75Singleton mode, defining

MarshalByReftObject in, 15–22Singleton SAOs

example of, 33–36explanation of, 28tip about, 35

sink chainsdefining in configuration files,

237–238role in implementing client channels,

349–350sink providers

behavior after invoking CreateSink()method, 242–243

creating, 258–260examining <url> entries with, 305understanding, 237–238

sinks. See also client-side sinks, server-side sinks

building for encryption helpers, 272creating for clients, 350–355creating for encryption, 274–280using, 261–263

402

Index

252indx.qxp 3/11/02 4:35 PM Page 402

SinkStack, contents in asynchronousrequests, 228–230

SMTP conversion, example of, 318–319SMTP sessions, starting, 319SMTP (Simple Mail Transfer Protocol)

encapsulating for channel source,323–331

RFC for, 318SMTPChannel

code for, 366–369using, 369–371

SMTPClientChannel, parametersfor, 346

SMTPClientTransportSinkProvider code,350–351

SMTPHelperClass, connecting to .NETRemoting with, 336–339, 344

SMTPHelper.MessageReceived() staticmethod, calling, 332–333

smtpServer parameter forSMTPClientChannel, 346, 356

SMTPServerChannelparameters for, 356versus SMTPClientChannel, 356–357

SMTPServerTransportSink, implement-ing, 362–364

sn.exe, generating key pairs with, 163SOAP formatter, role in handling asyn-

chronous responses, 233SOAP (Simple Object Access Protocol)

remoting framework, evo-lution of, 6–7

SoapClientFormatterSink, explanationof, 215

SoapFormatter, introduction to, 211SoapServerFormatterSink, explanation

of, 219SoapSuds

alternatives for starting of, 83calling, 79extracting metadata with, 167generating nonwrapped proxy source

with, 172–173generating source code with, 93–95

SoapSuds -gc output for SAO, exampleof, 181–183

SoapSuds-generated metadata, exam-ples of, 79–86

SoapSuds-generated proxies, using dele-gates with, 180–181

SoapSuds, role in .NET Remoting gener-ated metadata assembly, 12

SoapSuds.exe, role in SAO example,38–40

SoapType attribute, removing fromserver.cs, 183

source codegenerating with SoapSuds, 93–95simplifying for clients with wrapped

proxies, 81–82sponsors

role in lifetime management, 49,135–136

working with, 149sponsorshipTimeout attribute

explanation of, 136role in <lifetime> tag for config-

uration files, 99SSL (Secure Socket Layers) encryption,

advisory about, 134StackBuilderSink, explanation of, 221StartListening() method, calling for

server channels, 357–358, 360STAT command, role in POP3, 321StopKeepAlive() method, calling for

server-side sponsors, 159strictBinding attribute for formatters

and providers in config-uration files, using, 104–105

strong namingdisplaying for assemblies, 166role in versioning, 162–164

suppressChannelData attribute, role inHTTP channels for config-uration files, 101

symmetric encryption, example of,269–274

synchronous callsexample of, 53–57explanation of, 52using RealProxy with, 203

synchronous messages, examples of,214–216

SyncProcessMessage() method, imple-menting, 286–287

TTCP channel, role in configuration

files, 102TCP trace from client/server con-

nection, example withoutusing sinks, 262

time units for <lifetime> tag attributes,99

TimeSpans, returning for sponsors,149–150

transport channelsmoving messages through, 212–214preparing machines for, 371protocol considerations for, 317–323role in messages, 207–208

transport sinks, creating, 361–366

403

Index

252indx.qxp 3/11/02 4:35 PM Page 403

try/catch blocks, adding to clients forasynchronous one-way calls,65–66

TTL (time-to-live)changing defaults for, 137–138role in lease-based object lifetime

service, 135type attribute

for formatters and providers inconfiguration files, 103

role in <channels> tag for config-uration files, 101

using with <activated> property forconfiguration files, 108, 110

using with <wellknown> property,107

using with <wellknown> property forconfiguration files, 109–110

TypeLoadExceptions, generating withdelegates, 180

<Typename> properties in configurationfiles for lifetime example, 147

typos, effect on configuration files, 97

U/u [<assembly>] parameter, role in ver-

sioning, 164uncompressed streams, creating class

for, 253–254Unicode, explanation of, 321url attribute

using with <client> property forconfiguration files, 109

using with <wellknown> property forconfiguration files, 109–110

UrlAuthenticationSink, using, 306–308UrlAuthenticator code, storing user-

names and passwords with,301–305

URLs (uniform resource locators)parsing, 344specifying username/password com-

binations for, 307useDefaultCredentials property,

enabling single sign-on with,132–133

useIpAddress attribute, role in HTTPchannels for configurationfiles, 102

user accounts, defining for transport-channel examples, 371–372

USER username code, role in POP3, 320

Vversioned SAOs, lifecycles of, 165–172versioning

ins and outs of, 162purpose of, 175–176role in configuration files, 104–105

virtual roots, creating for IIS as containerfor server-side objects, 119

WWeb services remoting framework, evo-

lution of, 6–7Web sites

for compression library, 251for Mercury/32 e-mail server, 371for SOAP binding to SMTP, 321tcpTrace tool, 262

web.config, role in lifecycle of versionedSAOs, 166

<wellknown> propertyrole in configuration files, 106–107,

109–110role in lifecycle of versioned SAOs,

166–167, 170Windows authentication, enabling,

131–132Windows services, deploying servers

with, 111–117wrapped proxies

creating with SoapSuds, 79–84internals of, 83–84

wrapper methods, using delegates with,184–185

wrappers, event handling with, 192?WSDL parameter, advisory when

creating server-side sinks, 245

XXML (eXtensible Markup Language),

serializing objects to, 27–28XML-RPC (eXtensible Markup

Language-Remote ProcedureCalls) remoting framework,evolution of, 6

404

Index

252indx.qxp 3/11/02 4:35 PM Page 404