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"
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>
<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]#[1]]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:
