I just finished submitting my first article "idea" submission to MSDN. If they like it, then I'll send them the whole article. If they don't, then I'll write the article anyway and post it somewhere on this site. (But I'd love to actually get an article accepted by MSDN!) They say that it will take a couple of weeks before I hear any response... <finger's crossed>

My thoughts exactly...
SOAP isn't Dead

The development that I've been doing recently has revolved around the creation of two custom XML security tokens for use within our internal web-services framework. One of the major design goals that I've had was to reduce the complexity of retrieving, sending and validating the tokens within the service consumer and provider environments. We've had fantastic success getting the consumer-side implementation down to only a couple of lines of code. More could be done to reduce the amount of required development effort for a service consumer, but allowing developers to maintain a level of control over the storage and scope of the tokens is important as well.

The server-side, however, needed a method of enforcing some basic validation through simple configuration at the time of installation. I had started down the path of using custom application configuration settings in the service's web.config file to provide this configuration requirement, but I soon realized that it was not having the desired effect. The validation code was either explicitly called from the service's code-base, or it was only running when the custom token type was included in the message. This meant that either the developers building the service had to take time to focus on the token handling, or that the token would only be validated if it was provided. Neither of these situations meet our requirements.

The solution came to me as I spent some additional time thinking about the problem... Policy should always be configured within the policy document. The last thing that I needed was to find out how to extend the policy support of WSE2 to include my token types. I got that answer from this MSDN article. The more I work with the WSE2 framework, the more I love it. The development team for the WSE libraries has provided us with a great start for implementing the WS-* specifications within our environments today, but they have also left the door wide open for extending their work to support more complex senarios. It's wonderful.

Now if only the Java development community would catch up with Microsoft's support for these specifications, my life would be much easier. We've got to port all of the token logic into the AXIS world to support service consumers and providers on Unix systems as well.

About a month ago, a unique cryptanalysis of SHA-1 exposed a vulnerability in the algorithm that allows for a non-brute-force crack of a SHA-1 signature. The best description of the approach that I have found is Bruce Schneier's post: Schneier on Security: Cryptanalysis of SHA-1.

I wanted to include a quote from Bruce's post that describes the effect that this new technique will have on our everyday life (as technology professionals):

For the average Internet user, this news is not a cause for panic. No one is going to be breaking digital signatures or reading encrypted messages anytime soon. The electronic world is no less secure after these announcements than it was before.
But there's an old saying inside the NSA: "Attacks always get better; they never get worse." Just as this week's attack builds on other papers describing attacks against simplified versions of SHA-1, SHA-0, MD4, and MD5, other researchers will build on this result. The attack against SHA-1 will continue to improve, as others read about it and develop faster tricks, optimizations, etc. And Moore's Law will continue to march forward, making even the existing attack faster and more affordable.

As for my perspective, I just believe that this highlights the need to continue funding cryptographic research on both ends of the spectrum: creating algorithms and breaking them. It should also serve as a reminder to application architects and developers to keep our application logic seperate from the particulars of the cryptographic algorithms being used to sign / verify or encrypt / decrypt data in our applications. Our products need to be able to switch selected algorithms with as little effort as possible. While this may not have to be a runtime change, it should at least be as minimal a code change as possible.

Rick LaPlante is asking for people's opinions about Team System's ability to support nDoc (and other types of tools like that) here.

My answer is that Microsoft should be cognizant of the community developed projects surrounding their products, and try to support these tools through communication with the community.

In the case of nDoc, Microsoft should support the nDoc development team by providing them with enough information to integrate their tool into the VS IDE. I would bet that they are already planning to provide more than enough documentation for developers to build plugins into Team System (as they had with the VS.NET 2003 IDE), and I suggest looking to the nDoc development team to actually take advantage of this option!

James Geurt did a great job combing through Brad Abrams' Blog to compile a list of Microsoft development and design guidelines here.

Mike Gilbert makes a really good point here about how to use the data objects as return types in XML Web Services.

Recently, I had been trying to come up with a better methodology for allowing these data objects to include "functional" code than what was supported by the classes generated from a WSDL. Since reading this, I've realized that I've been thinking about the problem in the exact wrong way. It's not that I didn't know the tenets of SOA. It was more about forgetting to apply them.

So, that project that I was working on has since been refactored into:

• A simple data container class with the XML Serialization attributes applied to the class and its members.
• A class that can handle the basic functionality required to work with that data class.