I have just had my first MSDN Flash newsletter article published – I had been threatening to do it for ages, but I finally got round to doing it, to coincide with a web services event I held last week in London.

 

Here is the text for the article in the MSDN flash – be sure it sign up for your own copy of the flash, with details of articles, events and activities in the UK, by visiting MSDN Flash 

 

Recently I have been spending a lot of my time working with XML-based Web services. It's an interesting area to be involved with, for a lot of different reasons. Firstly, it's not very often that competing vendors get together to agree on a set of standards, so when it does happen (as it has with Web services) it's worth spending a little time and effort understanding them in more depth, and finding out how they are being used. Web services are the basis for a whole new layer of infrastructure that lets heterogeneous systems, built with different development tools and running on different platforms, communicate seamlessly, which makes the idea very powerful.

One interesting aspect of web services is to what extent people really understand them. In one sense, web services are indeed very simple: all they are is an XML payload wrapped up with some XML header information. Visual Studio and the .NET Framework make it a mere snap to turn a standard procedure into a Web service. Simply add a '[WebMethod]' attribute to a procedure and all the plumbing needed to expose it to the world via HTTP, and to handle the serialisation and de-serialisation of the parameters, happens 'auto-magically'.

That's fine for the canonical 'hello world' Web service, but when it comes to building the complex and sophisticated systems that are needed today, there are lots of other issues that need to be addressed, from the programming model that is exposed to developers, to issues around protocols, latency and asynchronous connections.

In terms of real world Web services issues, security has to be top of the list. If you want to expose a Web service either out on to the Internet, or inside a large organisation, you need to be confident that it is secure; that only those people or systems that are authorised to call it can actually make the calls; and that sensitive information remains secure while it flows across the wire. Fortunately, the relevant bodies have recently reached agreement on this topic in the form of WS-Security, so we now have a framework to build on - a framework that encompasses a range of exiting security mechanisms from simple usernames / passwords to X509 certificates and Kerberos.

This neatly leads on to the whole area of standards. The Web services world is currently in a state of evolving standards. The basics on which the whole Web services stack is built - XML, XSD, SOAP and now WS-Security - are stable. But when you examine more complex issues, such as the reliable delivery SOAP packets across potentially unreliable networks, or the handling of transactions across multiple web services, or dealing with long-lived interactions across heterogeneous systems, it is still relatively early days. Fortunately, there are a lot of people working to address these, and a number of WS-* initiatives under way.

The final area that I find fascinating is the work Microsoft is doing around "Indigo" .This will bake all these protocols into the stack and provide a great programming model for developers to build a whole new generation of distributed applications that communicate through Web services.

Enjoy, and start your web services work at the MSDN Web Services Developer Center