1 / 15

.Net Remoting

.Net Remoting. Distributed Computing under .Net. In .Net, there are three levels of access to distributed computing machinery: Low Level: System.Net.Sockets Intermediate Level System.Runtime.InteropSerives Access COM objects and Win32 API System.Runtime.Remoting

wilma
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

  2. Distributed Computing under .Net • In .Net, there are three levels of access to distributed computing machinery: • Low Level: • System.Net.Sockets • Intermediate Level • System.Runtime.InteropSerives • Access COM objects and Win32 API • System.Runtime.Remoting • Access channels and CLR activation • Channels based on TCP or HTTP over TCP • High Level • System.Web.Services • System.Web.UI .Net Remoting

  3. Distributed Computing under .Net • System.Net.Sockets • Provides low-level access to socket objects • You create listeners and send and receive just like we did inCSE691 – Software Modeling and Analysis • System.Runtime.Remoting • Provides access at a medium level of abstraction. • You create channels and proxies and do RPCs on remote objects • Data marshaling is much richer than under COM. You can send anything the CLR understands as long as it has a [serializable] attribute or derives from MarshalByRef. • Basically you just add those .Net identifiers and the CLR takes care of everything else. .Net Remoting

  4. Remoting .Net Libraries • System.Runtime.Remoting.Activation • Activate remote objects • System.Runtime.Remoting.Channels • Sets up channel sinks and sources for remote objects • System.Runtime.Remoting.Channels.HTTP • Uses SOAP protocol to communicate with remote objects • System.Runtime.Remoting.Channels.TCP • Uses binary transmission over sockets • System.Runtime.Remoting.Contexts • Set threading and security contexts for remoting • System.Runtime.Remoting.Messaging • Classes to handle message passing through message sinks • System.Runtime.Remoting.Metadata • Customize HTTP SoapAction type output and XML Namespace URL • System.Runtime.Remoting.Proxies • System.Runtime.Remoting.Services .Net Remoting

  5. Distributed Computing under .Net • System.Web.Services • Servers are hosted under IIS • Use HTTP-GET and HTTP-POST or higher level SOAP • Simple Object Access Protocol (SOAP) • Wraps XML message in SOAP envelope (XML tags) • SOAP messages are interpreted by IIS and ASP • Typically use standard and/or custom COM components in ASP pages. • Active Server Pages (ASP) are XHTML pages with embedded server-side and client-side scripts that may access COM and C# objects for a significant part of their processing. .Net Remoting

  6. Web Related .Net Libraries • System.Web • System.Web.Hosting • Communicate with IIS and ISAPI run-time • System.Web.Mail • System.Web.Security • cookies, web authentication, Passport • System.Web.Services – close ties to ASP.NET • System.Web.Services.Description • System.Web.Services.Discovery • System.Web.Services.Protocol – raw HTTP and SOAP requests • System.Web.SessionState – maintain state between page requests • System.Web.UI – access to WebForms .Net Remoting

  7. Remoting Architecture • .Net Remoting uses System.Runtime.Remoting • It is built on processing that supports: • Channels • A channel is a socket-based communication mechanism that can use either basic TCP protocol or the higher HTTP layer. • Activation • Activation is basically the same process that the CLR uses to create local objects. • You just have to tell the CLR what object you want. • The CLR manages its lifetime and marshals data and references back and forth, using a channel. .Net Remoting

  8. Remoting Architecture .Net Remoting

  9. Basic .Net Remoting – Remote Object • First create a remote-able object: • Design an object to be invoked remotely, derived from MarshalByRef • Implement the class as a C# library – this creates a dll. • Any objects that you need to pass to that object need to be serializable. • The basic types like ints and strings already are serializable. • Your class objects need to have the [Serializable] attribute and contain only serializable data members. Or they can derive from MarshalByRef. .Net Remoting

  10. Remoting Architecture .Net Remoting

  11. Basic .Net Remoting – the Server • Create a server: • Design a C# class, using a C# Console Application, or Empty Project in which you will create a WinForm. • In a member function – main will work: • Create a TcpServerChannel • Register the Channel with ChannelServices • Register the type of object clients want to use remotely by calling RegisterWellKnownServiceType • Then, block the main thread. • The object will be created by the CLR on its own thread and remote clients will access the object through the CLR. • You don’t have to write any server code to support this access – the CLR takes care of it for you. • Create a reference to the remote-able object’s assembly, build, and run the server. .Net Remoting

  12. Remoting Architecture .Net Remoting

  13. Basic .Net Remoting – the Client • Create a client: • Design a C# class, using a C# Console Application, or Empty Project in which you will create a WinForm. • In a member function – main will work: • Create a TcpServerChannel • Register the Channel with ChannelServices • In a member function – main will work: • Create a proxy to access the remote component. You do this by calling Activator.GetObject(…) and casting the result to the type of the remote object. • Note that both client and server need the assembly for the remote-able object. • Then, make calls on the remote object as needed. • You simply use the proxy as if it were the real object. • Create a reference to the remote-able object’s assembly, build, and run the client. .Net Remoting

  14. Remoting Architecture .Net Remoting

  15. Architecture for Project #3 • The previous slides described a classic client/server configuration. • For Project #3 we need something a little more sophisticated. • In a classic client/server only the client initiates communication. • In Project #3 you will have to have the “server” make notifications back on the “client”. • I would create a reply function that works just like the server, described earlier, except that the thread does not block after setting up the channel, but instead returns. • I would create a request function that works just like the client, described earlier. • I would have my Main function call the reply function then, as needed, call the request function. Everything else is just servicing the user interface. • I would do this for both the “client” that subscribes to notifications, and the “server” that sends out directory change notifications. .Net Remoting

More Related