.NET
provides several resources designed to provide generic processing logic
and guidance based on best practices. Application Blocks and Software
Factories collectively represent these resources.
Application Blocks
When
developing different services, there are utility or infrastructure
functions that are commonly required by multiple solutions, regardless
of the nature of their business logic.
Some examples of cross-cutting utility logic include:
Application Blocks are
directly comparable to out-of-the-box utility services that result from
the application of Utility Abstraction and Agnostic Context . They are so generic that when Domain Inventory is applied to a given enterprise, they can be utilized within a cross-domain scope, as per Cross-Domain Utility Layer .
|
Normally, we would attempt
to build a series of utility services to encapsulate these types of
logic so as to make them reusable and recomposable in support of
multiple service-oriented solutions.
Over the years, the
Patterns and Practices Group at Microsoft has identified common bodies
of utility logic and packaged them into a series of reusable components
called Application Blocks.
Note
The “Patterns &
Practices Group” at Microsoft was introduced to develop reusable
open-source libraries to solve common infrastructure tasks and thereby
bootstrap the development process. Several members of this group
contributed patterns to the SOA Design Patterns book. For more information see http://msdn.microsoft.com/practices/.
Application Blocks are
reusable components used to address common challenges in enterprise
software development. They encapsulate the best practices and
development guidelines and are available as Visual Studio projects with
source code. Application Blocks are also available as compiled binaries
that can be directly included in development solutions. The benefits
provided by Application Blocks echo many of the strategic goals and
benefits of service-oriented computing in general:
modular development and reusability for increased ROI
standardization of the development platform and the utility service layer
significant increase in developer productivity and overall responsiveness
enable project teams to focus more on business logic rather than low-level mechanics
establish a healthy level of decoupling between the utility logic and business logic
improve effectiveness of service governance
The available Application Blocks are listed in Table 1.
Table 1. A list of available Application Blocks.
Application Block | Description |
---|
Exception Handling | used to implement consistent exception handling policies in logical application tiers |
Security Application | performs authentication, authorization, role membership checking, and profile access |
Data Access | used to create, test, and maintain the data access layer (arguably the most commonly used block) |
Caching Application | provides a flexible and extensible caching mechanism (can be used on the server-side and client-side) |
Smart Client Application | used to build modular smart client applications |
Configuration Application | used to simplify the ability to read and write configuration information from a variety of data sources |
Cryptography Application | simplifies
introducing cryptographic functionality in .NET services (abstracts
DPAPI, symmetric encryption and hashing, and uses a configuration tool
to simplify key management) |
Logging and Instrumentation | allows services to be “instrumented” with logging and tracing calls |
Note
The collection of all the Application Blocks listed in Table 1,
with the exception of the Smart Client block, is referred to as the
Enterprise Library. It is important to note that the Enterprise Library
and the Application Blocks are not a part of the .NET framework. They
follow an open source licensing model and are not directly supported by
Microsoft.
Software Factories
A Software Factory
is a collection of related software artifacts, such as reusable code,
components, documentation, code generators, and visual designers.
Software Factories increase the quality and predictability of services
developed by standardizing solution templates used for developing
services. Software Factories can help establish domain-specific
services with improved consistency and quality by integrating
automation scenarios deeply into Visual Studio using templates and code
generation.
Guidance Toolkits
Software Factories are built using the Guidance Automation Extensions (GAX) and the Guidance Automation Toolkit (GAT).
GAX allows architects
and developers to automate development tasks within the Visual Studio
environment and provides a runtime environment that must be installed
to start working with GAT.
GAT extends the
Visual Studio environment by allowing you to author integrated user
experiences. The toolkit enables the automation of development
activities and integrates reusable code into services. Guidance
toolkits contain several components that work together to provide
automation functionality, as listed in Table 2.
Table 2. Guidance automation toolkit components.
Function | Description |
---|
recipes | automate repetitive activities that a developer would usually perform manually to reduce errors and increase consistency |
actions | units of work defined by a sequence of recipes |
wizards | walks
developers through one or more pages gathering values and is associated
with a recipe that is used to gather values for the recipe |
type converters | validate the value of a field and are used to convert them to the representation used by the recipe |
Visual Studio templates | used
to create Visual Studio solutions and add projects (templates can be
associated with recipes, which in turn are associated with wizards) |
Web Services Software Factory
When working with WCF, it is
common to run into decision points around when to use a data contract,
when to use a message contract, and how to determine the relationship
between these contracts. The Web Services Software Factory provides
guidance on these issues. It is a part of Microsoft’s Software Factory
initiative and provides guidance packages that help build solutions
based on Web services. The ideas around using data contracts, message
contracts, and service contracts are not difficult, but using these
technologies in a consistent and uniform way is critically important.
Specifically, this Software Factory contains guidance packages for:
ASMX
WCF
DataAccess Layer
WS-Security using ASMX
The scope of the individual
guidance packages ranges from the service proxy to the database access
layer. The Service Factory includes guidance for designing messages and
service entities, mapping message entities to business entities,
persisting the business entity into the database, security, and
exception management.
The Web Service
Software Factory supports wizard-driven development of data contracts,
message contracts, and service contracts. Data contracts are reusable
artifacts in a project, whereas message contracts are not reusable and
are specific to the operation they are being received and sent from.
This Service Factory further supports the use of SOAP faults by
simplifying the creation of fault contracts and attaching the fault
contracts to services.
As shown in Figure 1, the Web Service Software Factory organizes solutions into the service layer, business layer, and resource access layer.