Upload
juniper-austin
View
229
Download
1
Embed Size (px)
Citation preview
Context and Remoting
Module SubtitleBuilding 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
WebServiceProviders
Trading Partners
.NETBuilding Block
Services (“Hailstorm“)
.NET Remoting Core ConceptsThe Federated Services Model
Financial
News
B2B
.NETEnterprise
Servers
BizTalkMessaging
SQL ServerXML
ExchangeWebStorage
Open Standards:
TCP/IPXML
HTTPSMTPSOAP
Enterprise Applications
Accounting Organisation
Sales Procurement
Knowledge Management
Website
XML
EDIFACT
X12
MessageQueue
Messages – RPC is not all
Application
Application
Application
Application
bidirectionalmethod call
unidirectionalmethod call
queuedmessage exchange
bidirectionalmessage exchange
Application Domains
Isolated execution space for applications
Independent of OS concept of thread, process
Process Process
AppDomain AppDomainAppDomain
Object Object
ObjectObjectObject
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
RqTx Sync Thrd
remoting boundary
Object
ObjectObject
AppDomain
Context Context
Object Object
Object Object
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
Server
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
Channel"Proxy"
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
Channel
encode into wire format
decode from wire format
SOAP, Binary, Custom
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
Channel
"Proxy" IMessageSink
SynchProcessMessage()or AsynchProcessMessage()
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
Client Server
Proxies illustrated
Channel
"Proxy" IMessageSink
Transparent Proxy
MethodA()
MethodB()
PropertyQ
PropertyP
FieldX
FieldY
RealProxy
builds
Invoke()
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
Server
Dispatcher
The Dispatcher illustratedClient
Channel
Object
MethodA()
MethodB()
PropertyQ
PropertyP
FieldX
FieldY
StackBuilderSink
SyncDispatchMessage()
actual method calls
Channel Sinks
Formatter, dispatcher and transport are in sinks
All channel sinks are linked in chains
Client Server
StackBuilderSink
Server Object
Formatter Sink
Custom SinksCustom SinksCustom Sinks
Transport Sink
Proxy
Client Object
Formatter Sink
Custom SinksCustom SinksCustom 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
Property
Object
Context-Bound Class
System.ContextBoundObject
Attribute
create object
IsContextOK() ?1
No! GetPropertiesForNewContext() !
23
newYes! Use existing context.
No! Create new context.
Interception: Message Chains Every message passes a four chains of sinks
Context properties contribute these sinks
Custom attributes allow intercepting all traffic
ServerClient
Server Envoy Chain
Client Context Chain
Server Context Chain
ServerObject Chain
Channel
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
ServerServer
Context Chain
Context Property
Property contributes sink for server context
chain
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
Channels and Objects are AppDomain-Global
Registers the single-call endpoint:http://myserver:8080/MyEndpointURI
Channel registration
Object registration
...
HttpChannel chan = new HttpChannel(8080);ChannelServices.RegisterChannel(chan);
RemotingConfiguration. RegisterWellKnownServiceType( typeof(ServerClass), "MyEndpointURI", WellKnownObjectMode.SingleCall);
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
o = Activator.GetObject("http://...")o.methodCall();
Activation illustrated
AppDomain
Context
Object Object
Object Object
TCP8501
HTTP8080
Identity Table
uriA uriB uriC uriD
tcp://server:8501/uriDhttp://server:8080/uriB
RemotingServices.Connect()
Activator.GetObject()
Languagebinding
o = new myClass();o.methodCall();
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
<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
Server Application Configuration<configuration> <system.runtime.remoting> <application name="MyFoo"> <service> <wellknown type="Foo, common“ objectUri="Foo.soap“ 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
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
false forces new
context
install property
public class CallTraceAttribute : ContextAttribute{ public CallTraceAttribute(): base("CallTraceAttribute") { } public override bool IsContextOK( Context ctx, IConstructionCallMessage ctorMsg) { return false; } public override void GetPropertiesForNewContext( IConstructionCallMessage ctorMsg) { CallTraceProperty prop = new CallTraceProperty(); ctorMsg.ContextProperties.Add(prop); } }
Installs sink on runtime request.
Context Attributes & Interception 2/3
A Simple Context Property
public class CallTraceProperty : IContextProperty, IContributeServerContextSink { public String Name { get { return "CallTraceProperty"; } }
public virtual bool IsNewContextOK(Context newCtx) { return true; } public virtual void Freeze(Context newContext) { }
public IMessageSink GetServerContextSink(IMessageSink next) { return new CallTraceObjectSink(this, next); } }
Installed props check
context
Context Attributes & Interception 3/3
A Simple Message Sinkpublic class CallTraceObjectSink : IMessageSink{ private IMessageSink _nextSink; public CallTraceObjectSink(CallTraceProperty prop, IMessageSink nextSink) { _nextSink = nextSink; }
public IMessage SyncProcessMessage(IMessage reqMsg){ foreach( object o in reqMsg.Properties) { Console.WriteLine(o); } return _nextSink.SyncProcessMessage(reqMsg);
}
public IMessageCtrl AsyncProcessMessage(IMessage reqMsg, IMessageSink reply){ foreach( object o in reqMsg.Properties){ Console.WriteLine(o); } return _nextSink.AsyncProcessMessage(reqMsg, reply); }
public IMessageSink NextSink { get {return _nextSink; } }}
Dumps content of IMessage for each
call
Next sink receives control
thereafter
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
Questions?