WS DevCon: Tim Ewald: Building Web Services using System.XML

Tim is a big proponent of what he calls ?XML Way? of doing web services. This basically means using XML (as oppose to object models) as data representation for a web service. His weblog has a note explaining the concept.

Tim didn?t only talked about it, he also presented some practical solutions with example code that shows how to customize C# [WebMethod] (Tim pointed to his home page for source code) to get access to XML from within a method. Tim explained that [WebMethod] attribute really does three very different things:

-          dispatches SOAP request to the right method

-          generates WSDL (using reflection)

-          Marshal parameters

There?s a way to turn off WSDL generation. This is handy if you?re doing web services the ?right way? (WSDL first). There?s a way to turn off parameter marshalling as well. I think this may be handy if you?re dealing with some odd XML coming your way or need to optimize the way your handling XML. Once you turn off these two [WebMethods] features, you can still them to dispatch messages to methods.

It is nice to know you can access raw XML in .NET WS, but I?m not convinced one would need to go down to this level without a really good reason.

 

WS DevCon: Keith Ballinger: WS-Security support in .NET

Keith?s talk made me understand why we can?t just use SSL to secure Web Services. In a nutshell, it comes down to two arguments:

-          There may not be a direct connection between client and server. Web services requests can travel though intermediaries who have to understand the routing instructions, but cannot be trusted with the contents of the payload itself. Using SSL would obscure such routing information and make it impossible for the intermediary to process the message.

-          WS protocols must remain independent from HTTP. SSL secures HTTP traffic, but won?t help with other protocols that may be used to deliver a SOAP message.

 

Keith?s talk was a good intro to WSDK, but didn?t remove the need to read the documentation. It was pretty clear current incarnation of WSDK services will require developers to do quite a bit of hand-coding. It should get better with future versions.

 

WS DevCon: Clemens Vasters: Web Service Extensions for ASP.NET

Clemens presented his way of using SOAP extensions to insert all kinds of useful things into ASP.NET processing pipeline. I was very impressed by the elegance of the design and the care Clemens took in terms of delivering the best user experience.

Here?s what I understood: What he come up with is essentially an attribute-based approach towards extending a WebMethod. Want to add authentication? Just add [KerberosAuthentication] to the WebMethod. Want logging? Add another attribute.

Once the attribute is set, Clemens? code does a lot of plumbing ? modified WSDL; update *.config files, inserts the extension handler before and after your WebMethod call.

But that?s not all! On the client side, once the WSDL is used to build a proxy, the thing actually reads the WSDL, finds the SOAP extensions; generates the code using System.CodeDom.

Using this design newtelligence have implemented the support for WS-Security. The difference with WSDK is striking ? Clemen?s way is much simpler to use. KeithBa should definitely take note and consider adopting this design for WSDK.

(A few days after the conference Clemens has announced a wizard that generates soap extensions. Nice!)

 

WS DevCon: Rich Salz: What WS Needs to know about PKI

Rich gave a broad overview of crypto, PKI and XML security standards. I?ve learned that there?s much more to XML security than WS-Security.

Talking about digital signatures, Rich mentioned canonicalization ? the process of getting the one canonical XML string from an infinite set of different XML documents have only in insignificant differences (white space, order of attributes, etc). Rich pointed out that canonical XML is not the same thing as PVIS (post validated infoset). It seemed odd at a time, but now it makes sense. XML Schema defines PVIS in terms of data structure that satisfies a particular Schema. Since XML Schema was designed to define data structures for any kind of medium  (not just XML) it cannot possibly prescript things like the order of XML attributes or the amount of white space between angle brackets.