Transcript Context and Remoting
Context and Remoting
Module Subtitle
Building distributed applications and implementing attribute-driven behaviors with Microsoft .NET
Objectives
Introduction to the .NET Remoting core infrastructure Explore the extensibility mechanisms Available on the transport level Available through the Remoting Context
Contents
Section 1: Overview Section 2: Remoting Architecture Section 3: Context and Interception Section 4: Serving and Accessing Objects Summary
Section 1: Overview
Looking back: Remoting in COM(+) What's wrong with that?
.NET Remoting Core Concepts
Looking Back: Remoting in COM(+)
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
What’s wrong with that?
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
.NET Remoting Core Concepts
The Federated Services Model XML EDIFACT X12 Trading Partners .NET
Building Block Services (“Hailstorm“) Financial News B2B WebService Providers SQL Server XML BizTalk Messaging Exchange WebStorage .NET
Enterprise Servers Open Standards: TCP/IP XML HTTP SMTP SOAP Enterprise Applications Website Knowledge Management Sales Procurement Accounting Organisation
Messages – RPC is not all
bidirectional message exchange Application Application Application unidirectional method call bidirectional method call queued message exchange Message Queue Application
Application Domains
Isolated execution space for applications Independent of OS concept of thread, process AppDomain
Object Object
AppDomain
Object
AppDomain
Object
Process
Object
Process
The Remoting Context
Derived from COM+ context idea But: Remoting Context != COM+ Context Encloses objects with same functional context Carries shared properties that describe behavior
remoting boundary Object Object Object RqTx Sync Thrd Context Object Object Context Object Object AppDomain
What is
“
Remote
”
, What is
”
Local
”
?
"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
Section 2: Remoting Architecture
What: Messages Where: Channels How: Formatters Marshaling Concepts Proxies
What to communicate: Messages
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
Where to communicate: Channels
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 "Proxy" Channel Server Dis patcher
How to communicate: Formatters
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
SOAP, Binary, Custom decode from wire format encode into wire format Channel
Selecting Channels: TcpChannel
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
Selecting Channels: HttpChannel
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
Selecting Channels: Custom
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
The Message Box: IMessageSink
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 "Proxy"
SynchProcessMessage() or AsynchProcessMessage()
IMessageSink Channel
Objects To Go: Marshaling
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
Concepts: Agile and Contextful
Agile Objects Independent of Context Called directly from any AppDomain or Context Do not use channels Unbound Classes: Travel between AppDomains, marshal-by-value AppDomain-Bound Classes: Reside in a single AppDomain, marshal-by-reference Contextful Objects Bound to AppDomain
and
Context Marshal-by-reference outside of context
Objects calling Objects: Proxies
"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
Proxies illustrated
Client "Proxy" IMessageSink Channel Server Transparent Proxy MethodA() MethodB() PropertyQ PropertyP FieldX FieldY
builds Invoke()
Real Proxy
SyncProcessMessage()
The Dispatcher
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
The Dispatcher illustrated
Client Server Dispatcher Channel
actual method calls
StackBuilderSink
SyncDispatchMessage()
MethodA() MethodB() PropertyQ PropertyP FieldX FieldY Object
Channel Sinks
Formatter, dispatcher and transport are in sinks All channel sinks are linked in chains Client Server Client Object Server Object Proxy StackBuilderSink Formatter Sink Custom Sinks Custom Sinks Transport Sink Formatter Sink Custom Sinks Custom Sinks Transport Sink
Some Advanced Topics
Declaring Methods "One-Way" Use the "oneway" attribute: [oneway] void FireAndForget(); The Call Context Property bag passed with every IMessage Dictionary entry "__CallContext", class CallContext Allows to pass processing information along
Section 3: Contexts and Interception
Context Rules and Concepts Context Attributes and Properties Context Characteristics Interception: Context and Message Chains Standard Context Attributes Custom Context Attributes
Context Rules and Concepts
Contexts enclose "contextful" objects Classes derived from System.ContextBoundObject
Behavior for class declared using context attributes Common context boundary is shared when Objects have identical attributes
or
Context attributes actively agree to deviations All objects in other contexts are "remote" Conceptually similar to AppDomain boundary Messages crossing boundary may be intercepted Chains of IMessageSinks allows hooks at any stage
Context Attributes and Properties
System.
ContextBoundObject Yes! Use existing context.
No! Create new context.
IsContextOK() ?
Attribute 1 Context-Bound Class 2 3 create object Object No! GetPropertiesForNewContext() !
Property
Interception: Message Chains
Every message passes a four chains of sinks Context properties contribute these sinks Custom attributes allow intercepting all traffic
Client Server Channel Server Envoy Chain Client Context Chain Server Context Chain Server Object Chain
Chain Hooks: Message Sinks
Server Object Sink Installed to intercept messages per-object Allows to modify object behavior on message level Server Context Sink, Client Context Sink Installed to intercept messages per-context Allows to see, modify and possibly block all traffic Server Envoy Sink Installed by the server on the client side (!) Allows to pre-scan messages before transmission e.g. parameter validation e.g. queuing of multiple calls for optimization
Attribute Driven Behaviour
Sample Context Attribute: CallTraceAttribute Intercepts all calls crossing the context boundary Writes methods and arguments to log file How to establish interception?
Property implements IContributeServerContextSink GetObjectSink() returns new IMessageSink
Server Context Chain Server Property contributes sink for server context chain Context Property
Standard Context Attributes
[Synchronization()] Attribute Synchronized (serial) calls into context only Calls are queued at context boundary Allows to mimic the COM+ Apartment Model COM+ Context Relationship COM+ Context is a different boundary May or may not overlap with remoting context No relationship whatsoever Belongs to COM/Interop Services domain
Context Characteristics
Context Local Store Allows any data to be associated with the context Context.SetData(), Context.GetData() Context Statics [ContextStatic] static int q = 4; Static (class) member with per-context scope Access to the current context via Thread class Thread.GetCurrentContext()
Section 4: Serving & Accessing Objects
Remoting Services Exposing Well-Known Objects Exposing Classes for Client-Side Activation Configuring Remoting and Registering Channels Activation and Access
Remoting Services
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
Exposing Well-Known Objects
.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 and Singletons
"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
Server Setup Example
...
HttpChannel chan = new HttpChannel(8080); ChannelServices.RegisterChannel(chan); RemotingConfiguration.
RegisterWellKnownServiceType( typeof(ServerClass), "MyEndpointURI", WellKnownObjectMode.SingleCall);
Channel registration Object registration
Registers the single-call endpoint:
http://myserver:8080/MyEndpointURI
Channels and Objects are AppDomain-Global
Client-Side Activation
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"
Object Activation and Connection
The Activator (System.Activator) Creates or connects local and remote objects Activator.CreateInstance() Creates client activated objects Activator.GetObject
Connects to well-known objects RemotingServices Connect – lower level connect to remote object Relationship: Activator uses RemotingServices
Activation illustrated
tcp://server:8501/uriD http://server:8080/uriB
RemotingServices.Connect() Activator.GetObject() HTTP 8080 Identity Table
uriA uriB
Language binding Context Object
o = Activator.
GetObject("http://...") o.methodCall(); o = new myClass(); o.methodCall();
Object TCP 8501
uriC uriD
Object Object AppDomain
Configuring Remoting
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
Server System Configuration
SoapServerFormatterSinkProvider, System.Runtime.Remoting" /> Specify formatter
Server Application Configuration
Section 5: Putting It Together
Variations of Objects Context Attributes and Interception
Variations of Objects
1/2
Agile (never marshaled) public class MySimpleObject { public MySimpleObject() { } } Agile (marshal-by-value) [serializable] public class MySimpleObject { public MySimpleObject() { } }
Variations of Objects
2/2
Agile (marshal-by-ref, AppDomain-bound) public class MySimpleObject : MarshalByRefObject { public MySimpleObject() { } } Context-bound (marshal-by-ref) [CallTrace()] public class MySimpleObject : ContextBoundObject { public MySimpleObject() { } }
Context Attributes & Interception
1/3
A Simple Context Attribute public class CallTraceAttribute : ContextAttribute { public CallTraceAttribute(): base( "CallTraceAttribute" ) { }
false
forces new context public override bool IsContextOK( Context ctx, IConstructionCallMessage ctorMsg ) { return false; } install property public override void GetPropertiesForNewContext( IConstructionCallMessage ctorMsg ) { CallTraceProperty prop = new CallTraceProperty(); ctorMsg.ContextProperties.Add( prop ) ; } }
Context Attributes & Interception
2/3
A Simple Context Property public class CallTraceProperty : IContextProperty, IContributeServerContextSink { public String Name { get { return "CallTraceProperty"; } } Installed props public virtual bool IsNewContextOK (Context newCtx) { return true; } check context public virtual void Freeze (Context newContext) { } Installs sink on runtime request.
public IMessageSink GetServerContextSink (IMessageSink next) { } return new CallTraceObjectSink(this, next); }
Context Attributes & Interception
3/3
A Simple Message Sink public class CallTraceObjectSink : IMessageSink { private IMessageSink _nextSink; public CallTraceObjectSink(CallTraceProperty prop, IMessageSink nextSink) { _nextSink = nextSink; } Dumps content of IMessage for each call public IMessage SyncProcessMessage Console.WriteLine(o); } (IMessage reqMsg){ foreach( object o in reqMsg.Properties) { return _nextSink.SyncProcessMessage(reqMsg); Next sink receives control thereafter } public IMessageCtrl AsyncProcessMessage Console.WriteLine(o); } (IMessage reqMsg, IMessageSink reply){ foreach( object o in reqMsg.Properties){ return _nextSink.AsyncProcessMessage(reqMsg, reply); } public IMessageSink NextSink { get {return _nextSink; } } }
Summary
.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