This is possible through serialization.
When you return a .NET object, it's serialized (usually into XML or possibly JSON, but there could be other possibilities as well). If a .NET client is receiving the message, it will then deserialize it back into a .NET object. For example:
class MyObject
{
int blah;
string blah2;
}
...
return new MyObject() { blah = 0; blah2 = "asdf" };
Might get serialized as:
<ns0:MyOjbect xmlns:ns0="tempuri.org">
<blah>0</blah>
<blah2>asdf</blah2>
</ns0:MyObject>
in XML, or
{
MyOjbect {
"blah":0,"blah2":"asdf"
}
}
in JSON
And then deserialized back into the MyObject
class by the client. Other clients can do this deserialization to their own datatypes as well - or just work directly with he XML or JSON.
There's a little more at play here too, depending on whether you're using a SOAP
or REST
based service; for SOAP
, there'll be a SOAP
envelope around the serialization, and for REST
there'll be some HTTP
status headers and bodies. It also gets more complicated when you're dealing with complex/composed objects, but the basic idea remains the same: break them down into something you can easily and portably send over the wire to be reconstituted by the client.