Introduction

The Web Service Software Factory: Modeling Edition (also known as the Service Factory) is an integrated collection of resources designed to help you quickly and consistently build Web services that adhere to well-known architecture and design patterns. These resources consist of patterns and architecture topics in the form of written guidance and models with code generation in the form of tools integrated with Visual Studio 2008. To help you appreciate the goals, motivations, and intended audience of this release, this topic provides a little historical context.

Historical Context

The second major release of the Service Factory was released in December 2006 and used the Guidance Automation Extensions (GAX) to provide automation (wizards) within Visual Studio to help developers and architects build Web services using WCF and ASP.NET. The Service Factory team received a lot of valuable feedback on this release that can largely be summarized as follows:

• The tooling should remember the information provided so it does not have to be provided each time the source code is generated.
• The next version should focus less on the data access and business logic tiers and more on the service interface.
• Help those who want to modify the Service Factory source code; doing this is not a straightforward process.
• Wizards are okay some of the time, but a visualization of the services is a better experience.
• Services should be designed in a technology-independent manner.

The patterns & practices team built the Service Factory: Modeling Edition as a direct response of this feedback. Hopefully, this will help you understand who the intended audiences are and why the Service Factory contains what it does.

The previous release of the Service Factory: Modeling Edition was built on Visual Studio 2005. This release is targeted for Visual Studio 2008.

Intended Audiences

Based on the feedback about previous versions of the Service Factory, the Modeling Edition targets the following two different kinds of members of your development team:

• Web Service Developers. These developers or architects are responsible for building Web services. They are most likely to have a binary installation of the Service Factory on their computers. This binary version may be the one provided by the patterns & practices team or provided by someone on their framework and tools team.
• Framework and Tools Developers. These developers or architects have traditionally been responsible for building reusable libraries that other development teams in their organization will use. It is our experience that this development team in many organizations is now responsible for building tools other developers will use.

It is possible for a single developer to be in both of these audiences, but it is not likely, so there is no expectation that both of these areas of focus will be addressed by the same person. As a result of having two types of audiences, many components of the Service Factory: Modeling Edition may cater to only one of these audiences.

Service Factory Contents

For the Web service developer, the Service Factory contains automation and guidance integrated into Visual Studio for building services. At the core of the automation components is a Web services domain model. This domain model contains elements such as service contracts, operations, messages, and data contracts. This domain model manifests itself in the form of three integrated domain-specific languages (DSL) that are used to model services: Service Contract Model, Data Contract Model, and the Host Model. Figure 1 illustrates an example of the Service Contract Model. For more information about working with this and the other models, see Designing with the Models.

Figure 1
The Service Contract Model

In addition to the Visual Studio automation facilities, the Service Factory also contains the relevant written guidance about building Web services from the December 2006 release. Some of these topics include architecture, message design, versioning, exception handling, and other useful patterns. For a full list of topics that are included, see Web Service Architecture. Web service developers interested in learning more about the Service Factory: Modeling Edition are encouraged to complete the Building a Web Service hands-on lab provided on the Service Factory Community Site on CodePlex.

For the framework or tools developer, the Service Factory team has intentionally architected the Service Factory to be extensible. Because of this, the Service Factory uses many capabilities provided by GAX/GAT, the DSL Toolkit, and other resources when performing tasks such as model validation and code generation. In areas where certain capabilities were not available, they were built by the Service Factory team and are being provided to you as source code. Figure 2 illustrates many parts of the Service Factory and their relationships to each other. To understand the parts of the Service Factory, see Service Factory Architecture.

Figure 2
Dependency relationships of Service Factory components

In addition to the topics about the Service Factory itself, the Service Factory team has built a set of hands-on exercises that illustrate the most common types of changes they expect teams to apply to the Service Factory. These exercises also provide a comprehensive opportunity to learn about almost all parts of the Service Factory. In other words, even if there is not an exercise that illustrates the exact change you want to apply, by performing all the exercises, you should be able to figure out how to make the change based on what you learn from completing all of the exercises. The hands-on lab is named Creating Your Version of the Service Factory and is also on the Service Factory Community Site on CodePlex.

Guiding Goals and Principles

The Service Factory team applied the following goals and principles while building the Service Factory:

• The Service Factory will provide higher productivity because it raises the abstraction level for building services.
• Applications built using the Service Factory will have a higher quality because the generated code encapsulates best practices.
• The Service Factory will be designed to be extensible so it can adapt to the needs of a particular team's development processes and organizational environment.
• When using the Service Factory, implementation technology related decisions should be delayed until as late as possible. These decisions include the messaging platform (WCF and ASMX) to use and which Visual Studio projects to use in making up the solution for the service.
• Changes to the service and its design should require as little rework as possible.

Getting Started

The Service Factory team has put a considerable amount of effort in helping you familiarize yourself with the Service Factory. The Web Service Software Factory: Modeling Edition includes written documentation and hands-on lab exercises. In addition, short videos are provided on the Service Factory Community Site. For more information, see Getting Started.

Roadmap

A software factory is the most advanced and integrated form of guidance from patterns & practices. However, it is certainly not the final form, so the guidance captured in the Service Factory will evolve over time. Specifically, it will evolve to address:

• Additional aspects and challenges of service development, and
• Changes and improvements in the services platform.

This version of the Service Factory is built for Visual Studio 2008. For more detail about the roadmap, monitor the Roadmap page on the Service Factory Community Site.

More Information

For more information about the Service Factory, see the following resources:

• Service Factory Q & A. This is similar to a FAQ. It is a dynamic document on the Service Factory Community Site and contains a lot more information about the Service Factory: Modeling Edition that is not included in the documentation. Over time, this document will serve as a FAQ.
• Service Factory Known Issues. This is another dynamic document on the Service Factory Community Site that categorizes all issues the Service Factory team and the community has identified. Some of these issues will be fixed over time by the Service Factory team; we suspect community members will fix other issues.