Presentation is loading. Please wait.

Presentation is loading. Please wait.

Develop Distributed Applications using .NET Remoting

Similar presentations


Presentation on theme: "Develop Distributed Applications using .NET Remoting"— Presentation transcript:

1 Develop Distributed Applications using .NET Remoting
KEY MESSAGE: .NET Remoting SLIDE BUILDS: None SLIDE SCRIPT: Hello and Welcome to this MSDN session on Developing Distributed Applications using .NET Remoting. My name is {insert name} [Do not use the term FIELDCONTENT] SLIDE TRANSITION: What we will cover. ADDITIONAL INFORMATION FOR PRESENTER: Loke Uei Developer Evangelist Microsoft Malaysia

2 What we will cover Introduction to .NET Remoting Not Exhaustive
DCOM vs. Remoting Configuring .NET Remote Applications Hosting .NET Remote Applications KEY MESSAGE: What will be covered. SLIDE BUILDS: None SLIDE SCRIPT: In this session you will get a feel for .NET remoting. This session is not designed to take an in-depth look at .NET remoting, however, it is designed to give you a firm foundation. At the beginning of the session you will look at how .NET compares to the classic COM\DCOM world. What is different about remoting compared to DCOM? What are the advantages? What are the disadvantages? Moving on, you will see how you can configure remoting applications, and the different types of remoting modes that are available. You will see how you can configure these different types, both programmatically and using configuration files. Once you understand how to configure these applications, you will see how you can host these remote applications. .NET Remote objects can be hosted using a number of different applications. Some of these hosting options include Console apps, Windows Forms, Internet Information Services, and Windows NT Services. SLIDE TRANSITION: Prerequisites. ADDITIONAL INFORMATION FOR PRESENTER:

3 Session Prerequisites
Experience With the Following .NET Framework Visual C#™, VB .NET, or C++ Web Services Distributed Computing Concepts KEY MESSAGE: Session Prerequisites SLIDE BUILDS: None SLIDE SCRIPT: This session assumes you have some programming experience with the .NET framework. All of the code examples are written in C#, however, if you’ve been exposed to VB.NET, and not C#, you shouldn’t have any problem picking up the concepts. Remoting is very similar in concept to web services, and although you do not need to have a thorough understanding of web services, it will help if you have been exposed to some type of web services, networking, or distributed programming environment. SLIDE TRANSITION: So why this presentation? ADDITIONAL INFORMATION FOR PRESENTER: Level 200

4 So Why This Presentation?
You know DCOM’s a pain if: You've ever wanted to control the channel or format, or anything else about the DCOM messages. You've ever wanted to trace or log DCOM messages. You've wanted to easily use DCOM over the internet with a variety of clients. You’ve ever wanted to quickly change configuration settings such as ports and channels. KEY MESSAGE: So why this presentation? SLIDE BUILDS: None SLIDE SCRIPT: You know that using the predecessor technology to .NET Remoting (DCOM) is a pain when… You’ve ever wanted to have granular control over the channel and formatter for DCOM messages. You ever wanted to easy trace or log DCOM messages, you now can with a tracking handler. You’ve ever wanted to easily configure your application post deployment. You now can with .NET Remoting Configuration files. You ever wanted to easily use DCOM over the internet with the overhead of ping mechanism for object lifetime and you wanted the ability to send requests easily over HTTP and Port 80 using standard protocols and formatters such as HTTP, XML, and SOAP. SLIDE TRANSITION: Agenda ADDITIONAL INFORMATION FOR PRESENTER:

5 Agenda Architecture and Terminology Web Services/DCOM Comparison
Server Activated Objects (SAO) Client Activated Objects (CAO) Configuration Hosting KEY MESSAGE: Agenda SLIDE BUILDS: None SLIDE SCRIPT: This session will cover many aspects of .NET remoting. At the beginning of this session, you see be introduced to an overview of the architecture of .NET remoting. You will then see how that architecture compares to web services, and how it compares to DCOM. Once you have an understanding of remoting architecture, you will delve a little deeper, into the various types of remotable objects. Objects can be remoted as either Server Activated Objects (also known as well-known objects), or Client Activated Objects. Using these objects, you learn how to configure them using configuration files and programmatically. The presentation will end by using everything you’ve learned to host your remote objects using Internet Information Servier (IIS) and a custom written Windows NT service. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

6 Architecture and Terminology Into to Remoting
Communication between Application Domains Usually Between Servers Protect IP / Source Code Replacement for DCOM Low Level Control KEY MESSAGE: Introduction SLIDE BUILDS: None SLIDE SCRIPT: Remoting can be thought of as communication between two Application Domains, or isolated processes. Typically you will perform remote function calls, and pass data, in the form of an object or objects between Application domains physically on different servers. Since you may be going across the network, you will need to consider building lightweight components to keep network traffic to a minimum. There are many reasons why you want to take advantage of remoting, some of them may include Protecting Source Code, Protecting Intelectual Property, such as a mathematical algorithm. or providing some type of service. Remoting can be thought of the .NET replacement for DCOM. In the classic COM world, DCOM was used to make remote object calls. There were a number of issues with DCOM, that made working with DCOM difficult. Some of them included non-standard server ports, which made working with firewalls difficult. DCOM also used a ping, to keep the objects alive between servers. This ping was an expensive overhead that is no longer needed in the .NET world. Remoting also gives you a low level control to the programming APIs. In Remoting you can configure the ports on the server you want to use. You can also configure the protocol you want to use. Currently the .NET framework comes with two standaard protocols for remoting: tcp:// and You also have the ability to create your own protocols. SLIDE TRANSITION: Some .NET Remoting Terminology ADDITIONAL INFORMATION FOR PRESENTER:

