.NET Remoting Module Subtitle Building distributed applications and - - PowerPoint PPT Presentation
.NET Remoting Module Subtitle Building distributed applications and implementing attribute-driven behaviors with Microsoft .NET Contents Section 1: Overview Section 2: Remoting Architecture Section 3: Context and Interception
Module Subtitle Building distributed applications and implementing attribute-driven behaviors with Microsoft .NET
Section 1: Overview Section 2: Remoting Architecture Section 3: Context and Interception Section 4: Serving and Accessing Objects Summary
Looking back: Remoting in COM(+) What's wrong with that? .NET Remoting Core Concepts
All Objects implement IUnknown interface
Dynamic exploration of object features Lifecycle control with reference counting
DCOM: Object-RPC based on DCE Wire Format Marshaling through MIDL generated Proxies/Stubs
Automation: Dynamic binding through IDispatch
Servers locally advertised in Registry Activation "on-demand"
Servers launched at client request Objects created through class factories
DCOM protocol is binary and complex Reference counting difficult to master
Common source of memory leaks for servers Distributed operation require "pinging" clients
Marshaling is non-extensible Registry is difficult to manage; registration clumsy Activation paradigm has component bias
Difficult to locate and connect active servers
Connection oriented protocol
Does not work well on the Internet
Isolated execution space for applications Independent of OS concept of thread, process Process Process AppDomain AppDomain AppDomain
Object Object Object Object Object
"Local" are all objects within the same AppDomain All other objects are "Remote"
Even objects in the same process!
Context-bound objects:
"Local" if they share the same context "Remote" if they are in different contexts
"Local": Not marshaled, immediate object calls "Remote": Marshaled, calls through proxies
What: Messages Where: Channels How: Formatters Marshaling Concepts Proxies
Messages are objects that implement IMessage IMessage: Simple dictionary of key/values pairs .NET Message Types:
Construction call messages, response messages Method call messages, response messages
Invocation Styles
Synchronous: Request with immediate response Asynchronous: Request with delayed or no response
Server
Channels transport messages
Built-in channels: TCP, HTTP
Establish endpoint-to-endpoint communication Channels can listen for and send messages
Listen: IChannelReceiver, Send: IChannelSender
Makes no assumptions about endpoint architecture Can implement channel sinks for logging, interception Client Channel "Proxy" Dis- patcher
Formatters serialize .NET objects into wire formats Used dynamically by channel architecture
Configuration-file based association with channels Formatters are implemented as channel sinks
Built-in: SOAP and Binary Formatters
System.Runtime.Remoting.Serialization.Formatters Channel encode into wire format decode from wire format SOAP, Binary, Custom
System.Runtime.Remoting.Channels.Tcp Uses plain TCP sockets Transmits compact, binary wire format
By default, serialized by the BinaryFormatter .NET native wire-format Fast
Can use custom formatters for other wire-formats Best choice for LAN communication
Uses permanent socket connection
Not recommended for Internet communication
System.Runtime.Remoting.Channels.Http Uses HTTP 1.1 protocol Transmits SOAP 1.1 XML format
Serialized by SoapFormatter Open standard Basis for W3C SOAP/XMLP Protocol activity
Can use custom formatters for other wire-formats Best choice for Internet communication
Stateless protocol, scales well
Best choice for interoperability and integration
Bring your own Protocol (APPC,IPX,Pipes, ...) Transmit any format that fits
Can use SoapFormatter or BinaryFormatter Or bring your own formatter: IIOP, RMI, ORPC, ...
Applies to integration scenarios
Message Sinks are the .NET message drop-off Implemented by channels to accept messages Implemented by context properties for interception Allows building chains of sinks
Simple linked list through NextSink property Messages can be intercepted, modified or
processed anywhere in the chain
Client Channel "Proxy" IMessageSink
SynchProcessMessage()
Definition: Packaging Data for Transfer For objects passed as arguments, return values Marshal-By-Value
Entire object is packaged as-is Copy is transferred to destination No link between copy and original
Marshal-By-Reference
Just a reference to an object is packaged Reference is transferred to destination "Proxy" object links destination with original
"Proxy" Definition
Object that acts locally on behalf of a remote object Looks like and accepts calls as if it were "real" Forwards them to the remote object
Real Proxies
Inherit System.Runtime.Remoting.RealProxy Are the communication layer for transparent proxies
Transparent Proxies
Built dynamically through RealProxy Exact pass-through mirror of the remote object
Client Server
Channel "Proxy" IMessageSink Transparent Proxy MethodA() MethodB() PropertyQ PropertyP FieldX FieldY Real Proxy
builds Invoke() SyncProcessMessage()
Simplified model:
Located at the channel endpoint Receives messages Builds stack-frame from message content Invokes actual method on object Collects result and creates response message
Server Dispatcher
Client Channel Object MethodA() MethodB() PropertyQ PropertyP FieldX FieldY StackBuilderSink
SyncDispatchMessage() actual method calls
Formatter, dispatcher and transport are in sinks All channel sinks are linked in chains Client Server StackBuilderSink Server Object Formatter Sink Custom Sinks Custom Sinks Custom Sinks Transport Sink Proxy Client Object Formatter Sink Custom Sinks Custom Sinks Custom Sinks Transport Sink
Declaring Methods "One-Way"
Use the "oneway" attribute:
[oneway] void FireAndForget(); [oneway] void FireAndForget();
The Call Context
Property bag passed with every IMessage Dictionary entry "__CallContext", class CallContext Allows to pass processing information along
Remoting Services Exposing Well-Known Objects Exposing Classes for Client-Side Activation Configuring Remoting and Registering Channels Activation and Access
System.Runtime.Remoting.RemotingServices class
Provides fundamental remoting infrastructure
Connecting to remote object instances Object marshaling
System.Runtime.Remoting.RemotingConfiguration
Provides infrastructure for Remoting configuration
System.Runtime.Remoting.ChannelServices
Channel registration and management
System.Runtime.Remoting.LifetimeServices
Lease-based lifecycle management for objects
System.Runtime.Remoting.TrackingServices
Universal hooks for tracking remoting activities
.NET's activation model is very unlike COM's
.NET rather resembles CORBA model (!)
If there is no actively listening endpoint: no connection No surrogates, no registry, no location transparency EXE servers are not remotely activated
Simplifies Remoting greatly
Expose well-known object for clients to connect.
Bound to known channels with known name Does not use static registration, prog-ids or class-id
Can expose "single call" or "singleton" objects
"Single Call" Objects
Object instance is created for each call on channel Implements the stateless model of the web
"Singleton" Objects
One shared instance provided for all clients Serves as "gateway" into stateful application Object is created at registration time
RemotingConfiguration.
RegisterWellKnownServiceType
WellKnownObjectMode.SingleCall WellKnownObjectMode.Singleton
Channels and Objects are AppDomain-Global
Registers the single-call endpoint: http://myserver:8080/MyEndpointURI
Channel registration Object registration
... ... HttpChannel chan HttpChannel chan = new HttpChannel(8080); = new HttpChannel(8080); ChannelServices.RegisterChannel(chan); ChannelServices.RegisterChannel(chan); RemotingConfiguration. RemotingConfiguration. RegisterWellKnownServiceType( RegisterWellKnownServiceType( typeof(ServerClass), typeof(ServerClass), "MyEndpointURI", "MyEndpointURI", WellKnownObjectMode.SingleCall); WellKnownObjectMode.SingleCall);
Client-Side Activation similar to COM
Client requests creation of remote object Core difference: Server must be running
Server Side Implementation:
Class registered with RemotingConfiguration class
RemotingConfiguration.RegisterActivatedServiceType()
Runtime creates objects on client request
Client Side Implementation:
Object created through Activator class Alternatively: Configuration and language binding
Allows creating remote objects using "new"
The Activator (System.Activator)
Creates or connects local and remote objects
Activator.CreateInstance()
Activator.CreateInstance()
Creates client activated objects
Activator.GetObject
Activator.GetObject
Connects to well-known objects
RemotingServices
Connect – lower level connect to remote object
Relationship: Activator uses RemotingServices
GetObject("http://..." GetObject("http://...")
AppDomain
Context
Object Object Object Object
TCP 8501 HTTP 8080
Identity Table
uriA uriB uriC uriD tcp://server:8501/uriD http://server:8080/uriB
RemotingServices.Connect() Activator.GetObject() Language binding
yClass();
Remoting Configuration Architecture enables:
Definition of endpoints at installation time Well-known ports, full control for administrators Application component distribution by configuration
Configuration can define which classes are remote or local
Configuration is file-based
Integrated with .NET configuration infrastructure However: Must explicitly load
RemotingConfiguration.Configure(“filename“)
Hides most details of Remoting shown here
<configuration> <system.runtime.remoting> <channels> <channel id="http“ type="System.Runtime.Remoting.Channels.Http.HttpChannel, System.Runtime.Remoting" /> </channels> <channelSinkProviders> <serverProviders> <formatter id="soap“ type="System.Runtime.Remoting.Channels. SoapServerFormatterSinkProvider, System.Runtime.Remoting" /> </serverProviders> </channelSinkProviders> </system.runtime.remoting> </configuration> Declare channel Specify formatter
<configuration> <system.runtime.remoting> <application name="MyFoo"> <service> <wellknown type="Foo, common“
mode="Singleton" /> </service> <channels> <channel ref="http“ name="MyHttpChannel" port="9000"> <serverProviders> <formatter ref="soap" /> </serverProviders> </channel> </channels> </application> </system.runtime.remoting> </configuration> Associate channel with application Declare singleton service endpoint Associate formatter with channel
Variations of Objects Context Attributes and Interception
Agile (never marshaled)
public class MySimpleObject public class MySimpleObject { public MySimpleObject() { } public MySimpleObject() { } }
Agile (marshal-by-value)
[serializable] [serializable] public class MySimpleObject public class MySimpleObject { public MySimpleObject() { } public MySimpleObject() { } }
Agile (marshal-by-ref, AppDomain-bound)
public class MySimpleObject : public class MySimpleObject : MarshalByRefObject MarshalByRefObject { public MySimpleObject() { } public MySimpleObject() { } }
Context-bound (marshal-by-ref)
[CallTrace()] [CallTrace()] public class MySimpleObject : public class MySimpleObject : ContextBoundObject ContextBoundObject { public MySimpleObject() { } public MySimpleObject() { } }
.NET Remoting is open-standards based
... supporting SOAP, XML and HTTP
The infrastructure is extensible at every level
... and useable on every level
.NET Remoting Contexts build on the COM+ idea
... but make contexts available for your extensions
Attribute driven behaviors can be built on Contexts
... to separate plumbing from business code
.NET Remoting is configurable at installation time
... and on an application level