AJ's blog

November 23, 2014

WCF Policy – Part 1: What is policy about?

Filed under: .NET, .NET Framework, SOA, Software Architecture, Software Development, WCF — ajdotnet @ 3:16 pm

Remember what I described during the introduction? Switch a feature on on the server, and the WCF takes care that this information gets pushed through to the client, at runtime client and server work together to fulfill the demand, and on top of it the developer can interfere if necessary.

Add the tiny fact that the “feature” in question usually adheres to some standard, and you have a policy and its implementation – in our case a “WCF Policy”. Let’s look into this a little more in detail, as this defines our to-do-list for the upcoming posts.

Note: This post is part of a series. The TOC can be found here

Policy explained…

The world of services is based on various standards. These standards provide the set of features to choose from. Defining how a standard is employed by a particular service is actually defining the policy for said service.

Now, bringing this – so far abstract – concept of a policy to live in WCF includes several aspects:

  • Initially the developer needs some way to activate the feature on the service (or – rarely – the client), i.e. to switch it on and configure the details.
  • At design time the policy has to be advertised by the service. The most basic aspects like transport protocol and message format are already addressed in the WSDL and XSD. For everything that goes beyond that we have WS-Policy. On the server the information needs to be put into the WSDL, on the client it needs to be evaluated to generate a respective client proxy.
  • At runtime the policy has to be implemented by some runtime component; again, client and server.
  • Additionally, information implied by the policy should be accessible by the developer. Depending on the actual demand, this may be informal, he may be able to interfere, ore he may actually be required to provide additional input. (Say the username and password for basic authentication.)

Example…

OK, let’s make this a little more tangible and have a look at how it applies to employing WS-Addressing in WCF. This will also define the to-do-list for our own custom policy…

Initially the developer needs to declare that his service uses WS-Addressing. WCF covers WS-Addressing through different bindings. WsHttpBinding does it implicitly, a custom binding configures SOAP and WS-Addressing versions as part of the message encoding:

The binding also takes care of advertising the policy in the WSDL. Since WSDL itself has no knowledge of WS-Addressing, WS-Policy comes into play. WS-Policy is by itself a rather dull standard. It merely defines how to place additional information (particularly for the use of policies) in the WSDL. In our case it might look like this:

The element wsaw:UsingAddressing is called a custom policy assertion provided by WS-Addressing – Metadata – in general an arbitrary XML fragment. WS-Policy also provides means to define combinations and alternatives between policy assertions.

WCF also addresses the client side by generating a client proxy from a respective WSDL. This process includes handling policy assertions and generating the respective configuration (e.g. by choosing the appropriate binding) or code.

At runtime the actual behavior kicks in: The WCF client automatically generates a message ID for the SOAP request and includes it in the message as SOAP header:

The server takes the message ID and includes it in the reply message using the RelatesTo SOAP header.

Additionally the developer can access the message ID on the server and manipulate it, as he likes.

Summary…

To summarize this, here’s what makes up a policy in WCF:

During design:

  • Definition of the underlying standard

During development:

  • A way to switch the policy on and to configure as necessary
  • Advertising the policy in the WSDL
  • Evaluating the policy assertion during client proxy generation

During runtime:

  • Establishing the default behavior on server and client
  • Providing an interface to the developer

And this defines what we’re going to have to do – in the following posts…

 

That’s all for now folks,
AJ.NET

Advertisements

Building Your Own Policy with WCF

Filed under: .NET, .NET Framework, C#, SOA, Software Architecture, Software Development, WCF — ajdotnet @ 2:55 pm

Flexibility and extensibility of WCF is really great. You need a feature provided by the platform? Just switch it on, via code or configuration, and all the bits and pieces follow suit. The fact is advertised in the WSDL; the client proxy generation will pick that up and produce respective code and configuration; both, client and server, do their part to make it work at runtime; and last not least the developer usually gets the means to access or manipulate the respective information, should the need arise.

Wouldn’t it be nice to have the same apply to your custom demands, demands not covered by the platform? Demands like…

  • New versions of standards you need to support, but which are not supported by the platform yet.
  • Homegrown authentication schemes.
  • Tenants for multi-tenant solutions.
  • Billing information for services in B2C scenarios.
  • SLA and diagnostics information for operations

Whatever the reason, it would be very nice if we could implement our custom policy in a way that the application developer could use it in a way very similar to policies provided by the platform.

The good news is: It is actually possible to support custom demands in a way very similar to the built-in features of WCF.
The not-so-good news: It is not that simple or straight-forward to do, as there a a lot of bits and pieces working together – and no single information source putting them together. Well, this is what I’m trying to accomplish…

So, here’s the agenda for this little adventure:

Design time aspects:

Runtime aspects:

Looking back:

Quite a bit more than one post…

So stay tuned…

That’s all for now folks,
AJ.NET

Blog at WordPress.com.