7 Architecture and Terminology Remoting Terminology
Application Domains Channels Formatters (SOAP / Binary) Server Activated Objects (Wellknown) Client Activated Objects KEY MESSAGE: Common Terms found in Remoting SLIDE BUILDS: None SLIDE SCRIPT: Application domains are process boundaries used to isolate applications. Because application domains provide a secure and versatile unit of processing, that the common language runtime can use to provide isolation between applications, you need a mechanism to cross application domain boundaries. One of those mechanisms is remoting. When you do cross application domains, you need to open a channel. Channels provide data transportation when a client calls a method on a remote object. .NET provides two default channels, HttpChannel and TcpChannel which use the Http protocol and tcp protocol respectively. Once a channel has been opened, the objects to be formatted to move across the channel. Again, .NET provides two default formatters, SOAP and Binary. SOAP formatters are normally used between a .NET and a non-.NET system. Binary formatted data is much more compact and is almost a straight memory dump to the network stream. Currently the binary formatters can only be used between two .NET systems. Objects that are passed between two application domains are usually run in one of two modes: Server Activated Objects, also known as well-known objects, and client activated objects. Server Activated Objects are objects whose lifetimes are directly controlled by the server. Client Activated Objects are objects that are called by the client, and can live as long as the client needs them. SLIDE TRANSITION: Taking a closer look at Application Domains. ADDITIONAL INFORMATION FOR PRESENTER:

8 Architecture and Terminology Application Domains
Process Boundary Provides Isolation Provides Protection Security KEY MESSAGE: A Closer Look at Application Domains SLIDE BUILDS: None SLIDE SCRIPT: Operating systems and runtime environments typically provide some form of isolation between applications. In .NET, this isolation is referred to as application domains. This isolation is necessary to ensure that code running in one application cannot adversely affect other, unrelated applications. By running each process in it’s own application domain, the .NET frame work provides protection against memory leaks and corruption. Each application domain, also runs under it’s own security to context to prevent tampering and unauthorized use and or exploits. SLIDE TRANSITION: Use channels to connect to application domains. ADDITIONAL INFORMATION FOR PRESENTER:

9 Architecture and Terminology Channels
Transport Data Two Default Formats- or tcp:// - good for firewalls Tcp:// - high speed, binary Port Agnostic Create Your Own KEY MESSAGE: Channels SLIDE BUILDS: None SLIDE SCRIPT: Channels provide a means of communication between application domains. There are two default protocols that .NET provides out of the box for remoting, they include http and tcp. Http can be considered a firewall friendly protocol and is usually used if the architecture requires remoting across the internet. Typically the http protocol is used with the SOAP formatter. The tcp protcol is usually used for intranet environments, and is less firewall friendly. However, tcp is a much more compact protocol, providing faster network communication. Typically the tcp protocol is used with the binary formatter. Channels are port agnostic, and are not limited to any specific port. You can associate any unused port on the client or server with a channel. If neither the http or tcp channels meet your needs, the .NET framework allows you to create your own custom channels. SLIDE TRANSITION: .NET Remoting Formatters ADDITIONAL INFORMATION FOR PRESENTER:

10 Architecture and Terminology Formatters
Turn Message Into Stream Binary Soap 1.1 Compliant KEY MESSAGE: Formatters control the way the message is constructed. SLIDE BUILDS: None SLIDE SCRIPT: Formatters are used to move the remote objects over the channels. Objects are formatted into the network stream. There are two formatters that come with .NET, the Binary formatter and the SOAP formatter. The Binary formatter can be thought of as a memory dump to the channel, while the SOAP formatter is clear text and is SOAP 1.1 compliant. SLIDE TRANSITION: Use remoting channels and the SOAP formatter to talk to non-.NET systems. ADDITIONAL INFORMATION FOR PRESENTER:

11 Architecture and Terminology .NET to Non-.NET
SOAP 1.1 Specification Simple Datatypes int float string KEY MESSAGE: .NET Remoting can be used to communicate with systems built by other vendors on other platforms using Http requests and responses. SLIDE BUILDS: None SLIDE SCRIPT: .NET makes it easy to talk to non-.NET systems using the SOAP 1.1 protocol. Although the SOAP formatter can be used over the tcp protocol, typically when interacting with non-.NET systems, the http protocol is used. When you are talking to non-.NET systems, you will need to check what types of data types the remote system will be able to handle. Typically you will be limited to primitives such as ints, floats, or strings. SLIDE TRANSITION: Look at .NET to .NET Systems. ADDITIONAL INFORMATION FOR PRESENTER:

12 Architecture and Terminology .NET to .NET
Rich Functionality Almost any CLS Object DataSets Hashtables Custom Objects Binary Fast KEY MESSAGE: .NET Remoting has it’s fullest functionality when communicating with .NET Framework based systems on both ends of the communication channel. SLIDE BUILDS: None SLIDE SCRIPT: .NET remoting provides rich functionality. Almost anything you can represent in C#, Visual Basic® .NET or a CLS compliant compiler can be remoted. Some of the objects that can be remoted include Classes, Fields, Properties, Methods, DataSets, Hashtables, Lists, etc. These objects can Marshal By Value or Marshal By Reference with a lifetime. Because you will be talking directly to another .NET system, you will want to use the binary formatter, which is much faster than the SOAP 1.1 formatter. The binary formatter provides a binary encoding compact format, and in many cases just copies in-memory bytes into network stream. The only case in which you might want to use the HTTP/SOAP combination is when firewalls must be bypassed by using Port 80 and it is unfeasible to open additional ports for TCP communication. SLIDE TRANSITION: Demonstration 1 ADDITIONAL INFORMATION FOR PRESENTER:

13 Demonstration 1 Simple Demo Concepts
KEY MESSAGE: Demonstrate remoting a data access object. SLIDE BUILDS: SLIDE SCRIPT: In this demonstration you will see how to remotely call a data access class. The data access class exposes a method called GetProducts() to return a DataTable of products. SLIDE TRANSITION: Next Agenda Item ADDITIONAL INFORMATION FOR PRESENTER:

