1 / 54

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

jasper-cline
Download Presentation

Context and Remoting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. 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

  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 Website Sales Procurement SQL ServerXML .NETEnterprise Servers Knowledge Management Accounting Organisation 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. 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

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

  15. 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

  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 Client Server Dispatcher actual method calls Object MethodA() StackBuilderSink MethodB() PropertyQ PropertyP FieldX SyncDispatchMessage() FieldY

  26. 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

  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. 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

  31. 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

  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. 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

  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); 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

  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://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();

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

  46. 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

  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) [serializable]public 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, IConstructionCallMessage ctorMsg) { return false; } public override void GetPropertiesForNewContext( IConstructionCallMessage ctorMsg) { CallTraceProperty prop = new CallTraceProperty();ctorMsg.ContextProperties.Add(prop); } } false forces new context install property

More Related