Context and Remoting

1
Context and Remoting
Module Subtitle
Building distributed applications and
implementing attribute-driven behaviors with
Microsoft .NET
2
Objectives

• Introduction to the .NET Remoting core
  infrastructure
• Explore the extensibility mechanisms
• Available on the transport level
• Available through the Remoting Context

3
Contents

• Section 1 Overview
• Section 2 Remoting Architecture
• Section 3 Context and Interception
• Section 4 Serving and Accessing Objects
• Summary

4
Section 1 Overview

• Looking back Remoting in COM()
• What's wrong with that?
• .NET Remoting Core Concepts

5
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

6
Whats 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

7
.NET Remoting Core Concepts

• The Federated Services Model

XML
Trading Partners
.NETBuilding Block Services (Hailstorm)
EDIFACT
Open Standards TCP/IP XML HTTP SMTPSOAP
X12
Financial
WebServiceProviders
News
Enterprise Applications
B2B
Sales Procurement
Website
SQL ServerXML
.NETEnterprise Servers
Accounting Organisation
Knowledge Management
BizTalkMessaging
ExchangeWebStorage
8
Messages RPC is not all
bidirectionalmessage exchange
Application
Application
MessageQueue
queuedmessage exchange
unidirectionalmethod call
bidirectionalmethod call
Application
Application
9
Application Domains

• Isolated execution space for applications
• Independent of OS concept of thread, process

Process
Process
AppDomain
AppDomain
AppDomain
Object
Object
Object
Object
Object
10
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

AppDomain
Context
Context
Object
Object
Object
Object
11
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

12
Section 2 Remoting Architecture

• What Messages
• Where Channels
• How Formatters
• Marshaling Concepts
• Proxies

13
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

14
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

Channel
Server
Client
"Proxy"
Dis-patcher
15
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

16
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

17
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

18
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

19
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

Channel
Client
"Proxy"
IMessageSink
SynchProcessMessage()or AsynchProcessMessage()
20
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

21
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

22
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

23
Proxies illustrated
Channel
Client
Server
"Proxy"
IMessageSink
Transparent Proxy
builds
MethodA()
RealProxy
MethodB()
Invoke()
PropertyQ
PropertyP
FieldX
SyncProcessMessage()
FieldY
24
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

25
The Dispatcher illustrated
Channel
Server
Client
Dispatcher
actual method calls
Object
MethodA()
StackBuilderSink
MethodB()
PropertyQ
PropertyP
FieldX
SyncDispatchMessage()
FieldY
26
Channel Sinks

• Formatter, dispatcher and transport are in sinks
• All channel sinks are linked in chains

Server
Client
Server Object
Client Object
Proxy
StackBuilderSink
Formatter Sink
Formatter Sink
Transport Sink
Transport Sink
27
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

28
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

29
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

30
Context Attributes and Properties
System.ContextBoundObject
Yes! Use existing context.
new
No! Create new context.
Context-Bound Class
IsContextOK() ?
Attribute
1
2
create object
3
No! GetPropertiesForNewContext() !
Property
31
Interception Message Chains

• Every message passes a four chains of sinks
• Context properties contribute these sinks
• Custom attributes allow intercepting all traffic

Server
Client
Channel
Server Envoy Chain
Client Context Chain
Server Context Chain
ServerObject Chain
32
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

33
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
Property contributes sink for server context
chain
Context Property
34
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

35
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()

36
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

37
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

38
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

39
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

40
Server Setup Example
... HttpChannel chan new HttpChannel(8080) Cha
nnelServices.RegisterChannel(chan) RemotingConfi
guration. RegisterWellKnownServiceType(
typeof(ServerClass), "MyEndpointURI",
WellKnownObjectMode.SingleCall)
Channel registration
Object registration
Registers the single-call endpointhttp//myserve
r8080/MyEndpointURI

• Channels and Objects are AppDomain-Global

41
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"

42
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

43
Activation illustrated
tcp//server8501/uriD
http//server8080/uriB
TCP8501
HTTP8080
RemotingServices.Connect()
AppDomain
Identity Table
Activator.GetObject()
uriA
uriB
uriC
uriD
Languagebinding
Context
Object
Object
o Activator.GetObject("http//...")o.methodCal
l()
Object
Object
o new myClass()o.methodCall()
44
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

45
Server System Configuration

type"System.Runtime.Remoting.Channels.Http.HttpCh
annel, System.Runtime.Remoting"
/
type"System.Runtime.Remoting.Channels.
SoapServerFormatterSinkProvi
der, System.Runtime.Remoting
" / s
Declare channel
Specify formatter
46
Server Application Configuration


objectUri"Foo.soap
mode"Singleton" /
name"MyHttpChannel" port"9000"
ref"soap" /


Declare singleton service endpoint
Associate channel with application
Associate formatter with channel
47
Section 5 Putting It Together

• Variations of Objects
• Context Attributes and Interception

48
Variations of Objects 1/2

• Agile (never marshaled)
• public class MySimpleObject public
  MySimpleObject()
• Agile (marshal-by-value)
• serializablepublic class MySimpleObject
  public MySimpleObject()

49
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()

50
Context Attributes Interception 1/3

• A Simple Context Attribute

public class CallTraceAttribute
ContextAttribute public CallTraceAttribute()
base("CallTraceAttribute")
public override bool IsContextOK( Context ctx,
IConstructionCallMessag
e ctorMsg) return false
public override void GetPropertiesForNewContext(
IConstructionCallMessa
ge ctorMsg) CallTraceProperty prop new
CallTraceProperty() ctorMsg.ContextProperties
.Add(prop)
false forces new context
install property
51
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(IMessage
Sink next) return new CallTraceObjectSink(
this, next)
Installed props check context
Installs sink on runtime request.
52
Context Attributes Interception 3/3

• A Simple Message Sink

Dumps content of IMessage for each call
public class CallTraceObjectSink
IMessageSink private IMessageSink
_nextSink public CallTraceObjectSink(CallTrace
Property 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(reqMs
g, reply) public IMessageSink NextSink
get return _nextSink
Next sink receives control thereafter
53
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

54
Questions?