Introduction to the Web Service Software Factory

  • Article

As you hopefully know by now, the first community release of our Web Service Software Factory is now available at https://practices.gotdotnet.com/projects/svcfactory. Don and Tom provided a good overview as to what a Software Factory is on the GotDotNet workspace.

The Service Factory is a cohesive collection of various forms of guidance that have been built with the primary goal of helping you build high quality connected solutions in a more consistent way with less effort. In addition to the forms of guidance you may have already seen from the patterns & practices team, there is a new form of guidance in here, called a guidance package, that allows guidance to be automated from inside Visual Studio 2005 through the use of a wizard-based dialog than can be modified (by an architect perhaps) to fit the needs of a specific solution.

 

As you prepare to evaluate and provide feedback on our workspace I thought it would be worth mentioning some of the characteristics of this Service Factory that I think you might be interested in. Some of these are visible in our first community release, and others will become increasingly visible over the next couple of weeks and months.

 

Service Factory characteristics:

  1. Open - Our goal with this factory is not to hide complexity through the use of tooling – instead we like to think that we will hold your hand through the development experience. Often times we find that developers learn key api's through the use of our automated guidance and then prefer to write the code by hand. In the first community release you will see this capability demonstrated a couple of ways:
    1. The documentation describes development tasks such as creating a WCF service and then goes on to walk you through how to do that manually using just code, and it also shows you how our Guidance Package can automate that task for you using either recipes (GAT speak for wizards) or other acceleration mechanisms such as code snippets.
    2. As each step within an activity is completed using the Guidance Package a help screen appears within Visual Studio that tells you exactly what tasks were performed (so you can take a look at the generated code if you are interested) and also tells you what the next steps within an activity are.
    3. Furthermore, the guidance is for the most part specified declaratively in XML allowing you to look under the covers of the guidance package to learn what we are doing and even change the tooling. More on this shortly.

 

  1. Configurable - As you are well aware different applications, different organizations and different vertical industries have different requirements making it hard for us to create “one size fits all” style of guidance for building service oriented applications. For this reason we have tried to incorporate flex-points inside our guidance packages allowing an architect or lead-developer to specify how the Guidance Packages should be used for a particular project or organization. Some examples of how configuration are being applied include:
    1. The best example of configuration in our first release is related to the guidance package structure - by default our guidance packages includes a 1:1 mapping between the logical layers of an application and its implementation. For simple services, or where data contract reuse is unlikely you might want to modify our solution structure and combine different layers into a single layer.
    2. In an upcoming release of the Service Factory we have further examples around security - allowing an architect or lead developer to specify security requirements at a solution wide level and then have all services that are secured conform to those settings.

 

  1. Extensibile - Guidance packages developed using The Guidance Automation Toolkit are written using a combination of T4 code templates and CodeDom. In many cases basic changes to recipes can be made simply by modifying XML files. So where our integrated configuration capabilities still do not meet your exact requirements you have the ability to modify the underlying Guidance Package. Where your requirements are significantly different - or you have additional tasks that you would like to integrated inside the Guidance Package you can of course modify the guidance package that we provide and generate a Guidance Package that can be installed for use by your development team.

 

  1. Verifiable - It is one thing to automate the creation of your services and associated configuration (including security information) - but that doesn’t prevent best practices from being accidentally modified during development. For this reason we are currently experimenting with some work Microsoft Research created supporting the verification of security goals related to protocols such as secured web services whilst also considering how to extend it to allow verification of constraints specified by an architect during customization of the .

 

These characteristics are of course in addition to those inherant to all P&P guidance - which of course aims to increase the quality of your deliverables, increase developer productivity and consistency… So, if your software factory is looking pre-industrial grab our Service Factory and enter a new era of efficiency allowing you to capitalize on your investments in architecture…

 

Happy Easter everyone!