P&P Summit Day Two: Contractual Zen

 

The first after lunch session is being presented by Scott Hanselman and Patrick Cauldwell. To start with before the session they were running comedy sketches on the big screens, like a music video entitled “White and Nerdy” off utube and a fake switch to Linux commercial . Very funny stuff.

The talk is based on the architecture that Corillian, the company Scott and Patrick work for, used to define their services. They use a contract defined by a WSDL file and do not use asmx services.

Scott starts off talking about how .Net is the spackly, or putty, over the windows APIs. Under the spackle are 3rd class APIs. These are the low level APIs that actually do the work, like load library is covered over by CreateOjbect and the new keyword. As you build your own objects over the .NET framework you are adding additional spackle. At each class level we start to see that we are going from the generic (like select statements) to the more domain specific (such as accounts). Their product is called Voyager. It’s a C++ application that has a SDK wrapped around it to become the 2nd class level. The work built on top of the SDK becomes the 3rd class level.

They describe that prior to the idea of contracts took hole in their systems most communication between objects and systems was completely error prone and very convention based.   

They started to define their domain objects completely in xsd format for objects and wsdl for their contracts. These were then used to generate the code artifacts that became the classes and interfaces. They include platform specific operations and tags within the wsdl to help drive some of their code generation down stream. They use CodeSmith and NANT tasks to take the wsdl and xsd files and code generate their classes and interface files that they can compile into assemblies. The entire process can be reverse engineered so that they can take an assembly and break it back down in xsd and wsdl files.

Their goal was to take the Voyager application and put a SDK over the top with strongly typed contracts. Then, when they want to, they can then change the underlying Voyager system and not affect their consumers.

In order to not have to specifically code their services as Web Services they have set up HTTP Handlers that can deal with a request for wsdl information and calls to translate those requests into the calls of the objects and contracts based on all the information in their objects. This means groups within Corillian can just define a contract, code behind the contract what it is supposed to do, then drop it in a folder and a HTTP Handler deals with exposing it as a web service automatically. This turns out to be much like what WCF does with service descriptions.

This creating their own HTTP Handler endpoint to deal with the requests also allows them to overcome issues where consumers can’t talk SOAP. They can extend to other wire formats very easily by just adding a new HTTP Handler to do the translation and expose the code. All the while still using the same wsdl and xsd files for the code generation and underlying compiled code.

During the upgrade to 2.0 all they had to do was create new CodeSmith templates and recreate their NANT tasks in MSBuild Tasks and using the same xsd and wsdl files and then regen the code and it all just worked. Pretty sweet.

Contraxploitation - Exploiting your contracts!

Think :

• About your Service Description
• About multiple transports

Do:

• Exploit your contracts
• Extend your reach to other systems
• Put a stake in the ground

Feel:

• Enabled to generate more code
• Comforted by your layers of abstraction

Find the locations in your own code where you actually have service descriptions and start from there. Use those descriptors to create contracts and then put your design around the contracts.

A side note on my part: They use a LOT of custom .NET attributes. Interesting, but they didn’t talk about them much. I’d like to see what all they are doing with them.

Sorry if this post jumps around a lot, but I was typing it as they were talking and there was a LOT of info coming at me at once. Good stuff. Very flexible, but complex. It’s a good thing that the end developer is only exposed to the 3rd class API!