During the first day of the Visual Studio 2005 Ascend training a basic overview was given of the Visual Studio Team System and .NET framework 2.0 features. The main purpose of this day was to create a mindset for all attendees to be prepared for the next three days.

Although the first day turned out to be pretty interesting, my main focus was on the three other days on which I planned to follow the “Tools and Integration” track, which covered Visual Studio Team System (VSTS) in more detail. 

It is my intention to write some more detailed postings about a few of the Visual Studio Team System features in the next coming days. First, a short list of some of the topics (without any detail) that were covered during the “overview day” of the Ascend training:

VB.NET/C#

Although it has nothing to do with VSTS or Whidbey I cannot forget the following statement I heard during the training. It is definitely not my intention to start the VB.NET versus C# debate again (and hurt anybodies feelings) but I have to admit, I totally agree with his statement J

‘The only reason VB.NET is there, is to make C# shine!”

Visual Studio 2005 Team System

Core Tenets:

• Quality
• Productivity
• Connectivity

Software lifecycle silos:

• Infra architect
• Testers
• Project leader
• Business analyst
• Developer
• Etc.

VSTS solves the communication problems between the different silos.

VSTS brings you:

• Design for operations
• Increased reliability
• Predictability
• Quality easily and often

Main goal: see how you are doing DURING the project on quality, performance, time, etc.

ASP.NET 2.0

The ASP.NET team set a few goals for their 2.0 release:

• Development productivity; Current claim: reduce 2/3 of lines of code needed to solve common issues compared to ASP.NET 1.1

• Administrating and Management; provide easy manage and administrating functionality (instrumentation, performance counters, etc.)
• Totally extensible platform; make it possible to replace an extend all build in functionality (by using provider model)
• Make it the World fastest app server

Smart Client

Benefits the rich clients and thin clients world.

It is NOT a product, it is architecture!

Two main designs:

• Data centric
• Service centric

Data centric: it is al about replicating the data. For example, replicate the data when laptop is connected using SQL CE.

Service centric: it is al about “storing the actions” (instead of data alone). Store the xml messages on smart client and “play” them against the server when connected.

System.XML

Design goals for System.XML:

• Performance improvement
• Enhanced security; in v 1.0 no security support. Now code access security for System.XML
• Enhanced schema support; infoset available in v 2.0
• More XSLT processing; 4 times faster

System.Data

Programming model:

• Provider factories (to write provider independent code)
• Provider enum

DataSet Enhancements:

• Peformance and scalability improvements
• Standalone datatable instances
• XML datatype
• User defined datatype in DataSet

Binary serialization of content (in v 1.0 always serialized to XML)

Pretty interesting first day but…. will be back with more info on Visual Studio Team System!

It’s been very quit on my blog lately. One of the reasons for this is the birth of my (first) daughter. I took some time off to fully enjoy taking care of her and get familiar to the fact that from now on there is another girl in my life J.

Next week I start working again and I think it will be a very interesting week. The company I am working for is participating in a Visual Studio 2005 Ascend program. As part of this program I am one of the lucky ones that can attend a (four day long) VS 2005 training. I will follow the “Tools and Integration” track of the course covering a lot of Visual Studio Team System related issues.  

I will post some of my experiences, thoughts and other Visual Studio Team System related issues in the next coming week!

This week I had to write a Software Architecture Document for a new project that I am assigned to. The document presents the high level architecture that will be used for the solution created in this project. The high level architecture identifies the services that are needed. These will be described in more detail (interface, messages, and implementation) at a later stage in a separate document.

When reading through the functional requirements I noticed the large number of reference tables that were described in the specs. All of this reference data is needed for (at least one of) the services and of course it has to be possible to maintain these reference data. This made me think about the best way to design this reference data within the high level architecture. After a talk with my colleague Gerke, I decided to do it in the following way:

Al reference data that is relevant for only one service will be maintained by the service itself. All reference data that is relevant for more that one service will be logically grouped in one service. For example, in the requirements for this project; country, region and sub-region reference data is described. For this, a ‘geography’ service (it’s only a name) is identified that maintains the country, region and sub-region reference data.

For this kind of reference data services, I identified two different interfaces types, one ‘query’ interface and an ‘update’ interface. Most of the service consumers of a reference data service are only interested in the query interface. The query interface is the one that will be used by a business information service to access the reference data. The ‘update’ interface will implement the so called CRUD service actions. This interface is only relevant for the one responsible for maintaining the reference data and therefore a little less important.

The same applies to reference data that is relevant to only one service (and therefore is maintained as part of the service itself). For this situation also an update interface is defined that implements the CRUD service actions for the reference data part of the service.

When implementing the reference data services, I think it is best to implement the query and the update interface in a separate ‘asmx’ file (when using .NET web services). This gives a nice and clean interface that is easy to consume for the service consumers providing them the service actions that they are interested in only. It also simplifies the authorization part of the two different types of service actions provided by the two interfaces.

During a recent project it became very clear to me that standardization (naming conventions, coding guidelines, etc.) is also a very imported issue within a service oriented environment. Probably because of the service orientation hype, everybody is too busy with all the service oriented related issues within the project that make them forget very basic things (like coding standards and guidelines).

Because of the autonomous nature of a service it is very likely that they are developed by different people (or teams). From what I saw in practise, communication between the several build teams of the different services within a solution is very limited, simply because of the fact that the interfaces are well defined (if the designer understands it’s job).  In case there is communication between the different service teams, it is mostly about the service interface and messages definition, rather than internal implementation (coding) issues. In case of a lack of standards, guidelines, etc., the end result of this is a solution (application) that exists out several services all implemented in a very different way, using different naming conventions, exceptions handling strategies, etc.

Of course missing standards and guidelines can cause the same issues (poor quality of code) in an “old fashioned” n-tier application but, because of the more tightly integration between the different parts or components in the application, developers tend to communicate more and they are more often (forced to) have a look at each other code. This will result in at least the same “standards and coding techniques” used within the whole application.

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!

Currently there is a bit of a discussion going on within our team whether to use the Remoting interface for services or not. When using EDRA, Remoting is one of the possibilities for creating a service interface, the question is: is Remoting the best option to use?

One of the ideas is to use a Remoting interface for ‘business information’ services and a webservice interface for the ‘business process’ services. I think this decision is primarily driven by a better performance that Remoting is supposed to bring us.

Personally I am not sure if performance is the best thing to base a decision on in a SOA environment. Using services implies crossing boundaries. Crossing boundaries is expensive by default! Of course Remoting can give some performance gain in this case in comparison to webservices but this shouldn’t be an issue in my opinion. If performance is what you want, don’t cross boundaries, don’t use services.

Another disadvantage of using Remoting for services is the lack of security. Of course using one of the EDRA handlers (or a custom handler) can provide some sort of a ‘security solution’ but security isn’t embedded in the design of Remoting.

It’s not that I don’t linke remoting because I do. Remoting can be very useful when using it internally in an application; in some scenarios it can be much more appropriate than using webservices. I only think Remoting shouldn’t be used across application (service) trust boundaries.

In my search for information about designing a service interface I came across some interesting postings of Aaron Skonnard about “contract first approach” for developing services. It looks like some guys are having some very interesting ideas about this. As I can read from there postings there isn’t yet very good tool support for this way of developing service contracts. Christian Weyer is having some thoughts about tool support for this. I haven’t had the time to dive into this, but certainly will very soon!