CodeProject: Using Web Services for Remoting over the Internet.. Free source code and programming help

Report Article

Discuss

Send to a friend

53 votes for this Article.

Popularity: 7.95 Rating: 4.61 out of 5

Download source files - 103 Kb

Introduction

Usage
Concept and Design

Implementation

Test

Conclusion

Introduction

This article describes a design and implementation (C#) of the Remoting over Internet using the Web Service as a gateway into the Remoting infrastructure. The Web Service Gateway (Custom Remoting Channel) allows to enhance the remoting channel over Internet and its chaining with another heterogeneous channel. Consuming a remote object over Internet is full transparently and it doesn't require any special implementation from the remoting via intranet. The Web Service Gateway enables to create a logical model of the connectivity between the different platforms and languages. Before than we will go to its implementation details, let's start it with usage and configuration issue. For some demonstration purpose I will use a MSMQ Custom Remoting Channel (MSMQChannelLib.dll), which I described in my previously article [1]. I am assuming that you have a knowledge of the .Net Remoting and Web Service.

Usage

Consuming a remote object over Internet using the Web Service Gateway is very straightforward and it actually requires only to install the following assemblies:

WebServiceChannelLib , this is a Custom Remoting Channel on the client side to forward a remoting message to the Web Service Gateway over Internet (outgoing message).
WebServiceListener, this is a Web Service (gateway) to listen an incoming message from the client side and forward it to the local remoting infrastructure (incoming message).

Note that the above assemblies have to be installed (into the GAC) both on the server and client sides when a remote callback is used.

The next step is to configure a server and client host sides. Their configuration are depended from the actually application. Let me assume, we want to call a remote object driven by MSMQ custom channel over internet. Their config files might look like the following snippets:

server.exe.config

 <configuration>
 <system.runtime.remoting>
  <application >
   <service>
    <wellknown mode="Singleton" type="MyRemoteObject.RemoteObject, MyRemoteObject" 
               objectUri="endpoint" />
   </service>
   <channels>
   <channel type="RKiss.MSMQChannelLib.MSMQReceiver, MSMQChannelLib" 
            listener=".\ReqChannel"/>
   <channel type="System.Runtime.Remoting.Channels.Tcp.TcpChannel, System.Runtime.Remoting" 
            port="8090" />
   </channels>
  </application>
 </system.runtime.remoting>
</configuration>

The above server config file will register two channels to listen an incoming message for the remote well known singleton object.

client.exe.config

This is an example of the client config file to register our Custom Remoting Channel.

<configuration>
 <system.runtime.remoting>
  <application>
   <client >
    <wellknown type="MyRemoteObject.RemoteObject, RemoteObject" 
               url="ws://localhost/WebServiceListener/Listener.asmx; 
               tcp://localhost:8090/endpoint/RemoteObject" />
   </client>
   <channels>
    <channel type="RKiss.WebServiceChannelLib.Sender, WebServiceChannelLib" mode="soap"/>
   </channels>
  </application>
 </system.runtime.remoting>
</configuration>

The ws is a Custom Remoting Client channel to dispatch an IMessage over internet using a binary respectively soap mode formatter. Note that the mode is a CustomChannelProperty and its default value is binary.

web.config

This is a Web Service config file. The following snippet is its part. The Web Service gateway is also a local remoting client, therefore a client (sender) channel is requested to be registered. The following snippet shows a configuration of the two channels - Tcp and MSMQ.

<system.runtime.remoting>
 <application >
  <channels>
   <channel type="System.Runtime.Remoting.Channels.Tcp.TcpChannel, System.Runtime.Remoting"/>
   <channel type="RKiss.MSMQChannelLib.MSMQSender, MSMQChannelLib"                  
            respond=".\RspChannel" admin=".\AdminChannel" timeout="30" priority="10"/>
  </channels>
 </application>
</system.runtime.remoting>

Activating a remote object

The well known remote object (WKO) is activated by its consumer using the GetObject method mechanism. The proxy is created based on the remote object metadata assembly installed in the GAC (see an argument objectType). The remoting channel is selected by the objectUrl argument. The url address in this solution has two parts :

connectivity to the Web Service gateway over internet
connectivity to the Remote object over intranet within the Web Service gateway

Between the primary and secondary addresses is a semicolon delimiter as it is shown the below:

string objectUrl = @"ws://localhost/WebServiceListener/Listener.asmx; msmq://./reqchannel/endpoint";

Using this objectUrl design pattern allows an easy selection of the web service gateways on the Internet. Note that the ws custom remoting channel will trim this primary address and forward only its secondary part. In this solution, the objectUrl represents a physical path of the logical connectivity between the consumer and remote object regardless of how many channels are needed. In this example, the Web Service gateway resides on the localhost and it should be replaced by the real machine name.

Finally, the following code snippet shows an activation of the remote object:

 // activate a remote object

 Type objectType = typeof(MyRemoteObject.RemoteObject);
 string objectUrl = @"ws://localhost/WebServiceListener/Listener.asmx; msmq://./reqchannel/endpoint";
 RemoteObject ro = (RemoteObject)Activator.GetObject(objectType, objectUrl);

Note that a metadata (assembly) of the remote object must be installed into the GAC in the places such as client, Web Service gateway and server host.

That's all for the client/remoteObject plumbing issue over the Internet.

The following pictures shows this connectivity:

Now, to understand how the message flows between the heterogeneous channels over the Internet, have a look at the following paragraphs:

Concept and Design

Concept of the Remoting over Internet is based on dispatching a remoting message over Internet using the Web Service features as a transport layer. The following picture shows this solution:

Client activates a remote WKO to obtain its transparent proxy. During this process the custom remoting channel (ws) is initiated and inserted into the client channel sink chain. Invoking a method on this proxy, the IMessage is created which it represents a runtime image of the method call at the client side. This IMessage is passed into the channel sink. In our solution to the custom client (sender) channel ws. This channel sink has a responsibility to convert IMessage to the SoapMessage in the text/xml format pattern and send it over Internet to the Web Service gateway. The following picture shows this:

The Web Service gateway has two simply WebMethods, one for the SoapMessage format and the other one for a binary format encoded by base64 into the text string. The first one method enables to use a call from an unknown client, as opposite in the binary formatting message for .Net client.

Lets continue with the IMessage/SoapMessage flows on the Web Service gateway side as it is shown on the above picture. The text/xml formatted SoapMessage sent over Internet might look like the following snippet:

Text/XML formatted SoapMessage Request.

<SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:a3="http://schemas.microsoft.com/clr/nsassem/MyRemoteObject/MyRemoteObject, 
Version=1.0.772.24659, Culture=neutral, PublicKeyToken=ec0dd5142ae7a19b" 
xmlns:a1="http://schemas.microsoft.com/clr/ns/System.Runtime.Remoting.Messaging">
<SOAP-ENV:Body>
<System.Runtime.Remoting.Messaging.MethodCall id="ref-1">
<__Uri id="ref-2" xsi:type="SOAP-ENC:string">msmq://./reqchannel/endpoint</__Uri>

<__MethodName id="ref-3" xsi:type="SOAP-ENC:string">get_Id</__MethodName>

<__TypeName id="ref-4" xsi:type="SOAP-ENC:string">MyRemoteObject.RemoteObject, 
MyRemoteObject, Version=1.0.772.24659, Culture=neutral, 
PublicKeyToken=ec0dd5142ae7a19b</__TypeName>

<__Args href="#ref-5"/> 
<__CallContext href="#ref-6"/> 
</System.Runtime.Remoting.Messaging.MethodCall>
<SOAP-ENC:Array id="ref-5" SOAP-ENC:arrayType="xsd:ur-type[0]">
</SOAP-ENC:Array> 
<a1:LogicalCallContext id="ref-6">
<User href="#ref-8"/> 
</a1:LogicalCallContext>
<a3:User id="ref-8"> 
<FirstName id="ref-9" xsi:type="SOAP-ENC:string">Roman</FirstName>
<LastName id="ref-10" xsi:type="SOAP-ENC:string">Kiss</LastName>
</a3:User> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope>

This string request has to be de-serialized back to the SoapMessage object, which is a clone object of the sender's origin. After that, we have an enough information to perform a Method call on the remote object. Conversion of the SoapMessage to IMessage needs to use some trick, therefore there is no class in .Net namespaces to do it. The trick is based on creating a RealProxy wrapper using the remote object type and its endpoint url address and overriding an Invoke method of the base RealProxy class. Using the Reflection (late binding) to invoke the remote method, the RealProxy wrapper will catch the IMessage before its processing in the channel sink. Now, the Invoke method can perform updating the IMessage by original images such as LocicalCallContext and url address. After that, the IMessage is the same like on the client side over Internet. Now it's easy to forward this IMessage to the Message Sink calling its SyncProcessMessage method. The rest is done by a remoting paradigm.

The SyncProcessMessage returns an IMessage which it represents a ReturnMessage from the remote method. Now the process is going to reverse into the text/xml format of the SoapMessage response . I will skip it this process for its simplicity and I will continue on the client custom channel (ws) where a response message has been returned. Before that, have a look the text/xml formatted SoapMessage response how it has been sent back to the custom channel over Internet:

Text/XML formatted SoapMessage Response.

<SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:a3="http://schemas.microsoft.com/clr/nsassem/MyRemoteObject/MyRemoteObject, 
Version=1.0.772.24659, Culture=neutral, PublicKeyToken=ec0dd5142ae7a19b" 
xmlns:a1="http://schemas.microsoft.com/clr/ns/System.Runtime.Remoting.Messaging"> 
<SOAP-ENV:Body> 
<a1:MethodResponse id="ref-1"> 
<__Uri xsi:type="xsd:ur-type" xsi:null="1"/> 
<__MethodName xsi:type="xsd:ur-type" xsi:null="1"/> 
<__MethodSignature xsi:type="xsd:ur-type" xsi:null="1"/> 
<__TypeName xsi:type="xsd:ur-type" xsi:null="1"/> 
<__Return xsi:type="xsd:int">0</__Return> 
<__OutArgs href="#ref-2"/> 
<__CallContext href="#ref-3"/> 
</a1:MethodResponse> 
<SOAP-ENC:Array id="ref-2" SOAP-ENC:arrayType="xsd:ur-type[0]"> 
</SOAP-ENC:Array> 
<a1:LogicalCallContext id="ref-3"> 
<User href="#ref-5"/> 
</a1:LogicalCallContext> 
<a3:User id="ref-5"> 
<FirstName id="ref-6" xsi:type="SOAP-ENC:string">Roman</FirstName> 
<LastName id="ref-7" xsi:type="SOAP-ENC:string">Kiss</LastName> 
</a3:User> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope>

The result of the remoting call has to be de-serialized into the SoapMessage and then an IMessage can be generated by the function ReturnMessage. This IMessage is returned back to the remoting client infrastructure. In this point, the process of the remoting over Internet is done and the rest is a regular remoting mechanism.

As I mentioned earlier, the Web Service gateway has two methods, one has been described the above using the SoapFormatter and the other one is using a BinaryFormatter.

Using the Binary Formatted Message.

The .Net clients can use a remoting over Internet in more efficient (faster) way using the BinaryFormatter. The design implementation is more straightforward than using the SoapFormatter. The IMessage is serialize/deserialize by the BinaryFormatter to/from memory stream. Than this stream image is encoded/decoded using the Base64 conversion class to/from text string. Note that this text string is not readable. The IMessage is plugged-in into the server remoting infrastructure using the RemotingServices.Connect and RemotingServices.ExecuteMessage functions from the Remoting namespace. Thanks for these functions, they really saved my time.

Limitation note.

The limitation of the above solution is done by the Web Service functionality. You cannot handle a distributed transaction over Internet. In this case, the Web Service gateway represents a non-transactional client and remote object is a root of the transaction.

Implementation

The implementation is divided into two assemblies - Custom Client Channel and Web Service gateway. Their implementation is straightforward without using any third party library support. I am going to concentrate only for these parts related to the IMessage processing. More details about the design and implementation of the Custom Remoting Channel can be found it in [1].

WebServiceChannelLib

This is a Custom Client Channel assembly to process an outgoing remoting message over Internet. The Client Message Sink has an implementation both message processing such as SyncProcessMessage and AsyncProcessMessage. Based on the m_mode value, the IMessage can be formatted by the SoapFormatter or BinaryFormatter.

The SyncProcessMessage function initiates the Web Service client proxy generated by the VS. There is a small modification in its constructor. This proxy is a generic for any location of the Web service, that's why the url address is pass through its constructor instead of its hard coding. Note that any Exception will be converted into the IMessage format and send back to the client.

Sender:

// IMessageSink (MethodCall)

public virtual IMessage SyncProcessMessage(IMessage msgReq)
{ 
   IMessage msgRsp = null;

   try 
   {
      msgReq.Properties["__Uri"] = m_ObjectUri;
      Service webservice = new Service(m_outpath); 

      if(m_mode == "SOAP") 
      {
         // serialize IMessage into the stream (SoapMessage)

         MemoryStream reqstream = new MemoryStream();
         SoapFormatter sf = new SoapFormatter();
         RemotingSurrogateSelector rss = new RemotingSurrogateSelector();
         rss.SetRootObject(msgReq);
         sf.SurrogateSelector = rss;
         sf.AssemblyFormat = FormatterAssemblyStyle.Full;
         sf.TypeFormat = FormatterTypeStyle.TypesAlways;
         sf.TopObject = new SoapMessage();
         sf.Serialize(reqstream, msgReq);
         ISoapMessage sm = sf.TopObject;
         reqstream.Position = 0;
         StreamReader sr = new StreamReader(reqstream);
         string request = sr.ReadToEnd();
         reqstream.Close();
         sr.Close();

         // call web service

         string respond = webservice.SyncProcessSoapMessage(request);

         // return messages

         StreamWriter rspsw = new StreamWriter(new MemoryStream());
         rspsw.Write(respond);
         rspsw.Flush();
         rspsw.BaseStream.Position = 0;
         ISoapMessage rspsoapmsg = (ISoapMessage)sf.Deserialize(rspsw.BaseStream);
         rspsw.Close();

         if(rspsoapmsg.ParamValues[0] is Exception) 
         {
            throw rspsoapmsg.ParamValues[0] as Exception;
         }
         else 
         {
            object returnVal = rspsoapmsg.ParamValues[4];
            object[] OutArgs = rspsoapmsg.ParamValues[5] as object[];
            LogicalCallContext lcc = rspsoapmsg.ParamValues[6] as LogicalCallContext;
            ReturnMessage rm = new ReturnMessage(
                       returnVal,            //Object return

                       OutArgs,              //Object[] outArgs

                       OutArgs.Length,       //int outArgsCount

                       lcc,                  //LogicalCallContext callCtx

                       msgReq as IMethodCallMessage    //IMethodCallMessage mcm

                       );
            msgRsp = rm as IMessage;
         }
      }
      else 
      {
         msgReq.Properties["__Uri2"] = m_ObjectUri; // workaround! 

         // serialize and encode IMessage

         BinaryFormatter bf = new BinaryFormatter();
         MemoryStream reqstream = new MemoryStream();
         bf.Serialize(reqstream, msgReq);
         reqstream.Position = 0;
         string request = Convert.ToBase64String(reqstream.ToArray());
         reqstream.Close();
         // call Web Service

         string respond = webservice.SyncProcessMessage(request);

         // decode and deserialize IMessage

         byte[] rspbyteArray = Convert.FromBase64String(respond);
         MemoryStream rspstream = new MemoryStream();
         rspstream.Write(rspbyteArray, 0, rspbyteArray.Length);
         rspstream.Position = 0;
         msgRsp = (IMessage)bf.Deserialize(rspstream);
         rspstream.Close();
      }
   }
   catch(Exception ex) 
   {
      Trace.WriteLine(string.Format("Client:SyncProcessMessage error = {0}", ex.Message));
      msgRsp = new ReturnMessage(ex, (IMethodCallMessage)msgReq);
   }

   return msgRsp;
}

public virtual IMessageCtrl AsyncProcessMessage(IMessage msgReq, IMessageSink replySink)
{
   IMessageCtrl imc = null;

   if(replySink == null) // OneWayAttribute

   { 
      Trace.WriteLine("Client-[OneWay]Async:CALL");
      SyncProcessMessage(msgReq);
   }
   else
   {
      Trace.WriteLine("Client-Async:CALL");
      // spawn thread (delegate work)

      delegateAsyncWorker daw = new delegateAsyncWorker(handlerAsyncWorker);
      daw.BeginInvoke(msgReq, replySink, null, null);
   }

return imc;
}

The Web Service Client Proxy changes:

[System.Web.Services.WebServiceBindingAttribute(Name="ServiceSoap", 
Namespace="http://tempuri.org/")]
public class Service : System.Web.Services.Protocols.SoapHttpClientProtocol {

   [System.Diagnostics.DebuggerStepThroughAttribute()]
      public Service(string uri) {
      this.Url = uri;
   }
   ...
}

WebServiceListener

This is a Web Service gateway to listen a MethodCall formatted into the string request. There are two different WebMethods for this process: SyncProcessMessage and SyncProcessSoapMessage. The functions have a simple logic divided into tree steps:

Decoding and de-serializing of the request message
Invoking the Remote Method
Encoding and serialization of the response message

[WebMethod]
public string SyncProcessMessage(string request)
{
   // Request: decoding and deserializing 

   byte[] reqbyteArray = Convert.FromBase64String(request);
   MemoryStream reqstream = new MemoryStream();
   reqstream.Write(reqbyteArray, 0, reqbyteArray.Length);
   reqstream.Position = 0;
   BinaryFormatter bf = new BinaryFormatter();
   IMessage reqmsg = (IMessage)bf.Deserialize(reqstream);
   reqmsg.Properties["__Uri"] = reqmsg.Properties["__Uri2"]; // work around!!

   reqstream.Close();

   // Action: invoke the Remote Method 

   string[] stype = reqmsg.Properties["__TypeName"].ToString().Split(new Char[]{','}); // split typename

   Assembly asm = Assembly.Load(stype[1].TrimStart(new char[]{' '})); // load type of the remote object

   Type objectType = asm.GetType(stype[0]);                           // type

   string objectUrl = reqmsg.Properties["__Uri"].ToString();          // endpoint

   object ro = RemotingServices.Connect(objectType, objectUrl);       // create proxy

   TraceIMessage(reqmsg);
   IMessage rspmsg = RemotingServices.ExecuteMessage((MarshalByRefObject)ro, 
                                                     (IMethodCallMessage)reqmsg);
   TraceIMessage(rspmsg);

   // Response: encoding and serializing 

   MemoryStream rspstream = new MemoryStream();
   bf.Serialize(rspstream, rspmsg);
   rspstream.Position = 0;
   string response = Convert.ToBase64String(rspstream.ToArray());
   rspstream.Close();

   return response;
}

[WebMethod]
public string SyncProcessSoapMessage(string request)
{
   IMessage retMsg = null;
   string response;

   try
   {
      Trace.WriteLine(request);

      // Request: deserialize string into the SoapMessage

      SoapFormatter sf = new SoapFormatter();
      sf.TopObject = new SoapMessage();
      StreamWriter rspsw = new StreamWriter(new MemoryStream());
      rspsw.Write(request);
      rspsw.Flush();
      rspsw.BaseStream.Position = 0;
      ISoapMessage soapmsg = (ISoapMessage)sf.Deserialize(rspsw.BaseStream);
      rspsw.Close();

      // Action: invoke the Remote Method 

      object[] values = soapmsg.ParamValues;
      string[] stype = values[2].ToString().Split(new Char[]{','});
      Assembly asm = Assembly.Load(stype[1].TrimStart(new char[]{' '}));
      Type objectType = asm.GetType(stype[0]);
      string objectUrl = values[0].ToString(); 
      RealProxyWrapper rpw = new RealProxyWrapper(objectType, objectUrl, 
                                                  soapmsg.ParamValues[4]);
      object ro = rpw.GetTransparentProxy();
      MethodInfo mi = objectType.GetMethod(values[1].ToString());
      object retval = mi.Invoke(ro, values[3] as object[]);
      retMsg = rpw.ReturnMessage;
   }
   catch(Exception ex) 
   {
      retMsg = new ReturnMessage((ex.InnerException == null) ? 
                                           ex : ex.InnerException, null);
   }
   finally 
   {
      // Response: serialize IMessage into string

      Stream rspstream = new MemoryStream();
      SoapFormatter sf = new SoapFormatter();
      RemotingSurrogateSelector rss = new RemotingSurrogateSelector();
      rss.SetRootObject(retMsg);
      sf.SurrogateSelector = rss;
      sf.AssemblyFormat = FormatterAssemblyStyle.Full;
      sf.TypeFormat = FormatterTypeStyle.TypesAlways;
      sf.TopObject = new SoapMessage();
      sf.Serialize(rspstream, retMsg);
      rspstream.Position = 0;
      StreamReader sr = new StreamReader(rspstream);
      response = sr.ReadToEnd();
      rspstream.Close();
      sr.Close();
   }

   Trace.WriteLine(response);
   return response;
}

The implementation of the steps are depended from the type of formatter such as SoapFormatter or BinaryFormatter. The first and last steps are straightforward using the Remoting namespace classes. The second one (action) for the SoapFormatter message needed to create the following class to obtain IMessage of the MethodCall:

public class RealProxyWrapper : RealProxy
{
   string _url;
   string _objectURI;
   IMessageSink _messageSink;
   IMessage _msgRsp;
   LogicalCallContext _lcc;

   public IMessage ReturnMessage { get { return _msgRsp; }}
   public RealProxyWrapper(Type type, string url, object lcc) : base(type)
   {
      _url = url;
      _lcc = lcc as LogicalCallContext;

      foreach(IChannel channel in ChannelServices.RegisteredChannels)
      {
         if(channel is IChannelSender)
         {
            IChannelSender channelSender = (IChannelSender)channel;
            _messageSink = channelSender.CreateMessageSink(_url, null, out _objectURI);
            if(_messageSink != null)
               break;
         }
      }

      if(_messageSink == null)
      {
         throw new Exception("A supported channel could not be found for url:"+ _url);
      }
   }
   public override IMessage Invoke(IMessage msg)
   {
      msg.Properties["__Uri"] = _url; // endpoint

      msg.Properties["__CallContext"] = _lcc; // caller's callcontext

      _msgRsp = _messageSink.SyncProcessMessage(msg);

      return _msgRsp;
   }
}// RealProxyWrapper

Test

I built the following package to test functionality of the WebServiceListener and WebServiceChannelLib assemblies. Note that this package has only test purpose. Here is what you downloaded it:

ConsoleClient, the test console program to invoke the call over Internet - client machine
ConsoleServer, the host process of the MyRemoteObject - server machine
MyRemoteObject, the remote object - server machine
WebServiceChannelLib, the custom client channel
WebServiceListener, the Web Service listener - server machine

To recompile a package and its deploying in your environment follow these notes:

The folder WebServiceListener has to be moved to the virtual directory (inetpub\wwwroot).
The MyRemoteObject assembly has to be install into the GAC on the server machine
The WebServiceChannelLib assembly has to be install into the GAC on the client machine
(option) The MSMQChannelLib assembly [1] has to be install into the GAC on the server machine
The solution can be tested also using the same machine (Win2k/Adv Server)
Use the Echo WebMethod on the test page of the WebServiceListener to be sure that this service will be work

The test case is very simple. First step is to launch the ConsoleServer program. Secondly open the ConsoleClient program and follow its prompt text. If everything is going right you will see a response from the remote object over Internet. I am recommending to make a first test on the same machine and then deploying over Internet.

Conclusion

In this article has been shown one simple way how to implement a solution for remoting over Internet. I used the power of .Net Technologies such as SOAP, Remoting, Reflection and Web Service. The advantage of this solution is a full transparency between the consumer and remote object. This logical connectivity can be mapped into the physical path using the config files, which they can be administratively changed.

[1] http://www.codeproject.com/csharp/msmqchannel.asp