Transcript Net Remoting

.Net Remoting
Jim Fawcett
CSE791 – Distributed Objects
Spring 2002
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
2
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 in
CSE691 – 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
3
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
4
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
5
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
6
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
7
Remoting Architecture
Application Domain
Application Domain
server object
client Object
proxy for
Remote-able
Object
Remote-able
Object
channel
channel
CLR Thread
CLR Thread
.Net Remoting
8
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
9
Remoting Architecture
Application Domain
Application Domain
server object
client Object
proxy for
Remote-able
Object
Remote-able
Object
channel
channel
CLR Thread
CLR Thread
.Net Remoting
10
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
11
Remoting Architecture
Application Domain
Application Domain
server object
client Object
proxy for
Remote-able
Object
Remote-able
Object
channel
channel
CLR Thread
CLR Thread
.Net Remoting
12
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
13
Remoting Architecture
Application Domain
Application Domain
server object
client Object
proxy for
Remote-able
Object
Remote-able
Object
channel
channel
CLR Thread
CLR Thread
.Net Remoting
14
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
15