540 likes | 666 Views
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
E N D
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 Trading Partners .NETBuilding Block Services (“Hailstorm“) EDIFACT Open Standards: TCP/IP XML HTTP SMTPSOAP X12 Financial WebServiceProviders News Enterprise Applications B2B Website Sales Procurement SQL ServerXML .NETEnterprise Servers Knowledge Management Accounting Organisation BizTalkMessaging ExchangeWebStorage
Messages – RPC is not all bidirectionalmessage exchange Application Application MessageQueue queuedmessage exchange unidirectionalmethod call bidirectionalmethod call Application Application
Application Domains • Isolated execution space for applications • Independent of OS concept of thread, process Process Process AppDomain AppDomain AppDomain Object Object Object Object Object
remoting boundary Object Object Object RqTx Sync Thrd 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
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 Channel Client Server "Proxy" Dis-patcher
SOAP, Binary, Custom decode from wire format Channel encode into wire format 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
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 Channel Client "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
Proxies illustrated Channel Client Server "Proxy" IMessageSink Transparent Proxy builds MethodA() RealProxy MethodB() Invoke() PropertyQ PropertyP FieldX SyncProcessMessage() FieldY
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 Channel Client Server Dispatcher actual method calls Object MethodA() StackBuilderSink MethodB() PropertyQ PropertyP FieldX SyncDispatchMessage() FieldY
Custom Sinks Custom Sinks Custom Sinks Custom Sinks Custom Sinks Custom Sinks Channel Sinks • Formatter, dispatcher and transport are in sinks • All channel sinks are linked in chains Server Client Client Object Server Object Proxy StackBuilderSink Formatter Sink Formatter Sink Transport Sink 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
Object 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
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 ServerObject 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
Server 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
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); • Channels and Objects are AppDomain-Global Channel registration Object registration Registers the single-call endpoint:http://myserver:8080/MyEndpointURI
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 HTTP8080 TCP8501 RemotingServices.Connect() AppDomain Identity Table Activator.GetObject() uriA uriB uriC uriD Languagebinding Context Object Object o = Activator.GetObject("http://...")o.methodCall(); Object Object 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> Declare singleton service endpoint Associate channel with application 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 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); } } false forces new context install property