14 Agenda Architecture and Terminology Web Services/DCOM Comparison
Server Activated Objects (SAO) Client Activated Objects (CAO) Configuration Hosting KEY MESSAGE: In the next agenda item you’ll understand the differences between using Web Services, DCOM and .NET Remoting. SLIDE BUILDS: None SLIDE SCRIPT: This section will compare web services to .NET remoting and DCOM to .NET remoting. SLIDE TRANSITION: .NET Remoting compared to Web Services ADDITIONAL INFORMATION FOR PRESENTER:

15 Web Services/DCOM Web Services
Remoting KEY MESSAGE: Web Services Compared to .NET Remoting SLIDE BUILDS: None SLIDE SCRIPT: Web services are only hosted in Internet Information Server (IIS). Web servers also use the protocol and are formatted to SOAP using the Web Services Description Language (WSDL). .NET remoting, however, can be hosted in many different applications. These applications can include IIS, a windows form, a windows service or a console application. Although .NET remoting can take advantage of the protocol, it is not limited to that protocol only. .NET also can use the tcp:// protocol out of the box, and provides you the ability to create your own custom protocols. Although you can format your .NET remote objects using the WSDL specification for SOAP, .NET remoting also allows you to format your objects using binary encoding. SLIDE TRANSITION: Now compare .NET remoting to DCOM. ADDITIONAL INFORMATION FOR PRESENTER: Any Application IIS WinForm Windows® Service Console Application Multiple Protocols Tcp:// Custom Binary or Soap Only IIS Only WSDL

16 Web Services/DCOM DCOM
Remoting KEY MESSAGE: DCOM Compared to .NET Remoting SLIDE BUILDS: None SLIDE SCRIPT: In DCOM, your protocol is already chosen and limited to the RPC protocol. This protocol is not very firewall friendly and sometimes can violate a corporations security policy. DCOM also uses a ping mechanism from the client to inform the server which methods its using and what objects to keep alive. This mechanism does not scale well to internet focused solutions. .NET remoting, however, allows you to choose your own protocol. You can choose tcp://, or you can create your own protocol. You can also configure remoting to be firewall friendly and to specifically use certain ports. Because .NET remoting can also be hosted from a number of applications, including IIS, Windows forms, or Windows services, it gives you the capability to provide a tighter security model. SLIDE TRANSITION: Next Agenda Item. ADDITIONAL INFORMATION FOR PRESENTER: Choose Protocol Create Protocol Firewall Friendly Custom Ports Define Protcol Tighter Security Custom IIS NT RPC Protocol Not Firewall Friendly Pings for Lifetime

17 Agenda Architecture and Terminology Web Services/DCOM Comparison
Server Activated Objects (SAO) Client Activated Objects (CAO) Configuration Hosting KEY MESSAGE: Agenda SLIDE BUILDS: None SLIDE SCRIPT: This section delves deeper into remoting and will cover Server Activated Objects, also known as well-known objects. SLIDE TRANSITION: What are Serve Activated Objects? ADDITIONAL INFORMATION FOR PRESENTER:

18 Server Activated Objects Server Activated Objects
Well-known SingleCall Singleton Marshaling Configuration KEY MESSAGE: Understanding Server Activated Objects SLIDE BUILDS: None SLIDE SCRIPT: Server Activated Objects are also referred to as well-known objects. In fact the phrase ‘well-known objects’ can be interchanged with the phrase ‘server activated objects’. Server activated objects are considered well-known because the end point is considered well-known by the client. Well-known objects must be specified as being SingleCall or Singleton. SingleCall objects are only used once and destroyed. Singleton objects have one instance running on the server, and can service multiple clients. The objects can be marshaled either by reference or by value across the network. If an object needs to be passed by value, it needs to be marked as being serializable or implement ISerializable. Like all other remoting objects, Server Activated Objects can be configured using configuration files or they can be programmatically configured. SLIDE TRANSITION: Deeper look at well-known objects. ADDITIONAL INFORMATION FOR PRESENTER:

19 Server Activated Objects Well-Known
Client Must Know The Endpoint (URI) Server Controls Object <wellknown> RegisterWellKnownServiceType() KEY MESSAGE: Understanding Well-known Objects SLIDE BUILDS: None SLIDE SCRIPT: For well-known objects, a URI is used for identification. The client uses that URI to find the end point of the object, hence the object is considered well-known. Well-known objects’ lifetimes are directly controlled by the server. The server application domain creates these objects only when the client makes a method call on the object, not when the client calls new (New() in Visual Basic) or Activator.GetObject(); this saves a network round trip solely for the purpose of instance creation. Well-known objects can be configured by using a configuration file or programmatically. To configure a well-known object from a configuration file, the <wellknown> tag is used. You will cover this tag in greater detail in a few slides. To configure a well-known object programmatically, you use the RegisterWellKnownServiceType() method of the RemotingConfiguration class. SLIDE TRANSITION: SingleCall Mode ADDITIONAL INFORMATION FOR PRESENTER:

20 Server Activated Objects SingleCall
Object Created On Each Call One Instance Per Client Request No State Server Farm Friendly <wellknown Mode=“SingleCall”/> KEY MESSAGE: Understanding SingleCall Objects compared to Singleton Objects. SLIDE BUILDS: None SLIDE SCRIPT: Well-known objects must be specified as SingleCall or Singleton. SingleCall objects are created and destroyed each time they are called. Therefore the next method invocation will be serviced by a different server instance, even if the previous instance has not yet been recycled by the system. SingleCall objects do not maintain any state, and therefore all properties must be passed as arguments in a method. They are considered server farm friendly because it doesn’t matter if a client connects up to a different server. To declare a well-known object as SingleCall, you use the attribute moide=“SingleCall”, inside of the <wellknown /> tag. For example: <wellknown mode=“SingleCall” />. You can also specify whether an object is SingleCall when you programatically register on a object on the server end. To do this you simply pass an enumeration of type WellKnownObject to the constructor of the RegisterWellKnownType() method of the RemotingConfiguration class. SLIDE TRANSITION: Contrasted with Singletons ADDITIONAL INFORMATION FOR PRESENTER:

21 Server Activated Objects Singleton
One Object On Server Has Lifetime Default 5 Minutes Can Override Shared Between Multiple Clients KEY MESSAGE: Singleton SLIDE BUILDS: None SLIDE SCRIPT: Singleton types never have more than one instance existing at any one time. If an instance exists, all client requests are serviced by that instance. If one does not exist, the server creates an instance and all subsequent client requests will be serviced by that instance. Because Singleton-mode types do have a default lifetime, of 5 minutes, clients may not always receive a reference to the same instance of the remotable class, even if there is never more than one instance available at any one time. This is because the server object may expire between client calls. It is possible to override the 5 minute setting both programmatically or through configuration files. SLIDE TRANSITION: Marshalling ADDITIONAL INFORMATION FOR PRESENTER:

22 Server Activated Objects Marshaling
Marshall by Value Object Serialized Attribute [Serializable] Implement ISerializable Marshall by Reference Inherit System.MarshalByRefObject Proxy Class KEY MESSAGE: Marshalling objects via .NET Remoting SLIDE BUILDS: None SLIDE SCRIPT: Marshalling is a term used when an object is converted so that it can be sent across application domains. Unmarshaling creates an object from marshaled data. There are two types of marshaling: Marshal by value, and marshal by reference. Objects passed as marshal by value must either implement ISerializable or must be marked Serializable. When a call is made to a object by value, the remoting system makes a complete copy of these objects and passes the copy to the calling application domain. Once the copy is in the caller's application domain, calls to it are direct to that copy. You should use marshaled by value objects when it makes sense for performance or processing reasons to move the complete state of the object and any executable functionality to the target application domain. In many scenarios, this reduces lengthy, resource-consuming round trips across network, process, and application domain boundaries. Marshal-by-reference (MBR) objects are remotable objects that extend at least System.MarshalByRefObject. When a client creates an instance of an MBR object in its own application domain, the .NET Remoting infrastructure creates a proxy object in the caller's application domain that represents the marshal by reference object and returns to the caller a reference to that proxy. The client then makes calls on the proxy; remoting marshals those calls, sends them back to the originating application domain, and invokes the call on the actual object. You should use marshal by reference objects when the state of the object and any executable functionality should stay in the application domain in which it was created. SLIDE TRANSITION: Configuration for .NET Remoting ADDITIONAL INFORMATION FOR PRESENTER:

23 Server Activated Objects Server Configuration
Config file <wellknown mode=“SingleCall” or “Singleton” type=“type,assembly” objectUri=“myobject” /> Programmatic Create Wellknown Type Register KEY MESSAGE: Configuration SLIDE BUILDS: None SLIDE SCRIPT: As mentioned earlier, well-known objects can be configured using configuration files or they can be programmatically configured. To use a configuration file, you need to specify the <wellknown /> tag. The <wellknown /> tag has three attributes: mode, type, and objectUri. The mode is going to be either SingleCall or Singleton. The Type specifies the full type name of the object and the assembly name of the type implementation. This includes version, culture, and public key information if the containing assembly is in the global assembly cache. The objectUri specifies the endpoint of the object's Uniform Resource Identifier (URI). There are two steps required to programmatically configure a well-known object. The first step requires you to create the wellknown type, using WellKnownServiceTypeEntry() and then registering that entry with RegisterWellKnownServiceType(). SLIDE TRANSITION: Demonstration 2 ADDITIONAL INFORMATION FOR PRESENTER:

24 Demonstration 2 Server Activated Objects Singlecall Singleton Utilizing State
KEY MESSAGE: Demo using a SingleCall object, Singleton object, and their statelessness. SLIDE BUILDS: SLIDE SCRIPT: In this demonstration you will use SingleCall and Singleton objects. You will also see how SingleCall objects do not maintain any state while Singleton objects can maintain state across multiple client applications. SLIDE TRANSITION: Next Agenda Item ADDITIONAL INFORMATION FOR PRESENTER:

25 Agenda Architecture and Terminology Web Services/DCOM Comparison
Server Activated Objects (SAO) Client Activated Objects (CAO) Configuration Hosting KEY MESSAGE: Client Activated Objects are the second major way you can activate remote objects via .NET Remoting SLIDE BUILDS: None SLIDE SCRIPT: This section covers client activated objects. A client activated object is instantiated on the server when the client creates it, and not with ever method call, as you saw with the SingleCall object. Client activated objects are specific to the calling client and can maintain state for the client, but not across multiple client applications. SLIDE TRANSITION: Client Activated Objects in Detail ADDITIONAL INFORMATION FOR PRESENTER:

26 Client Activated Objects Client Activated Object (CAO)
Created by Calling Client Client Controls Lifetime Lease State For Individual Client Tracking Services KEY MESSAGE: Client Activated Objects in Detail SLIDE BUILDS: None SLIDE SCRIPT: Each time a client creates an instance of a client activated object, that instance will service only that particular reference in that particular client until its lease expires and its memory is recycled. When a client creates an object, it can specify a length of time, called a lease, that the object should exist. If the remote object reaches its lifetime limit, it contacts the client to ask whether it should continue to exist, and if so, for how much longer. Client activated objects also can maintain state, but only for the calling client. If a calling application domain creates two new instances of the remote type, each of the client references will invoke only the particular instance in the server application domain from which the reference was returned. A great feature for analyzing and monitoring client activated objects, that are marshaled by reference, is Tracking Services. To track an object, you only need to implement ITrackingHandler and register the tracking handler with the class TrackingServices. SLIDE TRANSITION: Client Activation ADDITIONAL INFORMATION FOR PRESENTER:

