One of the sessions that I attended today at Tech-Ed Europe is “Building and using Software Factories” with Steve Cook and Annie Matthewman.

I have been reading quite some stuff about Software Factories lately. I even started the book called “Software Factories” but haven’t finished it yet. Although there is quite some information available it kind of bothered me that most of it is purely theoretical, I haven’t seen any real implementation of a Software Factory yet (until now).

Steve first gave some basic information about Software Factories. One of the, maybe obvious, things he stated was that is it only useful to build a Software Factory if you build similar systems every time. If that is the case, the next thing you have to define is a “package” of reusable knowledge that eventually can form the Software Factory. So, in order to be able to build a Software Factory you first need to know what is available and how it can be reused.

The reusable items can vary from a piece of documentation, an architecture baseline, code snippets, wizards, etc.

Summarized, a Software Factory can be described as:

·         (customizable) structured collection of assets.

·         Software Schema that defines the context for the assets.

·         Explains people what to do.

·         Helps people do it.

One of the goals for Software Factories is: easy things should easy and difficult things should be possible.

The second part of the session covered a demo of a real implemented Software Factory. The Software Factory provided guidance for building a “wizard like” windows application communicating with web services.

To support building Software Factories, there are actually two new “technologies/toolkits”. One of them concerns Domain Specific Languages (DSL) and helps building DSL end the appropriate DSL designers. The other toolkit is the Guidance Automation Toolkit (GAT).

For the Software Factory that was demonstrated Steve and Annie actually build a “new” DSL for this problem domain and an appropriate designer for the new DSL. Building this wasn’t covered in this session, but will be covered in another session.

The GAT is a relatively new toolkit that is downloadable from the Microsoft website. The GAT can be best described of a Software Factory for building Software Factories.

From what I saw in the demo one of the pieces of GAT is  a (very) big XML file that describes the activities, actions and their contexts that together form the  (part of) Software Factory. When a Software Factory is build by using the GAT the end result all integrates very nice with Visual Studio.NET helping the developer building the piece of software that is supported by the Software Factory.

I haven’t actually spent time on evaluating the GAT yet but the demo looked pretty cool so I think I will give it a try soon.

This is my schedule for Tech-Ed Europe 2005. Looking forward to some (in my opinion) very interesting sessions and speakers. The sessions are a mix of the “connected systems“  and “architecture“ track. For most of the timeslots I choose an alternative session, just in case there are no seats left in the room when I arrive.

 If you happen to be in the same sessions, say hello, I’ am the one carrying a Tech-Ed bag J

Because I was assigned to project it wasn’t sure if I could make it to Tech Ed 2005 Europe. Luckily, we found a replacement for me at the project J. So I will be there!

Interested in more in-depth details about the implementation of the WS-I Basic security profile application? 

Go read the blog of Hernan de Lahitte who was member of the dev team. I a series of posts he will share his experiences in building this sample and talk about the issues that came up.

Currently Microsoft is working on a sample application that is compliant with the WS-I Basic Security Profile (BSP). This sample application shows you how to build secure web services using WSE. Besides this, the sample also demonstrates interoperability issues and gives some guidance on how to design services that can evolve technology changes by separating the business logic from the transport.

The sample is a “preview release” because the BSP specs don’t have the final status yet. The preview is built using Visual Studio 2003 and WSE 2.0. The final release (which will be available after the BSP specs are final) will be implemented with Visual Studio 2005 and WSE 3.0.

I was one of the lucky ones (J) participating in the reviewing team. So, I had the change to look at the code in an early stage and provide some feedback. I think that this sample is definitely worthwhile spending some time on for anyone interested in web service security and interoperability.

 The sample application will be available somewhere in the coming weeks. Today there is already a webcast available from the Patterns and Practises live site (direct link WS-I BSP webcast) for download. Go check it out!

Currently, one of my colleagues is working on a small assignment to investigate the possibilities of Microsoft Information Bridge Framework (IBF) when it comes to exposing web service functionality to end users. The main goal of this investigation is to determine if IBF is able to communicate with the web services that apply to our internally used reference architecture.

Personally I am not very impressed by IBF yet, but that’s probably because I know very little about this tool. What I do know is that Microsoft is positioning this tool as a key player in its “information worker” marketing strategy so it must be good! For me this tool is just another way to make sure the end user (or should I say Information Worker) continues using the Microsoft Office suite which is probably one of the most important products for Microsoft’s profit. Another thing I know is that many people (especially managersJ) see a lot of opportunities for this tool so we decided to give IBF a fair change.

Therefore my colleague was asked to test if IBF is capable in communicating with “secure” web services. In our case this means that IBF has to communicate with web services that use SOAP headers to support sending “user token” information. After some investigation it turned out that IBF cannot handle SOAP headers (or at least not populate the headers in a “flexible” way). Because I found this very hard to believe I did a quick search on the internet and all found was the capability of IBF to handle “transport layer” security. I noticed that there is very little information available on the internet related to IBF and security. In my opinion using SOAP headers is kind of straight forward when it comes to web services, but I might be wrong.

Is it true that IBF doesn’t support SOAP headers? If so, will this be supported in a next release? If not, IBF is definitely no option for us (at this moment).

If there is anybody out there that can point me to some more information about this, please let me know!

It’s been some time since I have written anything on this blog. I have been busy in the start up phase for some projects. For one of the projects I will be assigned to in the near future, interoperability and web service security will be a big issue. To refresh my memory I decided to go through the Basic Profile 1.0 (BP) specification once again. This profile provides implementation guidelines that help you build web services with maximum interoperability. The web services interoperability organization (WS-I) provides sample implementations (build by different vendors) that demonstrate web service interoperability across the different platforms.

Currently the WS-I is working on the Basic Security Profile (BSP), which covers building interoperable secure web services. The BSP covers guidance for both transport level security and (soap) message level security. Personally I am more interested in the message level security issues. To understand the BSP better I am also spending some time again on the WS-Security specs which describe in detail how to secure web services on the message level. Of course when thinking of web services and security in a Microsoft world we cannot forget WSE, so that is also on my ToDo list again.

At first, reading through these WS-* specs and profiles doesn’t seem very interesting but having a detailed look at the implementation that is available (WSE and BP 1.0 sample application) makes life a little more interesting. After having spent some time on it I even start to like it. So, maybe I’ll be back with more info about web service security soon. (I promise I’ll try to make this blog not more boring than it already is).

One of the new buzz words in IT is “Software Factories”. Although this methodology is in its very early stage, I think it is important to understand the concepts behind this methodology. Because Software Factories is a “new concept” and the topic covers a lot of new stuff, introducing these concepts can be hard (at least for me). Therefore I am looking for a way to get familiar with Software Factories bit by bit. Maybe, mapping Software Factories to concepts that I am already using at this moment can help. At least it gives me a starting point from were I can think about Software Factories and explore the possibilities of this new methodology. Let me share some of my thoughts about the roadmap I think is best for me to get familiar with Software Factories and start working with it in the near future.

Software Factory

In short, a Software Factory can be best described as a fully configured development environment for developing a particular type of software. Based on the fact that currently software development isn’t as successful as we want it to be this new methodology is introduced. The methodology is build on experiences gathered from more successful and much more productive industries like for example the car industry. Within these industries it is very common to use highly standardized processes, predefined designs and reusable components to rapidly manufacture products. This results in a very productive manufacturing process with predictable quality of the manufactured products. Lessons learned from these industries are now used to create a new methodology, called Software Factories. Software Factories targets the software development industry and aims to provide the same kind of advantages achieved in other industries.

Although Software Factories are still evolving and the methodology isn’t fully supported by tools yet, I think it is possible to start using some of these concepts in software development. To explain what I think can be done today, let me try to map the concepts of Software Factories to concepts that are more common (for me) within software development. For this purpose, let’s assume we have a logical architecture defined within our organisation that we are using for software development. Let me explain what I mean by a logical architecture (I will not cover this in detail at this moment, just enough to make my point. This is just my imaginary architecture J).

Logical Architecture

A standardized logical architecture can help architects break down the requested business functionality to one of the different responsibility domains. Well defined responsibility domains provide guidance to IT project members during the design and implementation phase of a software development project. Some of the keys to success in this area are standardization, patterns and frameworks. Having these in place makes software development more manageable and can guarantee a constant quality. Most of the time there is some guidance available, very often in the form of a Word document or some standard components (framework) that can be used. Unfortunately the usage of these guidelines isn’t embedded in the whole development process and is not supported by development tools at all. Let’s have a look at how Software Factories can help solve this “problem”. To make things more clear let’s assume we have a logical architecture defined within our company. Within this architecture we make a distinction between different domains:

