Using Microsoft's Service Factory

It's obvious that the development of a new system is a lot of work. There are many things to consider when designing the system, and this can be very time consuming. Since many of the architectural hurdles you face have been met by others in the industry, it only makes sense to learn from their experiences. This saves you from making the same mistakes that others have already made. This saves you time. And that in turn saves you money.

Microsoft's Patterns & Practices provides recommendations on how to, "design, develop, deploy, and operate architecturally sound applications for the Microsoft application platform." Leveraging their 'software factories', architects and developers can spend their time on business opportunities and building an application that addresses the needs of their organization.

Microsoft patterns & practices contain deep technical guidance and tested source code based on real-world experience. The technical guidance is created, reviewed, and approved by Microsoft architects, product teams, consultants, product support engineers, and by Microsoft partners and customers. The result is a thoroughly engineered and tested set of recommendations that you can follow with confidence when building your applications.

I recently started a .NET design for a new system, and while researching 'best practices' I came across Microsoft's newest addition to their Patterns & Practices Software Factories - The Web Service Software Factory (a.k.a. Service Factory). Since I was designing an SOA (Service Oriented Application), this software factory fit the bill.

Not to get into the specifics of the system I'm designing, its main component is a web service that exposes various web methods for placing orders. Having a strong SOA understanding, I know the general architectural requirements for a web service driven application. What I wasn't familiar with was the slight nuances needed for designing one using the .NET framework (which I am new to). Discovering the Web Service Software Factory gave me the boost I needed.

Once you download and install the Service Factory and related Guidance Packages, you will have a new project type available to create in Visual Studio. Under 'Project Types' there will be a subcategory :

• Guidance Packages
• Web Service Software Factory (ASMX)
• ASMX Service (this is an installed template)

When you create a new Visual Studio project using the ASMX Service template, a default project structure is created for you, following the Service Factory architecture. Three specific layers are created, separating the components of your solution. Each of the three components should be cohesive, about the same level of abstraction, and loosely coupled. Below are description of each layer as defined by Microsoft.

Service Interface Layer: This layer defines the operations of a service, the messages required to interact with each operation, and the patterns by which these messages interact—these patterns are referred to as message exchange patterns. The service interface layer contains a service contract, which describes the behavior of a service and the messages required as the basis for interaction. The service interface layer may also contain a service adapter, which is used to implement the service contract and to expose this functionality on a certain endpoint.

Business Layer: This layer incorporates components that implement the business logic of the application. Simple services often require only a very simple business action, but services with more complex requirements may implement a Controller pattern or business rules for implementing service behavior. The business layer also includes business entities that are used to represent objects specific to a business domain. These entities can incorporate both state and behavior. This layer can also include business workflows. These define and coordinate long-running, multi-step business processes.

Resource Access Layer: This layer contains the logic necessary to access data. The layer also contains service agents, which isolate the nuances of calling diverse services from an application and can provide additional services, such as basic mapping between the format of the data exposed by the service and the format an application requires.

Under each layer, the Guidance Package creates separate projects representing the architecture of the Service Factory. For example, if your solution was named 'MyService', your solution would have a structure as follows:

Solution 'MyService'
   Source
      Service
         MyService.DataTypes
         MyService.ServiceContracts
         MyService.ServiceImplementation
         C:\MyProjects\MyService.Host\
      Business Component
         MyService.BusinessEntities
         MyService.BusinessLogic
      Data Access Layer
         MyService.DataAccess

By right-clicking on most of the projects, such as 'MyService.DataTypes', or 'MyService.BusinessEntities', you are able to invoke a wizard to create particular components of the application. By making use of these wizards, it makes it easy to stay within the Service Factory pattern architecture. Using the wizards can be a little confusing the first few times you use them, leaving you wondering what information you are supposed to enter. I made it through the first few times by referencing the help system that is included, as well as the examples provided.

The Service Factory is fairly flexible, allowing you to create your web service as you see fit, and to whatever level of complexity you need. For example you can define your messgae types following an implicit (parameter programming model) or explicit (message contract degin programming model) approach, depending on what your organization requires. And since services designed using the .NET platform default to SOAP Document-based message formatting, you're web service maintains its message-based architecture.

So far (in my early development using the Service Factory) I've been able to get away with using the unmodified version of the Software Factory. However it's good to know that I am able to customize it if the need arises. There is detailed instructions on how to :

• Modify Responsibilities for the Data Access Layer


• Modify Responsibilities for the Service Layer


• Create Custom Solution Structures


• Create New Guidance Packages that Include Your Configuration Settings


• Modify the Documentation

Adding this level of customization, many architects and developers may feel less apprehensive about using the Service Factory.

Like I said, I'm only early in the development stage of the web service I've been referring to. I haven't actually created any 'real' code yet, but have been using the Service Factory to aid in the design phase of development. As I try to create the data models and service contracts for the service, the Service Factory has been indispensible in helping me define the core components of my application. I'll be sure to add a follow-up post documenting my experiences once I start creating the meat of the service.