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