·         Presentation domain; this domain hosts all user interaction related features. It hosts features like dialog management, multi channel support, etc.

·         Process domain; this domain is responsible for controlling the actual business process. The business process can be best described as the way an organisation is handling its procedures, workflow, tasks and information. The business process coordinates the tasks and makes sure they get executed by either communicating with the end user (through the presentation domain) or the business information services.

·         Business information domain; this domain maintains all information within the organisation. Information can be grouped together in logical area resulting in one or more business information services. Business information services are autonomous services and deliver information, or perform a business action on behalf of the business process.

·         Infrastructure domain; this domain represents the infrastructure that will be used for the application. This includes the messaging infrastructure and other generic services providing the so called ‘cross-cutting concerns’ (e.g. security, logging, instrumentation, etc.). Services and features included in this domain are not application specific and can serve more applications at a time.

From logical architecture to Software Factory

So, now we have our logical architecture defined, what’s next? The reason we defined separate domains within our logical architecture is to group together services with similar responsibilities or capabilities. In the ideal world there should be guidelines available that helps architects and developers to implement services in one of the above described domains. These guidelines can be in the form of a simple word document but can also be represented by a framework or a set of patterns that must be used by the development team. This is exactly where I think Software Factories come in!

Software Factories aims to provide a fully described and configured development environment for a specific type of application (read: domain) Thinking a little further and having a look at our logical architecture I can define at least four Software Factories (one for every domain in the logical architecture). Although four fully implemented Software Factories should be sufficient for providing the necessary guidance for implementing services or components in each of the four domains, I think I am not there yet! I still need a standardized way for translating the business needs to components or services in one of our four domains. To solve this issue I can create another Software Factory that provides guidance in mapping the business requirements to one of the described domains in our logical architecture. This overall Software Factory can be my factory that targets web based distributed applications and is composed out of the other four Software Factories. The five Software Factories together cover all concerns for building web based distributed applications.

Because I defined five separate Software Factories (instead of one big one) each of the factories exactly targets a group of people in an ordinary IT project. The overall Factory for example, targets the business analyst and the architect who work together to gather the necessary information from the end user. This software factory describes the process how to translate and group together the requirements from the end user to services in one of our four domains. The Factory that targets the presentation services domain provides the web developers in the project with the necessary patterns, frameworks, and guidance to implement the user interface services and so on for the rest of the factories.

So, now I defined my Software Factories, what’s next on my to-do list?

Software Factory schema and template

One of the important things in Software Factories is a software factory schema. Basically this is a document that summarizes all artifacts we need to produce, to successfully develop a piece of software. This schema doesn’t only tell us what products we have to deliver and how they look like, it also tells us in what order we have to do this and what is the relation between the several products. The software factory schema contains both fixed and variable products which makes the software factory more flexible. Having a well defined software factory schema isn’t actually new (except for the name). Some other methodologies (like RUP) also summarize and describe the artifacts that must be created during a software development project. However, I think there are some differences between these methodologies and the Software Factories methodology. Within Software Factories the list of artifacts and the description of the artifacts are much more targeted at a specific type of software. Other methodologies tend to have a more general way of describing the artifacts, they don’t really target the specific domains in our logical architecture for example. I think the advantage of the software factory is that in the end it provides much more guidance!

Having the full list of artifacts (and their description) in place doesn’t do the job. To make it really useful we need the implementation of all these artifacts and more importantly we have to make them available to the development team. This is where the Software Factory template comes in. A Software Factory template is a collection of patterns, frameworks and a Domain Specific Language (DSL) that can be loaded into a tool (for example Visual Studio 2005 Team System). The combination of the software template and the tool helps us automating the software development process. One of the main purposes of the template is to configure the tool and “guide” the development team through the process of building a specific type of software (in our case, software that fits in one of our domains in the logical architecture).

