FAQ - How does EFx Factory differ from the Web Service Factory?

  • Article

Naturally, I get asked this all the time.

What are the differences between the 'EFx Factory' and software factories such as the 'Web Service Software Factory' from patterns & practices?

[Now, I do need to say this, I do work closely with the patterns & practices teams who built Service Factory, in fact, I am still a member of the expert advisory board on that project. So, I do need to be careful how I word this :) or Don and Tom will kill me.]

My aim here is to give a fair comparison between the two factories from the point of view of the customers using them and market assessing them. What is available today, and what customers can expect to see from factories in this space in the future (especially from Microsoft). Therefore, this is not about how they were implemented technically, but more about how they are designed, and how they are used to do what they do from the customer end-user perspective.

I thought this was going to be a brief post, but I was wrong again. (I'll get there eventually).

[I'm using colour to distinguish the answers for each factory, and aid readability (hopefully). Not here of course, but below.]

Backgrounder

The Basics

The Web Service Software Factory (Service Factory) is a released public available deliverable from the patterns & practices group. Currently, it's in version 2.0 and addresses building secure ASMX or WCF web service layers and building data access layers.

The EFx Factory is a limited, unreleased, prototype offering developed within Microsoft Consulting Services. Currently, version 0.9 and not complete or released. It provides the end-to-end architecture for building both Client Applications and Web Services with a choice of any combination of technologies.

Both factories target similar problem and solution domains and are both founded upon well known .NET architectural patterns and other assets and deliverables from the patterns & practices group.

Let’s have a look at both factories from a high level, and then we’ll consider the differences in detail in the answer below. If you are familiar with these factories already, then skip this part and move straight to the answer section below.

Web Service Software Factory (Service Factory)

The objectives at the start of this project (circa start of 2006) were to make building web services easier, quicker and provide the right guidance and patterns to implement them. At the time of inception, the application of Software Factories was not well understood and the DSL toolkit was in its infancy. GAT was a recent enabling technology investment made by p&p which steered them to more automation than modelling approach. The p&p project team (consisting of some web service pattern legends: Jason Hogg, Don Smith et al. and a number of key industry expert advisors and leaders from our partners and customers) had heaps of valuable web service guidance to put into the factory.

The approach taken was focused on implementing web service patterns with ASMX, and now WCF technology, and on providing the factory user with the source code and solution structure to flesh out the service functionality. Using available p&p deliverables such as GAT, a set of Guidance Packages (GP's) do the code generation from a set of recipes and wizards which capture the user’s settings and generated configuration and source code (via the Text Templating Engine). From there, the developer is expected to enhance the generated source code in order to complete the solution. It also includes recipes for automating some common development tasks. As well, the deliverables include a great deal of invaluable documentation, reference implementations, and guidance for designing and creating web services and implementing web service patterns today.

You can find more details about the features of Service Factory here.

EFx Software Factory (EFx)

The EFx Factory evolved from an Architectural Application Framework called 'Enterprise Framework' (circa 2003) which itself is founded upon Enterprise Library and a number of other application blocks. The project was initiated internally within Microsoft in response to demand from customers and partners for a implementation of the .NET architecture and enterprise development patterns prescribed in written form from the patterns & practices group. Over a long period of time, the framework has encapsulated these patterns implemented on the .NET framework and has refined class libraries to aid the construction of client applications and services according to these architectures as the .NET platform has evolved. The net result of using the architectural application framework was that a developer need only write a small amount of source code to complete a service/application. The software factory that evolved from this framework (circa mid 2005), focused upon the modelling, tooling and automation of the variability points of the architectures of the client applications and services. The framework provided or pointed to most of these abstractions that would have otherwise have been coded directly to the framework class libraries. The primary focus of the factory has been architectural guidance, usability, and the separation of the technologies that would be used to implement various layers of the architecture. In effect, the factory allows any technology, pattern or strategy to be used to implement the various architectural layers, which promotes re-use and composability of factory variants.

You can find more details about the features of the EFx Factory here.

Answer

So let’s have a look at the key differences of these two factories, in detail.

[For the purposes of this comparison, we are only going to compare the ‘services’ that are built with the EFx Factory to the ‘service’ that is built with the Service Factory.

The EFx Factory actually assembles not only ‘services’, but also ‘client applications’ and also ‘systems’ which are a combination of multiple client applications and multiple services together as one product.

Furthermore, the EFx Factory is somewhat of a different generation of software factory, being much closer to implementing the pillars of factories (Model-Driven Development, Architectural Frameworks, Product Lines, Guidance in Context) and raising the level of abstraction to logical design rather than physical design, so it's not really a level-playing field to do an exact comparison.]

Factory Mechanics

Service Factory is the following:

  • A set of Guidance Packages, one per technology and architectural layer: ASMX, WCF, SQL. These create initial solution structure, and primarily generate source code artefacts for each layer directly into the solution structure, invoked from projects in the physical solution structure.

EFx Factory is the following:

  • Guidance Packages to create initial solution structure, and create the logical work products of the architecture, invoked from a view of the logical architecture of the product, DSL models and Visual Studio Application and System designers. 
  • DSL designers to visualise and define the 'specification' of the internals of the applications and services.
  • Factory runtime tools & runtime services to provide, view, and manage the Product Model, exposing a public automation API of the factory and its product.
  • A pluggable technology extensibility mechanism (models and programming interfaces) for other 3rd party factories to plug in and extend and enhance the provided technology-independent models - enabling re-use and composability.
  • Integrated extensions to the Distributed Application and Systems designers of Visual Studio, enabling top-down development of the service.

Assets

Both factories deliver guidance assets that automate the development of the factory product (the service).

The guidance assets included in Service Factory provide invaluable guidance for service implementation of WCF and ASMX technology web services, and data mapping to and from a SQL database. These assets include a number of key innovations in web service patterns and secure web services with class libraries to implement common concerns in building services (i.e. Exception Shielding, Versioning etc.).

The factory delivers comprehensive written guidance on web service architecture, and message exchange patterns, to aid in completing the services which it initiates.

It also includes reference implementations to act as examples of what the factory can create using this guidance.

The EFx Factory core assets are based upon service oriented, and enterprise architecture patterns, separating the architecture and design of a web service from the technology implementing it.

The factory includes an Architectural Application Framework, itself an abstraction of Enterprise Library, and this framework underpins the models and artefacts which the factory creates.

The factory also includes a reference implementation, but minimal documentation of its use.

Solution Structure

Both factories provide solution templates that determine the initial physical solution structure (solution folders, projects, and layout etc) of a service.

 

Both use recipes to define the structure and naming of the solution and its artefacts. The physical solution structure is viewed using the familiar ‘Solution Explorer’. Both factory's solution templates can be customized, in both structure, layout and naming.

 

Both factories use metadata on the created artefacts (solution folders, project etc).

In Service Factory, this metadata determines the ‘responsibilities’ of the containing artefact (solution folder, project). The metadata denotes the type of physical artefacts that are contained in the container artefact, and furthermore determines what actions (recipes) can be applied to them.

The assignment of these responsibilities is configurable by the factory user.

In EFx Factory, this metadata exposes the meta-model of a logical work product the factory is assembling (i.e. a service interface or business component, etc). In other words, a containing artefact (solution folder or project) is the physical representation of one of the logical work products of the service (i.e. Service Interface, business components, data contracts etc).

The metadata describes the actual state and properties (configuration) of the work product, and the containing artefact (solution folder, project) contains the physical artefacts of that work product within it.

The work products of the service are configured in a separate view of the factory’s logical product in another window called the Product Explorer . This view shows the logical architecture of the service.

 

The EFx Factory maintains a runtime mapping between the work product in the ‘Product Explorer’, and its artefact realisation in the ‘Solution Explorer’ . This separation (physical from logical) enables the factory user to re-arrange the physical structure to focus upon the deployment of the solution, rather than mixing that with the logical architecture of the service.

Artefact Generation

Both factories use GAT recipes and wizards to automate the creation of artefacts or work products of a service.

The Service Factory uses recipes and wizards to either generate source code, or to configure generated source code (on compiled CLR types), and automate some common development/debugging tasks. Source code artefacts are generated and assigned directly to the solution structure.

The EFx Factory uses recipes to create the work products in the logical architectural model, and recipes to configure the metadata of the work product in the model. In this way, the logical architecture of the service is separated and abstracted from the physical implementation of it.

Some work products of the service are represented in more detail using DSL models, and recipes are used to configure those models directly.

The factory also uses recipes to automate the restructure and renaming of physical artefacts representing the work products. For example, renaming a work product will require renaming certain physical artefacts and namespaces.

The EFx Factory defers and delegates source code generation of the work products to 3rd party pluggable factories at designated times in the development lifecycle of the product. The factory itself is responsible for the generation of the solution structure artefact containers (solution folders, projects), and the assignment of generated source code artefacts (from 3rd parties) to these artefact containers. This process is managed through the factory runtime.

Models, State and Process

In Service Factory, the source code is the 'model' of the service (albeit a 'weak' model) . When creating the work products of the service (data contracts, service interfaces etc.), a recipe is invoked from the physical solution structure (solution folder, project in Solution Explorer) according to the assigned responsibilities of that folder or project. (See previous sections). The wizard alone provides the abstraction of, and the configuration for the 'work product' (although there is no formal concept of a 'work product' in Service Factory per se). Once the wizard is completed by the factory user, it generates the required artefacts straight into the current solution folder or project.

There is no ‘state’ of the service expressed anywhere - except in the source code of the service. The factory (not surprisingly) provides no round-tripping or reverse-engineering of the source code, so there is no way to view this 'state' at a simplified (abstract) high-level.

As there is no state, and the recipes are keyed from the assigned responsibilities on an solution artefact (project or solution folder), it's difficult to determine what activities have been performed, and what needs to be done to complete a service. The user must be aware of (or will have to discover by right-click trial and error) which recipes are assigned to which solution folders or projects. Furthermore, they must be very familiar with the process of how to complete a service and in which order they have to execute these recipes to complete the service.

Furthermore, the user must know at what stage of the overall process they are in, as this is not depicted anywhere. This is problematic when development of the service is shared between team members.

If the user needs to change something about the service that was generated by the recipes before, they either must re-run the recipe, and recall how they configured the recipe previously beforehand. The recipe will overwrite any customization to the generated code (if any) although the user is warned of this. Or alternatively, rather than re-run the recipe and recall all the settings used previously (usually in the case of a small change), the user can modify the generated source code by hand to make their change.

The Service Factory does provide additional Code Snippets to create the most common artefacts. However, these last options are the realm only of technology domain experts, and the benefits of automation that the recipes provided is really lost.

The EFx Factory provides (and persists) a model of the entire product (service) and all its work product instances. The product is managed in the Product Explorer view.

The primary work products have graphical DSL designers in which their architecture is defined. Recipes are used to configure these models. Because of this visual abstraction, the user (and his teammates) can more easily visualise what state the service is in and what steps needs to be taken to complete the service. (This is aided by validation, discussed later).

To create or modify work product instances, recipes are invoked from the models themselves. 

The models provide the appropriate abstraction of the components of the service, its' variability points, and the state of the product and work product instances. The recipe wizards reflect this state when they are run, and instead of generating code directly, these recipes act upon the work products and product model itself.

To enhance the usability, and increase the productivity of using these models, and creating work products, the factory provides a number of specific editors, recipes and wizards to configure these models.

Abstraction & User Level

In the Service Factory, because the 'model' of the service is in the source code, source code is essentially the medium that the factory users must manipulate to create, configure and complete their service. This is a low-level abstraction of the solution domain.

All manipulation of the service is done via the 'Solution Explorer' view, which is the detailed physical view of the solution, (and best suited to display the deployment of the solution, not it's logical architecture). As long as this is the working view, the level of abstraction will always be at the source code level.

As there is no state of the service, and no state of the process to completing the service, the factory user will always have to be a 'developer' class user familiar with the the overall process of constructing a service from the current state of the source code (as a whole).

In most cases, to modify or enhance this 'model' this developer will require expert domain knowledge and experience of the technologies implemented by the factory.

The 'Guidance Explorer' does help provide a list of steps to complete certain processes, (and a log of the recipes executed previously), but it still does not provide a clear, reliable picture of where in the process the developer is and what needs to be done next.

In the EFx Factory, the model of the service is visualised in DSLs and in the Product Explorer . The model offers high-level abstraction of the web service architecture and patterns, and holds the current state of the service. Furthermore, these models do not depend on any technology.

To change the service the user simply uses the visual abstractions (models, explorers) used to view the models.

The factory user can be any technical user that is familiar with the patterns and architecture used by these abstractions.

The user can create the specification of a service without ever having to have any detailed experience of the technologies used to implement it. However, eventually, a technology domain expert will be required to apply and optimize the various technologies at some stage, but this activity can be deferred till later in the lifecycle of the product.

Designer Integration

The Service Factory does not leverage existing models or facilitate high-level top-down development of services.

The EFx Factory integrates and extends the Distributed Application and Systems designers of Visual Studio (Team Architect Edition if installed). The factory provides additional shapes to represent the implementation of a service, and enables implementation of the service straight from these diagrams using the project templates provided by the factory.

From the Distributed System Designer, the EFx Factory allows the user to drill into theses shapes to expose its' internal specification.

Validation & Completeness

In the Service Factory, since a weak 'model' of the web service is effectively defined in source code artefacts themselves, Service Factory can do little (apart from depending on the language compiler) to validate whether the web service source code artefacts have been created at all, in the right order, correctly or completely to form a valid and complete web service. Although, in principal it's possible to create recipes to perform this kind of validation at a course grain level.

The WCF guidance package does add FxCop code analysis rules that help verify the completeness of some WCF related code.

The EFx Factory has a comprehensive model of the service as a whole and the individual work products. The factory performs comprehensive validation of this model before any source artefacts are generated from it. In fact, this validation is a prerequisite to generation of source artefacts. The factory prevents the user from making invalid architectural configurations, and ensures the work products are configured correctly and completely.

This validation guides the factory user in pre-empting the tasks required to complete the service.

Architectural ‘concerns’ (cross-cutting concerns) for each layer in the architecture are defined in the model and enforced through validation, ensuring that these concerns are addressed appropriately, and the service complies to these enterprise-level concerns.

Architectural Coverage

The Service Factory guidance packages provide automated guidance assets (recipes, templates etc) for the generation of the Service Interface and Data Access Layers of a service. It addresses the middle layer Business Logic implementation and wiring up of the Service Interface and Data Access layers through written guidance, and customization of the source code. The Service Factory provides no guidance about architectural concerns of these middle layers, although there is plenty of written guidance available elsewhere on this.

The EFx factory provides a comprehensive architectural model of the entire service end-to-end.

The EFX factory models all the architectural layers, and their individual cross-cutting concerns (like: Authorization, Exception Management, Logging etc) at all layers in the architecture.

The models define the interaction between the components (method mapping & entity mapping) in the layers. The wiring up of the Service Interface to the Business Logic Components is automatic.

Since Business Logic implementation is difficult to model (too many technology patterns and strategies). The factory instead offers a pluggable technology strategy to implement this layer. This strategy then wires up the business logic components to the data access layers. Common strategies are: custom coding, sequence diagrams and workflow activity diagrams, each of which is provided by a 3rd party factory that can use any pattern or technology to model this layer. 

Service Implementation Technologies

The Service Factory comes in two technology flavours for the service interface- WCF or ASMX, and one flavour for the Data Mapping - SQL. In order to create a 'specification' of a service, you must make a technology choice before using the factory. Once that choice is made, you are tied into that technology implementation – it is very difficult to change that technology decision later - and you'll need to start from scratch again. There is no de-coupling of technology implementation from architecture of the service – so you can’t create a design and specification of your service without first choosing a technology.

The EFX Factory separates the architectural specification of the service from the technology used to implement it - using a technology-independent model .

By providing these technology-independent models of the service's internal architecture, and a rich extensibility mechanism for other factories to plug into this factory, the EFx Factory enables the layers of the service to be implemented by any technology.

Furthermore, there are several layers in the architecture that can be extended, primarily: Service Contract Implementation, Business Logic Strategy and Data Mapping Implementation.

In each of these cases, a 3rd party software factory specialising in a particular technology and architectural layer, can plug into the EFx Factory and implement that layer. They do this in a number of ways:

  • Enhancing the technology-independent model views with technology specific implementation metadata, commands and UI cues.
  • Providing separate technology specific views when that technology addresses work products not present in technology-independent view, or when the technology is best presented in a different view from that provided by the factory.
  • Providing technology specific implementation of the layer.

The EFx Factory, through technology separation and this extensibility mechanism, promotes 3rd party domain experts to produce the authoritative abstractions and implementations of specific technologies of these layers for re-use. These implementations, themselves software factories, will then address and promote a standardised model of these layers. This then promotes re-use of these software factories in other similar architectures of other software factories.

Composability & Re-use

In Service Factory, the recipes to create the structure of a service are based upon a specific technology. Because of the lack of a 'model' and separation between the service specification and the technology implementation of that service, the recipes are bound to a specific physical implementation which they create – they assume certain source artefacts (CLR types) in a certain structure. This makes the assets and recipes very hard to re-use in other factories with different physical implementations.

The EFx Factory separates the model of the service from the implementation of it. The implementation is provided by 3rd party factories based upon the logical architecture of a service layer. When these 3rd party factories create physical artefacts for the layer, (specific to their technology), they don’t populate the physical solution structure directly, since they have no coupling to or knowledge of that. Instead, they pass the artefacts to the factory, and the factory, through its physical<->logical mapping determines which physical artefact container (solution folder, project) these artefacts will be assigned to.

Since the 3rd party factories are only bound to a logical architecture, they can be re-used by other factories sharing the same logical architecture. This means that other factories can be composed using these factories.

Availability & Support

Service Factory is a freely available, released, documented, tested and supported deliverable from the patterns & practices team. It will continue to evolve as the .NET platform and emerging software factory platform evolves. This deliverable will continue to receive support from the patterns & practices team, and the development community as a whole.

EFx Factory is not finished and is not released to the general public. It was prototyped internally at Microsoft, but has not received the necessary development, testing, documentation resources and support to move forward as a releasable deliverable.

Summary

The Service Factory represents the first generation of software factories from Microsoft, which has made a significant step towards the creation and automation of web services.

The Service Factory is primarily focused upon the automation of web service implementations and patterns for specific technologies, using a wizard-based code generation process.

Its' very valuable guidance assets provide the best patterns and guidance for implementing web services and managing their lifecycle and operation. 

This factory is available and supported publicly today, and is successfully being used by many of our customers in production to help them build web services more rapidly today.

The EFx Factory represents a prototype of a new generation of software factories within Microsoft, which has pioneered many of the concepts representative of future software factories from Microsoft tomorrow.

The EFx Factory is primarily focused upon logical architectural design, designer integration, automation, usability and architectural re-use and composability.

It provides a managed automated environment that uses and leverages many abstractions, models and extensibility mechanisms to present an end-to-end logical architectural view of a product, enhancing that with a rich design experience for the user.

It has no dependence on technology. Instead, it provides architectural-based technology-independent models that can be extended by custom technology-specific providers, promoting re-use and innovation in the community. 

In turn, the core factory and the technology-specific providers can be re-used and packaged up to compose other factories to solve specific solution domains.

This factory is not publicly available and remains an unfinished prototype.

Moving Forward

Despite the significant advantages, and advancements that the EFx Factory offers in automating the assembly of service oriented client applications and services, Service Factory (and Web Client Factory), because of their availability, support, resource investments and ongoing development will remain the premier software factories available to Microsoft Enterprise partners and customers moving forward in this space.