1. History

Initially, (circa 2003, .NET Framework 1.0-1.1, Visual Studio 2002–2003) ‘Enterprise Framework’ (EFx) was built to meet growing customer demand for an implementation of the .NET architecture. The framework was based upon implementation patterns harvested from several enterprise solution implementations, for various customers. This framework implemented the layered .NET architecture and leveraged, and extended Enterprise Library to provide a complete framework for authoring applications and services on the .NET platform.

This application framework evolved along with changes in the .NET platform, emerging Microsoft technologies and changes in industry service orientation patterns. The framework delivered a set of class libraries containing base implementations of the architectural layers prescribing certain technologies (such as ASMX), and ‘infrastructural services’ which developers used to address the cross-cutting concerns for the architectural layers: Exception handling, Authentication, Authorization, Logging etc. The framework extended Enterprise Library, and implemented several real-world security providers necessary for many customers of the time with heterogeneous technology environments. In addition, many best practice patterns, specifically concerning exception handling were built upon Enterprise Library to solve these requirements in an enterprise context. The framework also provided blocks that were not packaged in Enterprise Library, such as a validation block. It provided useful abstractions of Enterprise Library specific to this solution domain, that offered simplified APIs, and the framework unified the API with typing of string parameters.

The primary challenge for developers was learning the patterns of the framework, and hand crafting the applications and services from blank solutions, without availability (at that time) of code templates. This resulted in prolific cut and pasting of code from the Reference Implementation code, itself highly vulnerable to manual error.

Circa 2005, several technologies emerged from Microsoft that enabled the use of templates, automation and modeling of these types of applications and services, including: Visual Studio 2005, Visual Studio Modeling (Distributed Application and System Designers), the Guidance Automation Toolkit (GAT), and the Domain-Specific Language Toolkit (DSL). Using these new technologies, the framework was able to evolve systematically into an implementation of a software factory. In that process, many of the constraints of the framework were lifted to enable further flexibility of the products which the factory could assemble. Primarily - the removal of the prescription of technology in the architectural layers, and the ability to deal effectively with change during the development of the applications and services. The factory introduced, through domain modeling, several new abstractions and utilized automation that were previously not possible.

This factory was one of the first factories to combine DSL diagrams with GAT recipes, as well as extending the Distributed Application and System Designers of Visual Studio with GAT recipes. The factory makes extensive use of recipes: for automating changes to solution structure and property changes to that structure, providing wizards to configure the models the factory provides, generating project templates for work products and automating menial tasks for the factory user.

By 2007, development on the EFx Factory ceased, and many of the concepts it had pioneered were to be absorbed by the future software factory platform from Microsoft, and adopted by software factories from patterns & practices (such as the Web Service Software Factory).

2. Core Features

The following list exemplifies the features of this factory from others of its period.

2.1. Architectural Product Model

The factory was one of the first factories to be designed on a factory 'Product Model' (part of the factory schema), and the factory provides a logical architectural view (and supporting runtime) for creating/modifying the work products of the factory, for the developer. This logical model separates the logical design of the factory product ‘Product Explorer’ from the physical implementation normally viewed and modified in ‘Solution Explorer’ of Visual Studio. In this way the physical structure of the solution artifacts could be separated from the logical architectural structure of the work products of the product. The factory user could now focus upon the architecture of the product, and author it using models and other abstractions, whilst the factory manages the creation, and placement of its source artifacts.

2.2. Distributed Application and System Designer Integration

The factory integrates with, and extends, the Distributed Application and System Designers installed with Visual Studio Team Edition for Software Architects. The Visual Studio provided diagrams such as the Application Designer and System Designers provide a means to define the high-level application (and services) in an enterprise and compose those into black box systems, which themselves can be composed into larger systems. The factory extends these designers to add a number of new shapes representing the implementation of those applications and services. These new shapes can then be implemented to provide the specific projects and solution templates to represent their physical structure in the factory product. These templates added a new set of diagram files to represent the internal component parts of the application and service layers. These diagrams define the specification of the application or service layers, and give the user a navigation path (drill-down) from the high-level applications into the inner implementation details.

2.3. Composability and Technology Extensibility

The factory models (using DSL’s) the internal implementation of the applications and services based upon a logical, technology-independent architecture and SOA patterns. This architecture is composed of several layers which are then extended and implemented by pluggable ‘Artefact Generators’ (or ‘technology providers’). The technology providers provide a technology specific implementation (and view) of each layer.

An example of such a layer would be the ‘Service Contract’ layer of a web service, containing service interfaces, service operations and data contracts. This factory was the first factory to provide an extensibility mechanism with which 3rd parties (such as Global SI's and ISV's and community domain experts) would provide technology tailored implementations of the various layers. These technology providers would take the form of other external factories (or factorettes), that would integrate into the EFx factory to enhance and expose technology specific views of the architectural models, and ultimately, transform those into source artefacts. This technology separation capability allowed a 'variant factory' to be packaged up and deployed to include: the technology-independent core factory (and its models) with several ‘Artefact Generators’ providing the technology implementations. The factory enabled the composability of variant factories that could build solutions to suit a multitude of real-world heterogeneous technology environments.