1 / 35

.NET Remoting

.NET Remoting. Amit Gupta, VI TE, SISL 2007-Jan. Topics…. What is Remoting Key Elements Remoting Architecture Configuration of Remote Applications Advantage’s and Disadvantage's Web Services Vs Remoting. Remoting.

tamira
Download Presentation

.NET 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. .NET Remoting Amit Gupta, VI TE, SISL 2007-Jan

  2. Topics….. • What is Remoting • Key Elements • Remoting Architecture • Configuration of Remote Applications • Advantage’s and Disadvantage's • Web Services Vs Remoting

  3. Remoting Remoting is a technology that allows programs and software components to interact across application domains, processes, and machine boundaries. This enables your applications to take advantage of remote resources in a networked environment.

  4. .NET Remoting Overview • .NET Remoting can be used for accessing objects in another application domain. .NET Remoting can always be used whether the two objects live in a single process, in a separate processes, or on separate systems. Process Process AppDomain AppDomain AppDomain Object Object Object Object Object

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

  6. Key Elements • Remote Object • Channel • Messages • Formatters • Formatter Provider • Proxy • Message Sinks • Utility Classes

  7. Remote Objects: A remote object is an object running on the server. The client doesn’t call methods on this object directly, but uses a proxy instead. With .NET it’s easy to distinguish remote object from local objects: The client can call methods of the remote objects via a proxy. Channel: A channel is used for communication between the client and the server. There are client and server parts of the channel. .NET framework 1.1 offers two channel types that communicate via TCP or HTTP. Messages: Messages are sent into the channel. Messages are created for communication between the client and the server. The messages hold the information about the remote object, the method name called , and all of the arguments.

  8. Formatter: The formatter defines how messages are transferred into the channel. SOAP: can be used to communicate with web services that are not based on .NET FW. Binary: are much fasters and can be used efficiently in an intranet environment Formatter Provider: A formatter provider is used to associate a formatter with a channel. By creating a channel , you can specify what formatter provider to use, and this in turn defines the formatter that is used to transfer the data into the channel. Proxy: The client calls methods on a proxy instead of the remote object. Two types of proxies: Transparent Proxies and the real proxies. Message Sink or Sink: A message sink , or sink for short , is an Interceptor object. Interceptors are used on both the client and the server. A sink is associated with the channel. The real proxies uses the message sink to pass the message into channel. And depending on where it is used , it is known as envoy sink, a server context sink , an object sink and so on…….

  9. Remoting Architecture

  10. Remoting Architecture

  11. Internals of Remoting • Remote objects • Channels • Formatters • Utility Classes • Proxy Objects • Messages • Object passing in Remote Methods

  12. Example: MarshallByRefObject Hello HelloClient +Greeting() +Main() HelloServer +Main()

  13. Remote Objects: • Remote objects are needed for distributed computing. • An object that should be called remotely from a different system must be derived from System.MarshalRefObject. • MarshalByRefObject objects are confined to the application domains: instead a proxy object is used to access remote object from another application domain. The other application domain can live inside the same process, in another process, or on another system . • The MarshalByRefObject class has, in addition to the inherited methods from the Object class, methods to initialize and to get lifetime services. The lifetime services define how long the remote Object lives

  14. Channels: • A channel is used to communicate between .NET client and a server. .NET framework 1.1 ships with channel classes that communicate using TCP and HTTP. • Both server and client application must create a channel. using System.Runtime.Remoting.Channels.Tcp; ………. TcpServerChannel channel= new TcpServerChannel (8086) Code to create a TcpServerChannel on the server side. • Creating a new channel instance immediately switches the socket to the listening state, which can be verified typing “netstat –a” at the command line. • A server can listen to multiple channels.

  15. Channels: • A channel class must implement the IChannel interface. The IChannel interface has these two properites: • ChannelName: is a read only property that returns the name of the channel. • ChannelPriority:is a read only property.More than one channel can be used for communication between a client and a server. The priority defines the order of the channel. On the client , the channel with highest priority is chosen first to connect to the server. • Additional interfaces are implemented depending on the whether the channel is client channel or a server channel. The server versions of the channels implement the IChannelReceiver interface, the client versions implement the IChannelSender interface.

  16. Channels: • The Client side IChannelSender has, in addition to IChannel , a single method called CreateMessageSink(), which returns an object that implements IMessageSink. The IMessageSink interface can be used for putting synchronous as well as asynchronous messages into the channel • The server side interface IChannelReceiver, the channel can be put into the listening mode using StartListening(), and stopped again with StopListening().

  17. Formatters: • The .NET framework delivers two formatter classes: System.Runtime.Serialization.Formatters.Binary.BinaryFormatter System.Runtime.Serialization.Formatters.Soap.SoapFormatter Formatters are associated with channels through formatter sink objects and formatter sink provider. Both the formatters contains the same information, but the Soap format is human readable and typically much larger than the binary format. In general , the binary formatter will output much smaller packet than will the SOAP formater.

  18. Utility Classes: ChannelServices and RemotingConfiguration • Channel service utility class is used to register channels into the .NET Remoting runtime. With this we can access all the registered channels • A channel is registered using the static method ChannelServices.RegisterChannel() • The ChannelService utility class can now be used to dispatch synchronous and asynchronous messages, and to unregister specific channels. • The RegisteredChannels property returns an IChannel array of all the channels we registered.

  19. Object Activation: • Clients can use and create remote Activator class. You can get a proxy to a server-activated or well–known remote object using the GetObject() method. The CreateInstance() method return a proxy to a client activated object. • Activating well-known object TcpClientChannel channel= new TcpClientChannel(); channelServices.RegisterChannel( channel ); Hello obj = (Hello) Activator.GetObject ( typeof (Hello ), “tcp://localhost:8086/Hi”) • GetObject is a static method of the class System.Activator that calls RemotingServices.Connect() to return a proxy object to the remote object. The proxy implements all the public methods and properties, so that the client can call these methods as it would on real object. • Instead of using Activator.GetObject(), you can also use RemotingServices.connect().

  20. Object Activation: • Activating client-activated objects • Activator.CreateInstance() creates a client-activated remote object. Using the Activator.GetObject() method, the remote object created on a method call, and is destroyed when the method is finished. • With the CreateInstance() method an activation sequence is started to create the remote object. The object lives until the lease time is expired and a garbage collection occurs.

  21. Proxy Objects: • The Activator.GetObject() and the Activator.CreateInstance() methods return a proxy to the client. • Two proxies: the transparent proxy and the real proxy • The transparent proxy looks like the remote object- it implements all the public methods of the remote object. These methods just call the Invoke() method of the Real proxy where a message containing the method to call is passed. • The real proxy send the message to the channel with the help of message sinks. • With the RemotingServices.IsTransparentProxy() , you can check if our object is really transparent proxy

  22. Utility Classes: ChannelServices and RemotingConfiguration • RemotingConfiguration class is another .NET remoting utility class. On the server side it’s used to register remote object types for server activated objects • Here is the server side code to register a well-known remote object type to the remotingServices: RemotingConfiguration.RegisterWellKnownServiceType( typeof(Hello), //Type “Hi” //URI WellKnownObjectMode.SingleCall //Mode The first argument specifies the type of the remote object. The second argument, “Hi”, is the uniform resource identifier of the remote object that the client uses to access the remote object. The last argument is the mode of the remote object. The mode can be a value of the WellKnownObjectMode enumeration: SingleCall or Singleton

  23. Utility Classes: ChannelServices and RemotingConfiguration • In the Connect() method , an Unmarshal() happens where not only the proxy, but also envoy sinks , are created. The proxy uses a chain of envoy sinks to pass the message to the channel. All the sinks are interceptors that can change the messages and perform some additional actions such as creating a lock, writing an event, performing security checks and so on… • SingleCall means that object holds no state. With every call to the remote object a new instance is created. This is very efficient on the server because it means that we don’t need to hold any resource for may be thousands of clients • With a Singleton the object is shared for all the clients of the server, such object types can be used if you want to share some data between all the client of the server. This shouldn’t be a problem for read-only data, but with read-write data you have to be aware of the locking issues and scalability.

  24. Ways to do …….

  25. Remoting through Configuration Files: Instead of writing the channel and the object configuration in the source code, we can use configuration files. This way channel can be reconfigured, additional channels can be added and so on, without chaning the source code. For .NET remoting, there are some xml XML elements and attributes to configure the channel and remote objects.<configuration><system.runtime.remoting><application name="Hello"><client displayName="Hello Clients for well known objects"><wellknown type="Remoting.Hello, ClassLibrary1" url="tcp://localhost:8086/Hello/Hi"/></client><channels><channel ref="tcp" displayName="Tcp Channel(HelloClient)"/> </channels></application></system.runtime.remoting></configuration>

  26. Configuration Files: • <Configuration> is the XML root element for all .NET configuration files. All the remoting configurations can be found in the subelement <system.runtime.remoting>. • Let’s look at the main elements and attributes of the parts within <system.runtime.remoting> • With the <application> element you can specify the name of the application using the attribute name. on the server side, this is the name of the server and on the client side it’s the name of the client application. • On the server, the element <service> is used to specify a collection of remote objects. It can have <wellknown> and <activated> subelements to specify the type of the remote object as well known ar client activated. • The client part of the <service> element is <client>. Like the <service> element, it can have <wellknown> and <activated> subelements to specify the type of the remote object. Unlike the <service> counterpart,<client> has a url attribute to specify the url to the remote object.

  27. Configuration Files: • <wellknown> is a element that’s used on the server and the client to specify well known remote objects. The server part could look like this: <wellknown mode=“SingleCall” type=“Wrox.ProCSharp.remoting.hello, remoteHello” objectURI=“Hi” /> • On the client, the type attribute is the same as it is for the server version. Mode and objectURI are not needed, but instead the url attribute is used to define the path to the remote object: protocol, hostname, port number, applivation name, and the object URl: <wellknown type=“Wrox.ProCSharp.remoting.hello, RemoteHello” URI=“tcp://localhost:6791/Hello/Hi” />

  28. Advantage’s • At it’s core .NET is a distributed infrastructure. It allows processes to share objects – to call methods on te access properties of the objects that are hosted in different application domains within the same process, different processes executing on the same computer, on computers on the intranet, or on computers distributed over wide areas. .NET

  29. Disadvantage’s The programming model is slightly more difficult than the ASP.NET Web services programming model, and Visual Studio .NET support for remoting is not as comprehensive as for ASP.NET Web Services. • There is no security built into the .NET Remoting infrastructure at the application layer. Because the remoting infrastructure relies on the protocol layer to provide a secure communication, it is potentionally less secure than ASP.NET Web Services. • Unlike Web services, remoting applications are tightly coupled. They rely on assembly metadata to describe types, which means that any application that communicates with another must have some intimate knowledge of other’s inner working. • The dependence on assembly metadata implies that client application must understand .NET concepts. As a result, applications make use of .NET Remoting are not interoperable with other system.

  30. Web Services Vs Remoting • Web Services: The Web services technology enables cross-platform integration by using HTTP, XML and SOAP for communication thereby enabling true business-to-business application integrations across firewalls. Because Web services rely on industry standards to expose application • functionality on the Internet, • they are independent of • programming language, • platform and device.

  31. Putting all together……

  32. What to choose???? Web Services OR RemotingAnd When????

  33. Make the Choice…. • There is no absolute answer to whether you should choose Web services • or remoting in most cases. If your entire distributed application is inside • your organization firewall and performance is critical, REMOTING via the TCP channel is the best choice. • If the entire application is inside the firewall and performance isn't as critical, or if you want to keep things as simple as possible, Web Services is a better choice • But, if you need to allow access to clients other than .NET, you'll need to use Web services regardless of whether or not the client is inside or outside the firewall. In the end, the choice is left to the developer, so you'll need thorough knowledge of both technologies to make a proper decision.

  34. THANKS

More Related