27 Client Activated Objects Client Activation
New() File Configuration <activated /> Activator.CreateInstance() Overloaded Pass In Url, Assembly Attributes KEY MESSAGE: Client Activation SLIDE BUILDS: None SLIDE SCRIPT: In order to use the New() command to instantiate a client activated object, the client application must be configured using a configuration file. The configuration file must use the <activated /> tag, instead of the <wellknown /> tag. Besides using the New() command, you can also use the Activator.CreateInstace() to create the remote object. By using Activator.CreateInstance(), you do not need to use configuration files. This method is overloaded, and accepts a URL to the remote object, along with an object array of assembly attributes. SLIDE TRANSITION: Configuration Properties ADDITIONAL INFORMATION FOR PRESENTER:

28 Client Activated Objects Configuration Properties
Config file <activated type="type,assembly" /> Programmatic UrlAttribute Activator.CreateInstance KEY MESSAGE: Configuration Properties SLIDE BUILDS: None SLIDE SCRIPT: The <activated /> configuration tag only has one required attribute, type. Type specifies the full type name of the object and the name of the assembly that contains the type implementation. This includes version, culture, and public key information if the containing assembly is in the global assembly cache. To programmatically configure a client activated object, two steps are created. First, you need to build an array of UrlAttributes to tell the client where the remote object is located. Once we have the array, we pass it into to the Activator.CreateInstance() method. The CreateInstance() method will return a reference to our remote object. Because the object is actually instantiated at the request of the client, we have the option to pass default constructors to the remote object. SLIDE TRANSITION: Lifetime (Lease) of Client Activated Objects ADDITIONAL INFORMATION FOR PRESENTER:

29 Client Activated Objects Lease
In DCOM – Ping High Overhead Not Suited for Internet Lease-based Mechanism Set Default Lifetime (min, sec, etc..) Sponsors Renew KEY MESSAGE: Understanding Leases and Remote Objects SLIDE BUILDS: None SLIDE SCRIPT: In the DCOM world, DCOM use to use a RPC ping to keep remote objects alive. This method was burdensome and had a high overhead of cost. Due to the about of traffic generated by the RPC ping, this method is not really suited for the internet. In the .NET world, remoting introduced the concept of a lease-based lifetime. With leases, the client and server can set up a contract to determine how long the object will live. The object can live for seconds or minutes. The client can also set up a sponsor that will renew the lease on be-half of the client. By using a sponsor, the client does not have to rely on calling another method to keep the remote object alive. SLIDE TRANSITION: Lease Properties ADDITIONAL INFORMATION FOR PRESENTER:

30 Client Activated Objects Properties
Lease Time Default 5 Minutes Set 0 to Infinite Sponsors Listens from Server Application GetLifeTimeService() Renewal() KEY MESSAGE: Lease Properties SLIDE BUILDS: None SLIDE SCRIPT: By default, a lease expires in 5 minutes. However, that number can be changed programmatically, or a setting in the remoting configuration files. A lease can be set to expire immedately, i.e. 0 minutes, or it can be set to run to infinity. If you don’t want to depend upon the client to invoke methods, and thereby extending the lifetime of the object, you can designate a sponsor. The sponsor can extend the lease of the remote object. If the leasing time expires, the sponsor is asked if it wants to extend the lease. To determine how much time is left on a lease, you can call the GetLifeTimeService() method. If you know you need to extend the lease, you call the Renewal() method. SLIDE TRANSITION: Tracking Remote Objects ADDITIONAL INFORMATION FOR PRESENTER:

31 Client Activated Objects Tracking
Implement ITrackingHandler DisconnectedObject () MarshaledObject () UnmarshaledObject () RegisterTrackingHandler( ITrackingHandler) KEY MESSAGE: Tracking Services SLIDE BUILDS: None SLIDE SCRIPT: Objects that are marshaled by refercence can be analyzed and tracked via tracking services. It is very easy to use tracking services. First you need to create an object that implements ITrackingHandler, and then you need to register the tracking object. ITrackingHandler had 3 methods DisconnectedObject(), MashaledObject(), and UnmarshaledObject(). Inside of these methods you can implement your custom logging. Logging can occur to a file, database, alerts, or even to the system event logs. As a brief overview, here is a little description about the 3 methods: The DisconnectedObject() notifies the current instance that an object has been disconnected from its proxy. The MarshaledObject() notifies the current instance that an object has been marshaled. The UnmarshaledObject() Notifies the current instance that an object has been unmarshaled. SLIDE TRANSITION: Demonstration 3 ADDITIONAL INFORMATION FOR PRESENTER:

32 Demonstration 3 CAO Demo CAO Demo Lease Demo Maintain State Tracking Remote Actions
KEY MESSAGE: Demo Client Activated Objects (CAO), working with leases, client state, and tracking services. SLIDE BUILDS: SLIDE SCRIPT: In this demonstration you will see how to use Client Activated Objects. You will see how you can set the lease times, and monitor that lease time through a Windows Form application. Once you’ve been exposed to the client activated objects, you will see how a client object can maintain it’s own state, and how clients can be analyzed and tracked using tracking services. SLIDE TRANSITION: Configuration agenda item ADDITIONAL INFORMATION FOR PRESENTER:

33 Agenda Architecture and Terminology Web Services/DCOM Comparison
Server Activated Objects (SAO) Client Activated Objects (CAO) Configuration Hosting KEY MESSAGE: Agenda SLIDE BUILDS: None SLIDE SCRIPT: This section covers configuration in more detail. It covers the details of configuring remote objects with files and then moves on to programmatic configuration. SLIDE TRANSITION: File Configuration ADDITIONAL INFORMATION FOR PRESENTER:

34 Configuration File Configuration
XML Easy To Read Easy To Modify Simple To Code No Need to Recompile KEY MESSAGE: File Configuration Overview SLIDE BUILDS: None SLIDE SCRIPT: Remoting configuration files follow the XML format. They are simply a clear text file, and can be read and\or modified in any text editor, such as notepad. Because they follow XML rules, they are very easy to code, create and edit. The biggest advantage for using configuration files is because there isn’t a need to recompile the application. You simply make the changes to the file and save it. Depending upon how your application monitors the files, the application could make changes immediately, or it may need to be restarted. SLIDE TRANSITION: File Format for Configuration Files ADDITIONAL INFORMATION FOR PRESENTER:

