spacer

Webref WebRef   Sitemap · Experts · Tools · Services · Newsletters · About i.com

home / programming / csharp / webservices / chap6 / 1 To page 1To page 2current pageTo page 4To page 5To page 6To page 7To page 8
[previous] [next]

Professional C# Web Services

Developer News
OpenOffice 3.2 Lands Amid Critical Changes
Red Hat, IBM Firmly in KVM Virtualization Camp
Red Hat Talks Up Open Source Cloud Plans

Server

The remote object needs a server process where it will be instantiated. This server has to create a channel and put it into listening mode so that clients can connect to this channel. In this chapter, we will use simple console applications as hosting servers, and in the next chapter we will look at the different application types.

Using configuration files for remoting clients and servers has the advantage that the channel and remote object can be configured without changing a single line of code and without the need to recompile. Another advantage is that the remoting code we have to write is very short.

Specifying the options programmatically has the advantage that we could get to the information during runtime. One way to implement this can be that the client uses a directory service to locate a server that has registered its long running objects there.

Server Configuration File

Configuration files have the advantage that the channel, endpoint name, and so on, can be changed without changing a single line of code and without doing a recompile. We will use configuration files first before we look at what happens behind the scenes when doing the configuration programmatically.

For versioning and probing of assemblies, we can have application configuration files with the same name as the executable, but with a .config file extension, such as SimpleServer.exe.config. The .NET Remoting configuration can be put into a different file or the same file. We have to read the .NET Remoting configuration explicitly, so it doesn't matter from a programming viewpoint. From the administrator viewpoint it would be useful to put the .NET Remoting configuration inside the same file as this can be used to configure the channel with the .NET Admin tool.

When the client connects to the remote object it needs to know the URI of the object, that is, the name of the host where the remote object is running, the protocol and port number to connect to, the name of the server, and the name of the remote object. Such a connection string can look like this:

tcp://localhost:9000/SimpleServer/MyRemoteObject

With the exception of the host name we have to specify all these items in the configuration file.

In the following configuration file, SimpleServer.exe.config, all of the remoting configurations must be added as child elements to <system.runtime.remoting>. The <application> element specifies the name of the server with the name attribute. The application offers a service and requires the configuration of channels for the service. Correspondingly we have the <service> and <channels> elements. The service that is offered from the application must be listed as a child of <service>. This is the remote object itself. The remote object is specified with the <wellknown> element.

The remoting framework uses the information to create an object from the type specified. For instantiating the object the framework requires the name of the assembly to know where the type of this object can be loaded from. We can set this information with the XML attribute type. type="Wrox.Samples. MyRemoteObject, MyRemoteObject" defines that the type of the remote object is MyRemoteObject in the namespace Wrox.Samples, and it can be found in the assembly MyRemoteObject. The mode attribute is set to SingleCall. We will talk later about all the different object types and modes. With objectURI we set the endpoint name of the remote object that will be used from the client.

The name of the assembly is often confused with the name of the file in which the assembly is stored. The assembly name is MyRemoteObject, while the file of the assembly is MyRemoteObject.dll. With method calls where an assembly name is needed as argument, never use the file extension.

In the <channels> section we define the channels that will be used from the server. There are already some channels defined in the machine configuration file machine.config that we can use from our applications. Such a predefined channel can be referenced using the ref attribute of the <channel> element. Here we reference the predefined server channel using the TCP protocol: tcp server. We have to assign the port of this channel with the port attribute, as the server must have a well-known port number that the client must be aware of:

<configuration>
   <system.runtime.remoting>
      <application name="SimpleServer">
         <service>
            <wellknown 
               mode="SingleCall" 
               type="Wrox.Samples.MyRemoteObject, MyRemoteObject" 
               objectUri="MyRemoteObject" />
         </service>
         <channels>
            <channel ref="tcp server" port="9000" />
         </channels>
      </application>
   </system.runtime.remoting>
</configuration>

home / programming / csharp / webservices / chap6 / 1 To page 1To page 2current pageTo page 4To page 5To page 6To page 7To page 8
[previous] [next]


The Network for Technology Professionals

Search:

About Internet.com

Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers

webref The latest from WebReference.com Browse >
Search Engine Optimization: Selecting and Embedding Keywords · Are Google's Language Translation Web Services Ready for Prime Time? · Installing and Using Meeplace, the Business Review CMS
Sitemap · Experts · Tools · Services · Email a Colleague · Contact FREE Newsletters 
 The latest from internet.com
IBM DB2 10 for z/OS: Justifying the Upgrade · Living La Vida Colo: Choosing the Right Colocation Facility · FTC Concerns over Social Media Privacy Linger

Created: February 13, 2002
Revised: February 13, 2002


URL: http://webreference.com/programming/csharp/webservices/chap6/1/3.html