Right.  Let's talk about SOA and WSS.

OK.  OK.  Let's talk about Service Oriented Architecture and Web Service Security.

The term, "Web Services" has, by now, got past the stage of being every boss's favourite buzz word, erm, phrase.  They are, instead, rapidly becoming a familiar part of the IT landscape, and have become a favoured way of implementing a Service Oriented Architecture (SOA).  So what's that?  Well, it's a way of building powerful applications made up in whole or in part of services provided by remote computers, possibly belonging to organisations other than your own.  Google, for example, provides a Web Service-based application programming interface (API).  You can use this to do keyword searches in your own application without having to worry about how a keyword search is actually done.  In other words what we are doing in a Web Service is to arrange for a client machine to ask a server machine to perform some service for it - i.e. to run some procedure or other and to return (send back) the result of executing the procedure.  In the case of the Google API, we ask one of Google's servers to run a search for us and to send back the search results.

In order for this to work, all the participants in the game have to agree on what the rules are.  Yes, we're back to standards again.  There are quite a few different standards in this field, probably reflecting its comparative youth.  No doubt a single standard will emerge over time.  For the purposes of this article, I'm going to assume that we're talking about the Simple Object Access Protocol (SOAP) and the Web Service Definition Language (WSDL) - so you should too, if there's to be any communication between us.

Now, the whole point of these standards is that it should not matter what kind of program is running at either end of the communication.  So long as they both stick to the protocol, everything should be fine.  A C# program using the .NET Framework, running on a Windows machine should be able to exchange messages with a Java program running on a Linux machine and using the Apache Axis framework absolutely seamlessly.  And that's pretty much what happens, but, as usual, there are exceptions.

In the early days of Web Services, nobody gave too much - some would say that no-one gave enough - thought to security.  As Web Services have become more popular and organisations have started using them to pass confidential information about the place, security has become a much more pressing issue.  As a result there are a number of standards dealing with Web Sevice security.  If you're really having difficulty sleeping you can read about them on the OASIS site.  They are extremely complex and, of course, add a layer of complexity to any programs that use them.  They also increase the chances that the parties at both ends of the Web Service communication might misunderstand each other - either because there are bugs in the implementation at one end or the other, or because the implementations have interpreted the standard differrently.

So why am I telling you this?  Well, it's been my misfortune over the past few weeks to try to use a Web Service exposed by one of our partners (the UK Student Loan Company).  My program, like all those I write at work, is written in C#, a .NET language.  The Web Service I've been trying to communicate with uses the Java Apache Axis Framework.

Normally, this wouldn't be a problem, but this service demands a certain amount of security because of the nature of the information being passed.  It's not terribly confidential.  We're not talking about student loan details, for instance; but it's a private conversation nevertheless.  The Web Service therefore has the following characteristics:

• Communication is over an encrypted connection (SSL)
• The SOAP header (the first part of a Web Service message) must contain the client's user name and password in clear text
• The server authenticates to the client using an X509 Certificate
• The client does not authenticate to the server
• No encryption over and above the transport layer (SSL) encryption is to be carried out.

Wouldn't you know it?  This is not one of the standard configurations that can easily be configured using the .NET Framework (and the Visual Studio integrated development environment).  There also seem to be some strange features in the Apache Axis Framework implementation, which mean that:

• Sending a message under these particular circumstances with a <Timestamp> element in the SOAP header - supposedly a mandatory field - will generate an error from the server
• The response to at least one message results in an XML document that does not conform to the schema set out in the WSDL file.  Our partners believe this to be a bug, but whatever it is, it has to be dealt with.

It turns out that on the client side, the solution is:

• To create a custom policy assertion class that filters both output from and input to the Web Service.  This is done by creating two custom SoapFilter classes that are called to filter (alter) the input to and output from the Web Service client.
• The filter for outgoing messages looks for the <Timestamp> element and deletes it before the message is sent up the wire.
• The filter for incoming messages looks for the malformed XML (which is on the <code> elements) and corrects them by adding a namespace definition.  As it happens the attribute that the namespace is defined for is entirely redundant, but it turned out to be easier to add the namespace definition than delete all the unnecessary attributes.  The corrected XML is then fed to the .NET Framework Web Service client handling plumbing.

They don't tell you this sort of thing in any of the standard texts or on any of the standard courses and, for the first time in my experience, all my newsgroup and mailing list postings went unanswered (with one exception - and my grateful thanks to Evan Freeman of the microsoft.public.dotnet.framewok.aspnet.webservices newsgroup for his moral and practical support).

In the hope, therefore of preventing frustration-driven rapid hair loss syndrome amongst .NET programmers, I have published a document on my personal Website that goes into all the gory details of what was done and why:

Microsoft dotNet WSE 3 Web Services.pdf

I hope it helps someone.  And if anyone has any suggestions as to how the document could be improved, or corrections or other improvements, then I'll be only too happy to act on them if I agree they'll help.