35 Configuration File Format
<System.Runtime.Remoting> <application> </application> </System.Runtime.Remoting> </configuration> KEY MESSAGE: General Configuration File Format for .NET Remoting. SLIDE BUILDS: None SLIDE SCRIPT: Because the configuration file follows XML rules, it has a number of nodes. All of the files have the following nodes: <configuration>, <System.Runtime.Remoting>, and <application>. The data found in the <application> will vary depending upon if the remote object is either a well-known object, or a client activated object. SLIDE TRANSITION: Server Activated Objects ADDITIONAL INFORMATION FOR PRESENTER:

36 Configuration File - Well-known Objects
<service> <wellknown type=“Namespace.Class, Assembly” objectUri=“Data” mode=“Singleton” /> </service> KEY MESSAGE: Well-known objects SLIDE BUILDS: None SLIDE SCRIPT: To a mark an object as well-known, you need to use the <wellknown> tag. The <wellknown> tag contains information about server-activated (well-known) objects the application exposes. It can occur one or more times in the <service> element. The <wellknown> tag has three required attributes: mode, type, and objectUri. Mode indicates whether the object is a Singleton or SingleCall object. One option MUST be selected. Type specifies the full type name of the object and the assembly name of the type implementation. This includes version, culture, and public key information if the containing assembly is in the global assembly cache. ObjectUri Specifies the endpoint of the object's Uniform Resource Identifier (URI). SLIDE TRANSITION: Client Activated Objects ADDITIONAL INFORMATION FOR PRESENTER:

37 Configuration File - Client Activiated Objects
<service> <activated type=“Namespace.Class, Assembly” /> </service> KEY MESSAGE: Client Activated Objects SLIDE BUILDS: None SLIDE SCRIPT: To mark an object as being client activated, you need to use the <activated> tag instead of the <wellknown> tag. The <activated> tag only has one attribute, type. Just like well-known objects, type specifies the full type name of the object and the name of the assembly that contains the type implementation. This includes version, culture, and public key information if the containing assembly is in the global assembly cache. SLIDE TRANSITION: Registering Configuration Files ADDITIONAL INFORMATION FOR PRESENTER:

38 Configuration RemotingConfiguration Class
RemotingConfiguration.Configure(“configuration file”) Method works for server and client configuration KEY MESSAGE: Register a Configuration File SLIDE BUILDS: None SLIDE SCRIPT: Once you’ve built your configuration file, it is extremely easy to use it. In fact, only one line of code is required to use a configuration file, and that line is RemotingConfiguration.Configure( “configuration file” );. This method works at both the client and the server. SLIDE TRANSITION: Programmatic Configuration ADDITIONAL INFORMATION FOR PRESENTER:

39 Configuration Programmatic Configuration
Hide Property Information Required Recompile Dynamic Easy To Deploy KEY MESSAGE: Programmatic Configuration SLIDE BUILDS: None SLIDE SCRIPT: There are a number of differences when using programmatic configuration instead of file configuration. Programmatic configuration hides all of the details of the application, inside of the application itself. However, because this information is actually inside of the application, any changes to the configuration will require the application to be recompiled. One advantage of using programmatic configuration, is that you may not know the configuration parameters at design time, so you may need to dynamically determine and create the configuration properties at runtime. Not using configuration files makes the application easier to deploy, because you do not need to worry about extra files, only the application itself. SLIDE TRANSITION: Programmatic Configuration Steps ADDITIONAL INFORMATION FOR PRESENTER:

40 Configuration Programmatic Configuration
Create Channel Register Channel Create Remote Object Register Object with Remoting Configuration KEY MESSAGE: Steps to use programmatic configuration. SLIDE BUILDS: None SLIDE SCRIPT: When you configure your application, you need to perform four basic steps. First you need to create the channel that will be used between the application domains. The channel can be a HttpChannel or a TcpChannel. Once you’ve created your channel, you will need to register the channel with ChannelServices(). Now that you have a channel to use, you need to instantiate your remote object. The object will be created using as a ActivatedServiceTypeEntry for client activated objects, or WellKnownServiceTypeEntry for well-known objects. Now that you have your remote object, the last thing you need to do is register the object with RemotingConfiguration as either a ActivatedServiceType or a WellKnownServiceType. SLIDE TRANSITION: Configure Server. ADDITIONAL INFORMATION FOR PRESENTER:

41 Configuration Programmatic Configuration - Server
ChannelServices.RegisterChannel(new HttpChannel(8080)); RemotingConfiguration.ApplicationName = "Data"; RemotingConfiguration.RegisterWellKnownServiceType(typeof(RemoteObject.DataAccess), "Data", WellKnownObjectMode.SingleCall); KEY MESSAGE: Configure the remote server. SLIDE BUILDS: None SLIDE SCRIPT: Here is an example to configure a server that will host a well-known object. First a HttpChannel at port 8080 is created and registered with ChannelServices. Then, the application is given a name to be used at the server, called Data. Finally, the object is registered using RemotingConfiguration as a well-known object using RegisterWellKnownServiceType(). RegisterWellKnownServiceType() has multiple overloaded methods. In this example, the typeof object is passed in, along with the Application name ‘Data’, and finally the well-known object is marked as being SingleCall. SLIDE TRANSITION: Configure the client. ADDITIONAL INFORMATION FOR PRESENTER:

42 Configuration Programmatic Configuration - Client
ChannelServices.RegisterChannel(new TcpServerChannel( 6789 ) ); ActivatedServiceTypeEntry obj = new ActivatedServiceTypeEntry( "RemoteObject.DataAccess", "RemoteObject"); RemotingConfiguration.RegisterActivatedServiceType( obj ); KEY MESSAGE: Configure the Client SLIDE BUILDS: None SLIDE SCRIPT: Configuring a client is very similar to configuring the server. In this example you are configuring a client activated object. First you are creating and registering a TcpChannel at port It doesn’t matter what port you use, as long as it is available on the client, and is the port the server is using. The next step declares the object as being client activated by using the ActivatedServiceType entry. Now that you have the object declared you register the object with RemotingConfiguration. SLIDE TRANSITION: Demonstration ADDITIONAL INFORMATION FOR PRESENTER:

43 Demonstration 4 Configuration Programmatic - Client Programmatic - Server
KEY MESSAGE: Demo on Programmatically configuring a client and server. SLIDE BUILDS: SLIDE SCRIPT: In this demonstration you will see how to programmatically configure a client and then a sever. SLIDE TRANSITION: Hosting agenda item. ADDITIONAL INFORMATION FOR PRESENTER:

44 Agenda Architecture and Terminology Web Services/DCOM Comparison
Server Activated Objects (SAO) Client Activated Objects (CAO) Configuration Hosting KEY MESSAGE: Hosting agenda item. SLIDE BUILDS: None SLIDE SCRIPT: This section will cover the different options used to host remote applications. SLIDE TRANSITION: Hosting options. ADDITIONAL INFORMATION FOR PRESENTER:

45 Hosting Hosting Options
Console Applications Windows Forms Applications IIS Windows NT Service KEY MESSAGE: Hosting Options SLIDE BUILDS: None SLIDE SCRIPT: There are numerous options you can use for hosting remote objects. Some of these options include Console based applications, windows forms applications, Internet Information Services (IIS), and using a Windows NT Services. Up to this point, you have been using console and windows forms applications. The remainder of this session will focus on using IIS and Windows NT Services for hosting remote applications. SLIDE TRANSITION: IIS and Windows Services ADDITIONAL INFORMATION FOR PRESENTER:

46 Hosting IIS and Windows Services
Built In Security Stable Windows Service Roll Your Own More Flexible KEY MESSAGE: IIS and Windows NT Service SLIDE BUILDS: None SLIDE SCRIPT: There are a number advantages to using IIS. IIS has built in security and can be configured from the IIS MMC Snap-in. IIS also has a built in security model, and can allow you to choose various methods of authentication. IIS is a very stable platform and with .NET Server has been integrated into the windows kernal. Windows services also has a number of advantages. By using a Windows NT service, you can create your own custom security model. You also have the flexibility to write everything from the ground up, from programmatic configuration of objects, to taking advantage of the built in service controller. SLIDE TRANSITION: IIS Configuration ADDITIONAL INFORMATION FOR PRESENTER:

47 Hosting IIS Configuration
Use Configuration File – Web.Config Remote Object - /bin Directory Place in Global Assembly Cache (Gacutil.exe) Must Use HttpChannel Can Use Binary Formatter Object URI ends in .rem or .soap KEY MESSAGE: IIS Configuration SLIDE BUILDS: None SLIDE SCRIPT: When you use IIS to host your remote type, you cannot programmatically configure the remoting system for your remotable type, since the host application domain is created by IIS and ASP.NET. To use the configuration file to configure remoting, you must place your configuration information in the Web.config file in that virtual directory. You must also place your remotable type implementation in the \bin directory (or use the Global Assembly Cache tool, Gacutil.exe, to place it in the global assembly cache). Because IIS uses HTTP natively, you can only use the HttpChannel for remoting. Using IIS makes it ideal for hosting remote internet applications. Although you can’t use the TcpChannel, that doesn’t mean you can’t use the binary formatter to provide you with a better compression method when transferring your objects across application domains. When hosting well-known objects, the URI must end in .rem or .soap. IIS will recognize that extension and pass it off the .NET framework as a remotable object. SLIDE TRANSITION: Windows Service Configuration ADDITIONAL INFORMATION FOR PRESENTER:

48 Hosting Windows Service
Project Built Into Visual Studio .NET Services.msc MMC Snap-in Any Channel Format HttpChannel TcpChannel Configuration Programmatic File KEY MESSAGE: Windows Services Configuration for Remote Objects SLIDE BUILDS: None SLIDE SCRIPT: There are a number of advantages to using Windows NT Services. It is easy to develop services in Visual Studio .NET, because it is built in as a project template. You can also control your service via the Services.msc MMC Snap-in. Windows Services are not limited to any channel format or port. You can use both HttpChannel or TcpChannel. You can select any port that is available on the machine. Unlike IIS, you can fully programmatically configure your remote application, or you can use configuration files. SLIDE TRANSITION: Demonstration 5 ADDITIONAL INFORMATION FOR PRESENTER:

49 Demonstration 5 Hosting Demo Windows Service
KEY MESSAGE: Demo on Hosting In IIS and Windows NT Services. SLIDE BUILDS: SLIDE SCRIPT: This demonstration will show you how to host remote objects in IIS and Windows NT Services. SLIDE TRANSITION: Session Summary ADDITIONAL INFORMATION FOR PRESENTER:

50 Session Summary Architecture and Terminology
Web Services/DCOM Comparison Server Activated Objects (SAO) Client Activated Objects (CAO) Configuration Hosting KEY MESSAGE: Summary SLIDE BUILDS: None SLIDE SCRIPT: This session has covered many aspects of .NET Remoting. You’ve been exposed to the overall architecture and the terminology associated with Remoting. You’ve seen how you can relate Remoting to Web Services and DCOM. You’ve also been exposed to the two types of remote objects: Server Activated Objects (also known as well-known objects) and Client Activated Objects. Server Activated Objects are controlled by the server and have two modes SingleCall and Singleton. Client Activated Objects are controlled by the client and are unique to the client. You’ve also seen how you can configure these objects using configuration files, or programmatically configure these objects. Once you’ve understood the configuration aspect, you were exposed to hosting these objects in IIS or as a Windows NT Service. SLIDE TRANSITION: Where to get more information. ADDITIONAL INFORMATION FOR PRESENTER:

