Because I have some time of in the last few days of this year I was looking for some coding stuff that I could do. To prepare for the (near) future, I decided to try upgrading the EDRA 1.1 bits to .NET framework 2.0. Just because I was curious how much time was involved in upgrading code like this. I installed the latest available release of Visual Studio 2005 and after opening the Reference Architecture solution in VS.NET 2005, the upgrading wizard left me with a little more than 100 errors and warnings. As you can see in the (very) short list below, most of the errors and warnings are because the EDRA bits are using 1.1 .NET framework parts that are obsolete in the .NET framework 2.0.

·          'System.AppDomain.GetCurrentThreadId()' is obsolete: 'AppDomain.GetCurrentThreadId has been deprecated because it does not provide a stable Id when managed threads are running on fibers (aka lightweight threads). To get a stable identifier for a managed thread, use the Thread object returned from Thread.CurrentThread.'

·          'System.Xml.XmlValidatingReader' is obsolete: 'Use XmlReader created by XmlReader.Create() method using appropriate XmlReaderSettings instead. http://go.microsoft.com/fwlink/?linkid=14202

·          'System.Xml.Xsl.XslTransform' is obsolete: 'Use System.Xml.Query.XsltCommand instead.

After a few hours of coding and searching the Visual Studio 2005 online documentation this is how (part of) my laptop screen looked like:  

I haven’t done any testing yet, I will do that the next coming days. But he.... at least it compiles!

I finally found time to do some testing with the ‘WSCF’ tool of thinktecture that Christian Weyer is blogging about. Installed the tool and followed the walk-through document. Cool!

Last week we decided to do an upgrade of EDRA 1.0 to EDRA 1.1 on our development machines. According to Microsoft, version 1.1 is the final version of EDRA. Microsoft indicates that in the beginning of next year they will start a similar project to take on the latest distributed design challenges using Microsoft’s BizTalk and "Indigo" technologies.

After making the change described my previous posting in the Microsoft EDRA 1.1 code, we compiled the EDRA 1.1 code using our own public key. After that we compiled our ‘EDRA extensions’ against the new EDRA 1.1 assemblies. Only one code change was needed to make all our code compile (Microsoft decided to change the name of one of the Handler Interfaces). Further the following changes were needed to make our test services work:

·         Remove ‘ra’ namespace prefix in ServiceReferenceArchitecture.config.

·         Move Pipeline configuration from ServiceReferenceArchitecture.config to the new ‘TemplateServices.config’ file.

·         Add two new configuration sections to specify the location of the ServiceReferenceArchitecture.config and the TemplateServices.config file.

Based on the results of our NUnit test, everything worked as expected (after the changes described above).

To make absolutely sure services implemented using EDRA 1.1 behave the same as services implemented using EDRA 1.0 we also did some manual testing against our test services. After that we had enough confidence to advice a project that is using EDRA 1.0 at this moment to do the upgrade to EDRA 1.1.

All the project has to do now is: install the new EDRA 1.1 assemblies; install the new version of our ‘EDRA extensions’; make the necessary changes in the configuration files; start system testing!

Currently, I am working myself through the WS-Policy specification. When doing this I found this very interesting article of Aaron Skonnard in which he explains how to use WS-Policy for webservice validation. The technique Aaron describes makes it possible to completely decouple validation logic from the webservice implementation, which of course improves service maintainability. After reading this article I decided to not only study the theoretical part of WS-Policy but also do some coding with it.

As I am doing some work with Microsoft EDRA at this moment, I decided to try to integrate WS-Policy into EDRA. Out of the box EDRA only supports schema (xsd) validation, so the technique Aaron describes can be very useful.

I haven’t done any testing with EDRA and WSE 2.0 yet, but according to Microsoft it must be possible. I actually do see some issues in integrating WS-Policy (WSE 2.0) and EDRA. These are not really technical issues. I think, when using WSE 2.0 and EDRA together, the WSE pipeline gets executed first. I am also almost sure that this isn’t easily changed (haven’t tested this yet). This means when using WS-Policy for doing some business validation and using EDRA for authorization, validation is executed before authorization is done. As I said, this is not a technical problem but can definitely be an issue. Of course using WSE for security is a very valid option to solve this issue.

I am very much aware that WS-Policy might change in the future and WSE doesn’t solve all related WS-Policy issues yet. One of the issues with WSE for example is the lack of policy discovery. WSE doesn’t provide a way to discover the policy statements of a service, so a solution must be found for this. In our situation, a possible solution for this is to store the URL for the service policy file together with all other service related info in our directory service. In this scenario it is at least clear where to find a service policy file if it exists.  

Although I see some issues, I think using WS-Policy in EDRA might be useful to get rid of business validations within the service implementation. I also think integrating it in EDRA doesn’t need a lot of work, so I will give it a try in the next couple of days.

Stay tuned!