net remoting certsig tom perkins. fundamentals distributed applications process a process b process...
TRANSCRIPT
.NET REMOTING
CertSIG
Tom Perkins
FUNDAMENTALS
Distributed Applications
Process A
Process B
Process C
•Objects can communicate across process boundaries
•Objects may be on same computer, different computers, or Internet
•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 Boundaries
Process A Process B
Good News …
•Windows creates “process boundary” to isolate processes
•Keeps one process from affecting others
•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
Application Domains
Process A
Application Domain
A
Application Domain
B
CLR
•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.Remoting
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
System.Web.ServicesSystem.web services
namespace
•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
Client App Domain Server App Domain
Proxy
Remoting SystemRemoting System
Server Object
Channel
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
Client App DomainServer App Domain
Object resides hereClient invokes a
method on MBV object
1.
3.
2.
Object is serialized, transferred over network,restored on client as exact copy
MBV object available on client;
No proxy, no marshalling
4,
Faster performance
Fewer network roundtrips
Large objects slow to move
Doesn’t run in (better) server environment
Create by declaring class serializable
[Serializable]
Public class MyMBVObject
Marshal-by-Reference Objects
Client App DomainServer App Domain
Object always resides,
executes here
Client invokes a method on
object
1.
.
2.
Local proxy holds reference to object
3,
Increases number of network roundtrips
Use when objects are large
Or functionality available only on server
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
• Only MBR objects can be activated remotely
• 2 Categories of Activate objects– Server-activated objects– Client-activated objects
Client objectServer object
Server-activated Objects (SOAs)
• Object Lifetime controlled directly by server
• Remote object instantiated only when client calls a method on proxy object
Client object
Proxy object
Server 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)
• 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.
Client object
Proxy object
Server Object
This guy controls this guy’s lifetime.
CAO Activation
Client object
Client App Domain Server App Domain
Proxy
Remoting SystemRemoting System
Server Object
Channel
1. Client attempts to create an instance of the server object.
2. Activation request sent to remote server
3. Server creates object
4. Server return ObjRef object to client – info to build proxy object
5. Client uses ObjRef object to build proxy
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)• Still need to connect to Remoting Framework
Client object Server object
ExecuteQuery()
SQL SELECT query
dataset
Remotable class
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
Remote object
Listens to client
requests
Creating a Server-Activated Object (SAO)
Remoting Server Program
Channel
Remoting
Framework DbConnect
Remotable class
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.RegisterWellKnownServiceType(
typeof(dbConnect), // type of class
“DbConnect”, // URI of remotable class
WellKnownObject Mode.SingleCall)
// activation mode – c.b. Singleton
Activation requests
Remote object can be accessed through all registered channels
DEMO – 2. Create a Server-Activated 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 objectDbConnect dbc = new DbConnect();
StepByStep3_3
• Windows application
• Accepts SQL SELECT string from user
• Passes it to remotable object
• Returned rows are displayed in datagrid