WCF Policy – Part 8: Making the Information Available on the Client

AJ's blog

Our policy has its default behavior. All the information is collected, it just is not available to the developer yet. So let’s take care of that.

We already have the basics covered, namely we have an interface ITrackingInformation through which the application developer should have access to the information. All we need to do is to build a bridge between message inspectors and the application code.

On the client the application developer uses the generated client proxy class, thus we need to pass in the tracking information to that object. The class derives from ClientBase<TChannel> and thus inherits the property Endpointof type ServiceEndpoint. This class in turn maintains a collection of endpoint behaviors. With a custom behavior which implements our interface, the developer has the gate to our policy. Going one step further, this behavior can also register a message inspector in IEndpointBehavior.ApplyClientBehavior, which utilizes…

View original post 321 more words

Understanding WCF in depth : Part – 1

Xamlized

WCF (Windows Communication Foundation) is a mechanism which enables applications to communicate whether they are on the same computer, across the Internet, or on different application platforms.

Thus it allows you to build a Service Oriented application which focuses on integrating across platforms.

Before diving into the basics (ABC’s) of WCF, we should understand the core functionality of WCF which is “WCF Runtime Components”. When we say there arises a need to talk to the outer world we intend of sending “Messages”. Similarly WCF also uses “Messages” to interact.

WCF Runtime Components:

“Message” class is a core part of the WCF Runtime Component.

There are 2 important subparts of WCF Runtime viz.

1. Channel Stack: This is the block which does the actual work of transferring a message through the channel which then gets picked up at the other end. For now you can consider this to be a black box…

View original post 395 more words

WCF Policy – Part 6: Implementation Basics

AJ's blog

We’ve come pretty far, but we haven’t done anything worthwhile yet.

As a reminder: Our tracking policy is pretty simple: Client and server should keep track of sending and receiving messages, and accumulate that information along a request/reply call as part of the SOAP call. In the end this should create a timing protocol of the complete call.

So far we’ve got the design part covered: The server announces the policy, the client recognizes it. The next major aspect is actually doing something. In this post I’m going to provide some basics we are going to need further on. Classes to maintain the tracking information, as well as SOAP related helpers.

For a single tracking entry:

TrackingEntry
{
DateTime TimeStamp { ; ; }
Source { ; ; }
Reason { ; ; }
[…]
}

TrackingHeaders combines the information going to the SOAP headers of one message, in our…

View original post 495 more words

WCF Policy – Part 6: Implementation Basics

AJ's blog

We’ve come pretty far, but we haven’t done anything worthwhile yet.

As a reminder: Our tracking policy is pretty simple: Client and server should keep track of sending and receiving messages, and accumulate that information along a request/reply call as part of the SOAP call. In the end this should create a timing protocol of the complete call.

So far we’ve got the design part covered: The server announces the policy, the client recognizes it. The next major aspect is actually doing something. In this post I’m going to provide some basics we are going to need further on. Classes to maintain the tracking information, as well as SOAP related helpers.

For a single tracking entry:

TrackingEntry
{
    DateTime TimeStamp { ; ; }
    Source { ; ; }
    Reason { ; ; }
    […]
}

TrackingHeaders combines the information going to the SOAP headers of…

View original post 552 more words

WCF Protection Level

WCF has a huge security component to it and encrypts and signs messages by default. It could be an overkill especially if you are debugging or transporting data using a secured channel and are trying to squeeze out every bit of performance.

To avoid this, you can just implement integrity when confidentiality is not a requirement. In such cases, WCF provides the facility to set the protection level on the message. Also note that protection levels can only be set for messages. WCF does not allow the disabling of protection levels for transport security. The following application file snippet illustrates how to achieve this using configuration files; the messages are required to be signed only before they are sent:

<bindings>
<wsHttpBinding>
<binding name=”test”>
<security mode=”Message”>
<message defaultProtectionLevel=”Sign”/>
</security>
</binding>
</wsHttpBinding>
</bindings>

You can also specify the protectionLevel property through code at ServiceContract and OperationContract as well. Message exchange patterns (MEPs) determine how the messages are sent from the sender to the receiver. WCF does implement security support for both one-way and request-reply MEPs. However, duplex MEPs are available only in WsDuaHttpBinding, NetTcpBinding, and NetNamedPipeBinding.