.NET REMOTING
CertSIG
Tom Perkins
FUNDAMENTALS
Distributed Applications
•Objects can communicate across
process boundaries
•Objects may be on same computer,
different computers, or Internet
Process A
•Heterogeneous architectures allowed
•Some processes can run even
though others busy or have failed
•Application divided into tiers (layers)
– gives increased flexibility and
scalability
Process C
Process B
Process Boundaries
Good News …
•Windows creates “process boundary” to
isolate processes
•Keeps one process from affecting others
Process A
•Each process has its own
•virtual address space
•Executable code
•Data
•One process cannot access code or data
of another process
•If process crashes it doesn’t affect others
Bad News …
Takes a lot of resources to create, monitor, and
terminate processes
Switching processes is expensive
Many apps have many short-lived processes
Process B
Application Domains
CLR
Process A
Application Domain
A
Application Domain
B
•Provides managed execution
•Services:
•Cross-language integration
•Code access security
•Object lifetime management
•Debugging
•Profiling support
•Application can run in CLR in
application domain
•Smallest execution unit in .NET
•Class System.AppDomain
•Several app domains can run in a
Windows process
•App domain boundary similar to
process boundary, but much cheaper
•Can run multiple apps in same
Windows process
3 Ways to develop Distributed
Applications
System.Net
Namespace
•Standalone listeners
•Custom protocol handlers
•Requires good understanding of network programming
System.Runtime.Remotin
g
Namespace
System.web services
System.Web.Services
namespace
•Classes in this chapter
•Allows communication between objects in
different app domains
•May be on separate computers
•Simple way for processes to communicate
•Key characteristics: flexibility and extensibility
•Classes make up ASP.NET Web Services
•Objects exchange messages in HTML and
SOAP
•Key characteristics: simplicity and
interoperability with other systems
What is .NET Remoting?
• .Net Remoting allows objects in different
application domains to talk to one another
• It handles the details of network
communication transparently
What about this business of no
direct calls across application
domain boundaries?
• Remoting uses indirect approach
• Creates proxy objects
.Net Remoting Architecture
Client object
Server Object
Proxy
Remoting System
Client App Domain
Channel
Remoting System
Server App Domain
Marshalling
• Process of packaging and sending method
calls among objects
• Uses serialization and deserialization
Remotable Objects
• Definition – objects that can be marshalled
across application domains
• All other objects – non-remotable objects
• Two types of Remotable Objects
– Marshal-by-value (MBV)
• Copied from server domain to client app domain
– Marshal-by-reference (MBR)
• Uses proxy to access objects on client side
• Clients hold just a reference to these objects
Marshal-by-Value Objects
Faster performance
Fewer network roundtrips
Large objects slow to move
Client invokes a
method on MBV
object
2.
Doesn’t run in (better)
server environment
1.
Object resides
here
3.
Object is serialized,
transferred over
network,restored on client
as exact copy
4,
MBV object
available on client;
No proxy, no
marshalling
Create by declaring class
serializable
Client App Domain
[Serializable]
Public class MyMBVObject
Server App Domain
Marshal-by-Reference Objects
Increases number of
network roundtrips
Use when objects are large
Client invokes a
method on
object
2.
Or functionality available
only on server
.
1.
Object always
resides,
executes here
3,
Local proxy holds
reference to object
Client App Domain
Server App Domain
public class MyMBRObject : MarshalByRefObject
Channels
• Objects that transport messages across
application boundaries (computers, etc)
• When client calls method on server, info
transferred through channel
• Info back through same channel
• Channels must be registered before they
can be used
More about Channels
• Channel has 2 endpoints
• Receiving end (server) listens to particular protocol
through specified port number
• Sending end (client) sends info using protocol and port
number specified by server
• Receiving end  must implement IChannelReceiver
Interface
• Sending end  must implement IChannelSender
Interface
• Protocols
– HTTP
– TCP
Formatters
• Defn- objects used to serialize and
deserialize data into messages before
they are transmitted over a channel
• 2 Formatters
– SOAP – SOAPFormatter class
– Binary – BinaryFormatter class
• Defaults
– HTTP Channel SOAP formatter
– TCP Channel Binary formatter
Remote Object Activation
Client object
Server object
• Only MBR objects can be activated
remotely
• 2 Categories of Activate objects
– Server-activated objects
– Client-activated objects
Server-activated Objects (SOAs)
• Object Lifetime controlled directly by
server
• Remote object instantiated only when
client calls a method on proxy object
Client object
Server Object
Proxy object
This guy controls its own
lifetime
2 Activation Modes for SOAs
• Single-Call activation
– Object instantiated only for purpose of fulfilling
one client request
– .NET then deletes and reclaims memory
• Singleton Activation mode
– At most one remote object, regardless of how
may clients may be using it
– State can be maintained
– Lifetime Lease determines its lifetime
When to use
• Single-Call activation
–
–
–
–
–
When it doesn’t cost much to create an object
No object state required
Server needs to support large number of requests for object
Load balancing environment
(retrieve inventory level for an item, display shipment info, etc)
• Singleton Activation
–
–
–
–
Use when it costs a lot to create an object
State required over a long period of time
Several clients need to work on the shared state
(Chat server – multiple people talk to same remote object and
share data with one another)
Client-Activated Objects (CAOs)
Client object
Server Object
Proxy object
This guy controls this guy’s
lifetime.
• Lifetime is controlled by the client
• CAOs are instantiated on server as soon as the
client requests the object to be created.
• Object creation is not delayed until first method
is called by client.
CAO Activation
1. Client attempts to
create an instance of the
server object.
Client object
Server Object
3. Server
creates object
5. Client uses ObjRef object to
build proxy
Proxy
2. Activation request
sent to remote server
Remoting System
Client App Domain
Channel
Remoting System
4. Server return ObjRef
object to client – info to
build proxy object
Server App Domain
CAO Characteristics
• Serves only client responsible for its
creation
• Doesn’t get discarded with each request
• Can maintain state with client it is serving
• Unlike Singleton CAO’s, different CAOs
cannot share a common state.
When to Use CAOs
• Clients want to maintain a private session
with the remote object
• Clients want to have control over how the
object is created and how long it should
live.
• Example: a complex purchase order
involving many roundtrips and clients want
to maintain their own private state with the
remote object
Comparing Object Activation
Techniques
Activation Type
Flexibility
Scalability
Single-Call Server
Activation
Singleton Server
activation
Client Activation
Maximum scalability;
remote object uses
resources for min time;
server can handle many
clients
Maximum flexibility; you have
complete control over remote
object construction and lifetime
Lifetime Leases
• Definition – the period of time a particular
object will be in memory before deletion and
garbage collection
• Used by Singleton SAOs and CAOs
• Object must implement Ilease interface in
the
System.Runtime.Remoting.Lifetime
namespace
DEMO – 1.Create a Remotable
class
• Must inherit from MarshalByRefObject class.
• This demo creates DbConnect class (will produce a
remote server object)
• Purpose: connects to a SQL Server database
• Allows you to execute a SELECT statement to return a
dataset – ExecuteQuery() method on the server object.
• Walkthru, then class is in DLL (bin\Debug)
Remotable class
• Still need to connect to Remoting Framework
Client object
Server object
SQL SELECT query
ExecuteQuery()
dataset
Server Program
•
•
•
•
Connects to .Net Remoting Framework
Listens to the client request
Instantiates the remote object
Invokes calls on remote object as requested by client
Server Program
Listens to
client
requests
Remote object
Creating a Server-Activated Object
(SAO)
Remotable class
Remoting
Remoting Server Program
Framework
DbConnect
Activation requests
Channel
1. create server channel – listens on
particular port for activation requests
from other application domains
TcpServerChannel channel = new
TcpServerChannel(1234) // port 1234
2. Register the channel with .Net
Remoting
3 Register the remotable class
RemotingConfiguration.RegisterWellKn
ownServiceType(
typeof(dbConnect), // type of class
“DbConnect”, // URI of remotable class
WellKnownObject Mode.SingleCall)
// activation mode – c.b. Singleton
Remote object can
be accessed
through all
registered channels
DEMO – 2. Create a ServerActivated Object (SingleCall)
• Exposes the remotable class through the
remoting framework
• Long running process
– No interface
– Listens for incoming client requests on a channel
•
•
•
•
This example uses a Console application
(Should be a Windows service or IIS)
Walkthru – StepByStep3_2
Creates a remoting host that listens on port 1234
DEMO – 3. Instantiate and Invoke
a Server-Activated Object
• We’re building a Remoting Client
• We want to send messages to Remoting Server
to activate the Remote object.
• Steps
– Create and register a client channel to send
messages to server; type s.b. compatible (TCP or
HTTP)
– Register the remotable class in the client’s app
domain.
– Instantiate the server object
DbConnect dbc = new DbConnect();
StepByStep3_3
•
•
•
•
Windows application
Accepts SQL SELECT string from user
Passes it to remotable object
Returned rows are displayed in datagrid