Blogging about things you did two days ago is strange because you really want to fast forward to the cool stuff that you have learnt since then. Anyway – let me summarise what we looked at on Thursday of the Indigo Ascend Training.

After we got past the entry level (but essential) stuff on Wednesday we moved on to look more closely at some of the features that Indigo must have in order to support what people are already doing today with a fragmented set of tools. Specifically we looked at:

• Security
• Reliability
• and Transactions

As well as:

• Interoperability
• Integration
• and Migration

Obviously thats quite a bit to cover in one day but if you are familiar with some of the existing specification work in this space it helps quite a bit. The big question out there in the industry right now is “how do I secure my web-service?” and with the current tool-set its a little convoluted – even with WSE 2.0.

In this post I am going to quickly look at two configuration options you can go with and how they affect security.

Just to recap, service implementations themselves know very little about how they are bound to the network and what underlying security protocols are used to secure communications. They are “bound” to the network via a “binding” and an “endpoint”. Bindings represent a grouping of configuration settings which dictate what kind of transport endpoints use to communicate with each other.

They also define what contextual information is passed between them – including credentials, transactional context and reliability semantics (although transport selection comes into play here too).

The two bindings that I will look at in this post are the basic profile binding and the WS profile binding. What they do should be obvious from the names – no? OK – lets look a little bit more closely then.

Basic Profile Binding

Back when .NET 1.x was released web-services were still in their infancy, in fact you could argue that the web-services stack offered up by ASP.NET with *.asmx files represented to most mature effort to date – but it still had limited support for critical enterprise capabilities such as authentication, privacy and non-repudiation.

The basic profile binding is designed to interoperate with solutions built with this set of tools (the current set of tools). I provides no message level security options and relies on the underlying transport to encrypt and authenticate communications. The WinFX SDK has a nice entry which summarises the predefined bindings supported out-of-the-box in Indigo.

Bindings can be specified in configuration files or by manually instansiating the type that represents the configuration options. Configuration is fairly straight forward, in the bindings section under the <system.serviceModel /> element you add a <basicProfileBinding /> element and specify the configuration name.

The configuration name is used so that you can have multiple endpoints bound to the same kind of binding but allowing each of them to have their own customisations. The code equivalent to the above configuration would include instansiating the BasicProfileBinding class which exists in the System.ServiceModel namespace.

Once the proxy reads in its configuration for the basic profile binding the SOAP envelope that it sends to the recipient endpoint is extremely basic (hence the name).

If you have ever sniffed traffic on a .NET 1.x web-service call the above should look pretty familiar – and simple. The WS profile binding on the other hand is a much more complicated beast by default – so lets have a look at that.

WS Profile Binding

The interactions between the client and server endpoints when using WS profile involve a number of round trip calls to establish a secure session. For our simple hello world example eight messages were transmitted.

The first six messages are all to do with establishing the session using SSPI security tokens, I don’t know a lot about SSPI but I do know that if it were easily compromised then Windows networks would be up the proverbial without a paddle.

• First Six Messages (1, 2, 3, 4, 5 and 6)

The last two messages contain the actual request to and response from the service, although the contents of the message are inaccessible to us because of encryption and signing (and are two large to provide a screenshot of). The configuration file however is pretty much the same.

I guess the take away here is that the services are abstracted away from having to know too much about the underlying protocols, although in my experience messaging technologies tend to be at least semi-aware in order to get the most out of the computing environment (at times changing?).

Transactions Across Autonomous Services

Well – that was just a quick taste of security, there are heaps other subjects that were covered on day two and I hope to write about them in seperate posts, however, I did want to touch on the subject of transactions in the web-services world.

There was certainly some lively discussion about transactions in a web-services context but I think everyone agreed that there are some architectural issues that need to be appreciated when trying to achieve consensus across autonomous parties.

We had Jim Webber who among other things is associated with the SSDL effort, he is also extremely smart. Through a group discussion Jim alerted me to the WS-BusinessActivity (PDF) specification as a standard approach for multiple parties to achieve consensus and commit to performing work (being very careful not to call these transactions and mistakenly convey atomic semantics).

Basically - it all boils down to compensation and how you achieve it. The WS-BusinessActivity specification promotes a standard approach – however I feel that compensating business transactions is too important to abstract away from the actual business – in fact I think it may be to hard to even define as part of your own custom message exchange pattern.

Jim did point out that WS-BusinessActivity is a framework which you can extend to add contextual information – but it still makes me feel uneasy. I’ve got a few things on my TODO list over the coming weeks which include.

• Read and digest WS-BusinessActivity.
• Read and digest SSDL (have already skimmed).
• Re-read WS-Security, WS-SecureConversation and WS-Trust.

Next Up

I am going to post up about the third day fairly soon, although I am still just beginning to grok the extensibility story in Indigo and I want to provide a few examples.