Today's article is just a summary of what we've put together with the file transport and a demonstration of how it works. There's no new code left to show, although I'll go over a number of improvements we could make to the transport in the future. Here are the previous articles in this series:
Running the server creates a listener at my.file://localhost/x, which for the machine I'm running this on is going to resolve to c:\x. The listener creates a file system watcher to look for a request message at c:\x\request. We're using the TextMessageEncoder, so the format of the request message is expected to be a text-encoded message using SOAP.
Meanwhile, I've started up the client and given it an input string to send as the message body.
Creating factory... done.
Creating channel... done.
Opening channel... done.
Enter some text (Ctrl-Z to quit): asdf
Sending request... done.
Processing reply: http://reflection
Enter some text (Ctrl-Z to quit): ^Z
What this is going to look like on the "wire" is first a request message with the http://reflect action written to c:\x\request:
<s:Envelope xmlns:s=http://www.w3.org/2003/05/soap-envelope xmlns:a="http://www.w3.org/2005/08/addressing">
Then, the server writes back a reply message with the http://reflection action to c:\x\reply:
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
This transport is fully operational, but it's taken a number of shortcuts to get to that point in the smallest amount of code. Here's what has been left behind:
I hope this series has helped explain the process of writing a transport. It's been tough having a long series like this. I hope in the future we can make the process of building a transport easier. There will be other transport examples in the SDK to look at when the product is released.
The next series is going to be a much shorter one and covers writing a custom message encoder.
Next time: Building A Custom Message Encoder to Record Throughput, Part 1