So, where are we? If we think Software Factories is promising enough to invest in, I now have a possible approach to start implementing (or at least think about it) this methodology step by step within my daily work. I can simply pick one of the responsibility domains within the logical architecture and start describing the artifacts that we need to successfully deliver software within that domain. Although I think this still is a lot off work (and challenging), focussing on one responsibility domain can help to reduce the complexibility. By the time I defined and implemented the artifacts for the first responsibility domain, Microsoft might be ready to provide me with the (stable) tools that make it (better) possible to write my own Domain Specific Language’s and support our Software Factory from within our development environment (VSTS).

The above are my first steps in the world of Software Factories. If any of you have a better approach to get familiar with this, please let me know!

Team Foundation Server provides the core functionality for integrating all of the Visual Studio 2005 Team System parts/tools. One of the services available in Team Foundation Server is the “Source Code Control Service”. This service makes it possible to interact with the core source control features of Team Foundation Server.

A very cool feature of the Team Foundation Source Code Control is the check-in policy framework it provides. This framework makes it possible to set validation rules (policies) that must be satisfied before the developer is allowed to check-in his code. By using this feature you can make sure unit tests are available (and run) for the piece of code or that the code meets the FxCop rules. Also this framework provides us with some extension points that we can use to write our own policies.  

Unfortunately the policy can be overridden by the developer but in this case an e-mail is send to our good old project leader. This will give him the possibility to make sure the developer sticks to the policy the next time. The main purpose of the check-in policy framework is to support some sort of a process that ensures a certain level of quality of the code that is checked in by the developers.

Two important principles related to this checking policy feature are: policy definition and policy evaluation.

Policy definition; (for the control freaks among us) in this process it is decided which rules must be satisfied before the developer is allowed to check-in his code. Policy definition is very likely done by the architect or lead developer on the team.

Policy evaluation; this is the process that actually validates a check-in of the developer against the policies that are defined

Policy definition can be done from within Visual Studio Team System. Policies can be set on a project base by using the Team Explorer. Policies can be added, deleted or edited for a specific project.

The policies that are set for a project will be evaluated while the user is interacting with the Visual Studio IDE. This makes sure that every time a developer checks in a piece of code it validates against the set of rules/policies. Every policy (represented by a plug-in in the policy framework) receives the necessary information to determine if the code meets the policy. The policy plug-in can return information that can be used by the policy framework to display messages the user why the code doesn’t meet the policy. 

If you want more control, it is possible to write your own policies. These policies can be used by the policy framework. Basically all you have to do is implement a few interfaces and there you go. One of the things to remember is that the new policy plug-in has to be installed on all the client machines that must apply to this new policy. Team Foundation Server doesn’t provide a mechanism for distributing policies yet!

To create a new policy plug-in you can simply open a new Visual Studio project to create one or more classes that implement the necessary interfaces. To create a policy the following interfaces must be implemented:

IPolicyDefinition; this interface exposes some methods that are used in the policy defining process. The information provided by the methods of this interface is displayed in the user interface that helps defining a set of policies (within the Team Explorer) for a project.

IPolicyEvaluation; this interface exposes methods that are used to evaluate if the code that is checked in meets the policy. Methods in this interface accept the content of the actual check-in so this can be validated against the rules in the policy.

The policy framework makes sure that all classes that implement the IPolicyEvaluation interface receive the following information when a file (fileset) is checked in:

• The check-in comment
• The currently selected list of files
• The currently selected work items
• The release note information

The policy plug-in can use all of this information to decide if the infoset satisfies the policy.

Al assemblies that contain classes that implement the above interfaces will be picked up by the check-in policy framework. It is possible to have more that one policy plug-in in one assembly. Before the policy framework can pickup new policies it must know were to look for policy assemblies. Fur this purpose we have the good old registry, that helps Team Foundation Source Control service solve this problem. All we have to do is store a value (location) for the policy plug-in under a special registry key. At this moment the name of the key is “HKEY_LOCAL_MACHINE \Software\Microsoft\Hatteras\Checkin Policies”and HKEY_CURRENT_USER \Software\Microsoft\Hatteras\Checkin Policies. This will probably change because “Hatteras” is the codename Microsoft is using for the source control system!

If you are interested in the extensibility possibilities of the Team Foundation Source Control system (or any other Team Foundation Server services) go download the Visual Studio Team System Extensibility Kit and have a look!