<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
	<channel>
		<title>gdp's Comments</title>
		<language>en-us</language>
		<link>https://www.intensedebate.com/users/768819</link>
		<description>Comments by jezell</description>
<item>
<title>iServiceOriented : Back in Action</title>
<link>http://blog.iserviceoriented.com/index.php/2010/01/21/back-in-action/#IDComment75212808</link>
<description>In order to route raw traffic, you will need to set up a contract to send and receive the WCF Message class with request and reply actions set to &amp;quot;*&amp;quot;.  public interface IRequestReceiver {     [OperationContract(Action=&amp;quot;*&amp;quot;, ReplyAction=&amp;quot;*&amp;quot;)]     Message Receive(Message message); }  On the service implementation class, set the AddressFilterMode attribute to Prefix to tell the service if you would like to be able to receive messages at any path below the address used by the service host instead of only at the specified url.  Use a custom binding with WebMessageEncoder and HttpTransport on your service host and outgoing endpoints. If you want to force all traffic to be raw message data rather than validating the messages as XML, add a custom WebContentTypeMapper that always returns WebContentFormat.Raw.   For each received message, you can use HttpRequestMessageProperty.Name to look up HTTP specific details such as the query string. The received message can be send  to the destination endpoint by using a ChannelFactory&amp;lt;IRequestChannel&amp;gt; to create a request channel with the same custom binding used by the request service. </description>
<pubDate>Thu, 13 May 2010 08:37:27 +0000</pubDate>
<guid>http://blog.iserviceoriented.com/index.php/2010/01/21/back-in-action/#IDComment75212808</guid>
</item><item>
<title>iServiceOriented : Building a Basic Web Server Using WCF</title>
<link>http://blog.iserviceoriented.com/index.php/2010/01/23/building-a-basic-web-server-using-wcf/#IDComment53735706</link>
<description>.NET 4.0 includes a new message encoder for raw byte streams that doesn&amp;#039;t require as many tricks because it isn&amp;#039;t coupled to the REST support that the WebMessageEncoder was designed for.  </description>
<pubDate>Mon, 25 Jan 2010 01:02:13 +0000</pubDate>
<guid>http://blog.iserviceoriented.com/index.php/2010/01/23/building-a-basic-web-server-using-wcf/#IDComment53735706</guid>
</item><item>
<title>iServiceOriented : Building a Basic Web Server Using WCF</title>
<link>http://blog.iserviceoriented.com/index.php/2010/01/23/building-a-basic-web-server-using-wcf/#IDComment53717269</link>
<description>Don&amp;#039;t disagree. If all you want is basic raw HTTP support with no frills, you are probably better off just using HttpListener. As you mention, WCF itself uses HttpListener under the covers. However, WCF isn&amp;#039;t just about doing the same thing in a different way. WCF is about a uniform communication model. The nice thing about this approach is that the same interface and concepts also work with TCP, MSMQ, and any other WCF binding with very minimal effort. WCF also adds a standard extensibility model for things like tracing, performance counters, instancing, security, etc. With HttpListener, you just get the basics. </description>
<pubDate>Sun, 24 Jan 2010 21:21:09 +0000</pubDate>
<guid>http://blog.iserviceoriented.com/index.php/2010/01/23/building-a-basic-web-server-using-wcf/#IDComment53717269</guid>
</item><item>
<title>iServiceOriented : Message: The Most Important WCF Class</title>
<link>http://blog.iserviceoriented.com/index.php/2010/01/22/message-the-most-important-class-in-wcf/#IDComment53630849</link>
<description>WCF certainly doesn&amp;#039;t go out of it&amp;#039;s way to make messaging with anything other than interfaces and objects marked up with attributes easy, but it is possible. This topic is probably worth an entire blog post, so I&amp;#039;ll write something up when I get a chance. </description>
<pubDate>Sun, 24 Jan 2010 01:16:38 +0000</pubDate>
<guid>http://blog.iserviceoriented.com/index.php/2010/01/22/message-the-most-important-class-in-wcf/#IDComment53630849</guid>
</item><item>
<title>iServiceOriented : Message: The Most Important WCF Class</title>
<link>http://blog.iserviceoriented.com/index.php/2010/01/22/message-the-most-important-class-in-wcf/#IDComment53465350</link>
<description>The component responsible for turning the representation of the message into data is the MessageEncoder. You see the base 64 tag because you are using the text message encoder. If you want to send raw binary data, you can implement a custom message encoder class with a custom xml dictionary writer that only writes out the raw byte array and writes it out directly as bytes. This is how the byte stream message encoding in 4.0 works. Message encoders are a pretty easy thing to implement compared to something like channels. </description>
<pubDate>Fri, 22 Jan 2010 22:28:47 +0000</pubDate>
<guid>http://blog.iserviceoriented.com/index.php/2010/01/22/message-the-most-important-class-in-wcf/#IDComment53465350</guid>
</item><item>
<title>iServiceOriented : Message: The Most Important WCF Class</title>
<link>http://blog.iserviceoriented.com/index.php/2010/01/22/message-the-most-important-class-in-wcf/#IDComment53393805</link>
<description>No, there are no special pitfalls when dealing with non-SOAP messages. As long as you set the message version to none, you will be fine. If doing REST work, you can use the WebMessageEncoder. Additionally, .NET 4.0 adds ByteStreamMessageEncodingBindingElement.  &lt;a href=&quot;http://msdn.microsoft.com/en-us/library/system.servicemodel.channels.bytestreammessageencodingbindingelement(VS.100).aspx&quot; target=&quot;_blank&quot;&gt;http://msdn.microsoft.com/en-us/library/system.se...&lt;/a&gt; </description>
<pubDate>Fri, 22 Jan 2010 16:36:09 +0000</pubDate>
<guid>http://blog.iserviceoriented.com/index.php/2010/01/22/message-the-most-important-class-in-wcf/#IDComment53393805</guid>
</item>	</channel>
</rss>