51 For More Information… MSDN Web site at Got Dot Net ASP .NET
msdn.microsoft.com Got Dot Net ASP .NET KEY MESSAGE: Where to get more information SLIDE BUILDS: None SLIDE SCRIPT: The best place for additional information is on the web. You can go to msdn.microsoft.com for the Microsoft developer portal. Going to msdn.microsoft.com/net takes you to the portal for .NET information. In addition, gotdotnet is a great resource, with lots of sample code from Microsoft internals. SLIDE TRANSITION: Other websites ADDITIONAL INFORMATION FOR PRESENTER:

52 For More Information… Dot Net Remoting ASP .NET Directory
ASP .NET Directory KEY MESSAGE: Other websites SLIDE BUILDS: None SLIDE SCRIPT: For specific information on .NET remoting you may want to visit This website’s only focus is on .NET Remoting. Another place to look is the Largest ASP.NET Directory found at This directory links to various remoting articles located over the internet. SLIDE TRANSITION: MS Press ADDITIONAL INFORMATION FOR PRESENTER:

53 MS Press Essential Resources for Developers
Key Message: Talk about MS Press books and introduce the Build your own book feature SLIDE BUILDS: 2 SLIDE SCRIPT: [BUILD 1] Microsoft Press has released a number of books on the .NET framework. [BUILD 2] Have you ever looked at some of our books as just not bought them because there was only one chapter that interested you? Well now MS Press are offering the ability to create your own book from an ever growing selection of titles. Look through the Inside SQL and Inside Windows 2000 books and just pick a chapter from each, add a chapter on Office or Exchange. Build your own reference book then have it make into a MS Reader E-book, or a PDF file or even have it printed. Go to and try it for yourself. [Check the custom list to see if the books in build 1 are available – if not mention it in the script] SLIDE TRANSITION: MSDN ADDITIONAL INFORMATION: To find the latest developer related titles visit

54 MSDN Essential Resources for Developers
Subscription Services Library, OS, Professional, Enterprise, Universal Delivered via CD-ROM, DVD, Web Online Information MSDN Online, MSDN Flash KEY MESSAGE: MSDN SLIDE BUILDS: None SLIDE SCRIPT: MSDN is the essential resource for developers. It contains subscriptions, such as MSDN online and MSDN flash (as the MSDN web is becoming the central portal for developers). It has membership programs which are coordinated online as well as user groups. There are print publications as well as a variety of training and events - at local, national, and international levels. SLIDE TRANSITION: Where can I get MSDN? ADDITIONAL INFORMATION FOR PRESENTER: Training & Events MSDN Training, Tech-Ed, PDC, Developer Days, MSDN/Onsite Events Print Publications MSDN Magazine MSDN News Membership Programs MSDN User Groups

55 MSDN Subscriptions THE way to get Visual Studio .NET
Enterprise Architect Software and data modeling Enterprise templates Architectural guidance MSDN Universal $2799 new $2299 renewal/upgrade Enterprise Developer Enterprise lifecycle tools Team development support Core .NET Enterprise Servers MSDN Enterprise $2199 new $1599 renewal/upgrade With Visual Studio .NET we continue to have the Professional and Enterprise versions plus we are adding the Enterprise Architect version that provides the modeling and design tools for systematic design of applications. And to provide even broader coverage for developers, this month we introduced a new product line for MSDN, and announced that every version of Visual Studio .NET will have a corresponding version of MSDN, so developers will have the choice of whether to buy Visual Studio .NET – the packaged product, or MSDN – the subscription service. If asked for pricing, here are the pricing offerings for the MSDN Subscriptions: MSDN Universal $2799 new/ $2299 renewal/upgrade MSDN Enterprise $2199 new/$1599 renewal/upgrade MSDN Professional $1199 new/$899 renewal/upgrade MSDN OS $699 new/$499 renewal MSDN Library $199 new/$99 renewal Use this opportunity to discuss other MSDN offerings such as the MSDN Online website, MSDN local and national events, MSDN User Groups, the MSDN Magazine, and the MSDN Flash, etc. NEW Professional Tools to build applications and XML Web services for Windows and the Web MSDN Professional $1199 new $899 renewal/upgrade

56 Where Can I Get MSDN? Visit MSDN Online at msdn.microsoft.com
Register for the MSDN Flash Newsletter at msdn.microsoft.com/flash Become an MSDN CD Subscriber at msdn.microsoft.com/subscriptions MSDN online seminars msdn.mircosoft.com/training/seminars Attend More MSDN Events KEY MESSAGE: MSDN SLIDE BUILDS: None SLIDE SCRIPT: There is one place you should go to start: MSDN.MICROSOFT.COM There is one communication you should subscribe to: MSDN Flash. Twice monthly listserve for the developer community - focuses on news, information, resources and events Look for MSDN branded events - feature SLIDE TRANSITION: So the next step in your career cycle developing using Microsoft Technologies is to become an MCSD ADDITIONAL INFORMATION FOR PRESENTER:

57 Become A Microsoft Certified Solution Developer
What Is MCSD? Premium certification for professionals who design and develop custom business solutions How Do I attain MCSD Certification? It requires passing four exams to prove competency with Microsoft solution architecture, desktop applications, distributed application development, and development tools Where Do I Get More Information? For more information about certification requirements, exams, and training options, visit KEY MESSAGE: Explain the MCSD program SLIDE BUILDS: None SLIDE SCRIPT: The Microsoft Certified Solution Developer (MCSD) credential is the premium certification for professionals who design and develop custom business solutions with Microsoft development tools, technologies, and platforms. There is a new track which includes certification exams that test users’ ability to build Web-based, distributed, and commerce applications by using Microsoft’s products, such as Microsoft SQL™ Server, Microsoft Visual Studio, and Microsoft Component Services. For more information about the MCSD certification, please visit: SLIDE TRANSITION: That’s it. Signoff in you own way. ADDITIONAL INFORMATION FOR PRESENTER:

58


Download ppt "Develop Distributed Applications using .NET Remoting"

Similar presentations


Ads by Google