Jezz Santos : Web Services Software Factory

TechEd Europe 2007

jezzsa — Wed, 26 Sep 2007 03:50:25 GMT

For those big into Software Factories in Europe - it is TechEd Developers in Barcelona again! (November 7th)

There are a few sessions on factories, including ours "ARC 301 - Build Your Own Software Factory"

Software factories are emerging automation and guidance tools that address many of the chronic problems in building software for our customers, partners, and industry today. This session explores the what, the why, and the how of building software factories, and shares the "real life" experiences of designing, implementing, and customizing factories available today. Receive guidance on the processes, patterns, and tools needed to build your own software factories that can succeed and survive on today's and tomorrow's evolving platforms.

This will be the same session Edward and I presented at TechEd US in Orlando in June, and TechEd Japan in Yokohama in August, however this one has a little twist to it - my good friend and colleague Don Smith is going to be your host!!

Don has kindly offered to deliver this talk in my absence, basically because I cant make it and he kindly stepped up. We have delivered this talk together so he knows the content (and to be fair he is a better speaker than I am - don't tell him I said that though). You'll love him.

Don is also delivering "TLA304- Building Services with the Service Factory: Modeling Edition" (also on the 7th Nov) which for some of you will be a massive revelation and insight into the potential of software factories of the future.

Being an extremely useful tool for architects and developers, the next release of the Service Factory adds one of the most often requested features: a graphical tool for designing message contracts and service interfaces based on the Visual Studio SDK, DSL Toolkit and Guidance Automation Toolkit. There are clear advantages of using a modeling environment when building services. The development team has more flexibility when the modeling environment includes logical models that don’t force platform and language decisions too early in the project. When this environment has a great deal of extensibility, the capabilities are only limited by imagination. The Web Service Software Factory: Modeling Edition provides this type of modeling environment. Attend this demo-heavy session to see how the Service Factory can be used and extended by your service development team.

If you haven't seen the Service Factory (Modeling Edition) recently, you really need to, this will blow you away!!

EFx Factory Futures

jezzsa — Thu, 18 Jan 2007 00:50:00 GMT

Well, its time to (officially) announce the end of further development of the EFx Factory prototype! and open a new chapter on software factories for our customers.

[In actual fact, not really hot-off-the-press news, this post has been pending getting published for some months now.]

The pioneering work on EFx has not been in vain. The good news is that many of the innovations, learnings, patterns and assets, from this factory are to be absorbed into future factories from Microsoft, thanks to the patterns & practices team. You can expect to see some of the more powerful features exemplified in EFx (such as: Product Modelling, Runtime Integration, Technology Separation and Extensibility for Composability) in the next versions of the Service Factory. The gap you see now between these two factories (discussed in detail in How does EFx differ from Service Factory?) will start to close now, as we consolidate our experiences, and ramp up with a new software factory platform - go the Service Factory!

The stuff in EFx was too good to ignore, (our customers really wanted to get their hands on it), and its only been a matter of finding the right channels to get this out publicly (to have the largest impact on our customer problems), which has really been the major challenge to date. Now that we have found that channel, you should expect to see even more innovations and compelling features in the new generation of software factories to come.

As for myself, I'll continue to work passionately on software factories, in the hope of 'making sense of it for you' (the tag line of this blog).

There are still many challenges in making enterprise development a cheaper, easier and more predictable experience with reliable results using factories, and hopefully I'll share with the community some of the past experiences, patterns and techniques in this area that we have identified as key with building your factories.

Looking Forward

Currently, this industry is on the brink of the adoption of software factories, and we currently find ourselves in a limbo, waiting for a platform to assist with the vision and boost adoption.

Many customers have identified and committed to a strategy to move forward with software factories, but without support from the platform, and experience and knowledge transfer in this domain, this task at hand seems ominously difficult, or hopelessly un-informed.

Those of us that took the plunge earlier on, without any formal platform, can testify that building factories is not an effortless undertaking. The rewards of those efforts are starting to come to fruition for the betterment of others. The earlier attempts, in various forms, should begin now to coalesce into a shared experience, and impact the future direction of this space.

Building factories today is hard. It's both hard to know what to build, and hard to know how to build it. Also, the current platform for building them is difficult to manipulate and esoteric. All this gets worse when you know we are in the shadow of a new platform that will soon to leap frog us forward again. But there are incremental advances being made all the time by many different people. It's going to take sometime before we have a fully realised vision, but this is no different than any other critical innovation in our industry, we will do it in small (verifiable) increments. Hopefully, we will be providing a bunch of tools to make this more achievable in the near future.

Most people have not witnessed the power of a real software factory yet. For most, it's hard to understand what they are and what benefit they offer the current software development market today. For those of us that have witnessed them, the potential is sobering and the benefits crystal clear. It's easy to see therefore what the future of factories can bring this industry, and how that will shape the future of software development. I hope most of you will start to witness that in the coming months.

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

jezzsa — Wed, 17 Jan 2007 12:50:00 GMT

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 3^rd 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 3^rd 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 3^rd 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 3^rd 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 3^rd 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 3^rd party factories based upon the logical architecture of a service layer. When these 3^rd 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 3^rd 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.

The Factory 'Meta-Model'

jezzsa — Mon, 31 Jul 2006 22:31:00 GMT

Hopefully in previous posts I have been able to help de-mystify what exactly the factory schema is and how you should be thinking about it. If you are still confused about how to build a factory and how to create the factory schema, you are not alone.

My good friend Ed Bakker and I have been working together towards improving the user experience of factories, primarily for the factory user, and also for the factory author. He has just posted on some of his own thoughts in this area (Software Factories - The Next Generation).

I wanted to expand on some of those thoughts here from a different angle, in a couple of articles and focus a little more on the schema and meta-model of a factory and how they are related, the EFx factory has a bit of a head start on most of the emerging factories at the moment.

A Solution-based Approach

The first software factories on the market right now like the 'Service Factory' (from patterns & practices team) do not define or provide or use a factory schema, nor offer help on what one should look like, or how it works. They do not provide a 'model' per-se of the problem domain of building a service as a 'product' of the factory, and therefore they don't require the need for a factory schema.

Instead, the approach it uses is to define sets of losely related GAT recipes to create the physical components of a service by directly generating the source artefacts right into the solution.
These recipes are expected to be executed, by the factory user, in the right order, on the right physical solution elements, then somehow the user is expected to know what was created and further more go back into the physical artefacts, manually, and edit them (using code snippets and other recipes). It's a job for a skilled expoerienced developer who has detailed knowledge about the how the factory works, and deep knowledge of the solution domain as well.
It is the output of the recipes (source code) that maintains the *state* of the service being defined, and therefore it is difficult to re-configure the state of the service with automated tools. So to be clear, there is a 'solution model' maintained in the source code. But there is no provision for reverse engineering the 'solution model' source back to a logical 'problem model', that can be modified and re-generated easily by the factory user.

This class of factory is able, to describe the work products (physical artefacts) of the factory, and the assets that create them (tools, recipes etc), but they offer little formal schema of the factory or visualisation of that schema, and rely upon written guidance as a means to relate one work product to another.
In other words, there is no 'problem model' of the product of the factory. There is a 'solution model' persisted in the physical solution structure and its artefacts, and the factory user is expected to be very familiar and concerned with the physical model. This design thererfore only offers very little abstraction of the problem space.

A Different Approach

An approach which is more in-line with factories of the future, and one the EFx factory took to the same problem domain, is to use a model driven approach to model the service and its variability points from end-to-end. This therefore, offers an abstraction of the problem domain to the factory user. The advantages of this approach are numerous:

The Problem Model

The EFx factory employs a runtime model (a Meta-Model) of the 'product' and its' work products that the factory produces, as well as the architectural relationships between them.

The factory is then able to display a logical 'view' of the things (work products) it produces (a product model) in a hierarchy that describes how they are composed and related, offering implicit guidance on how to construct and compose them.

Separating the Implementation from the Configuration

In addition, the EFx factory offers an extensible plug-in mechanism for 'Artefact Generators' which are used to generate the source artefacts that are represented by the model (once the model has been configured).

The model describes the architectural make up of the service and the relationship of the components within, not the technology implementation of it.

Technology implementation is cleanly separated by this design, and only applied (postponed) till when the factory user is ready to select a technology based upon changing requirements of the solution.

It is these 'Artefact Generators' (seperate specialised pluggable packages) that determine how best to write the source artefacts based upon the current configuration of the model, and in all but the rarest cases, these artefascts will require no further editing by the factory user. In fact, in this design the factory user, performs little if any coding. The coding know-how of the solution domain is encoded into the 'Artefact Generator' itself.

Seperating the Logical from the Physical

Further advantages of this approach are:

The factory user no longer needs to be concerned about working with, or configuring, the physical artefacts the factory (artefacts generators) produce, nor modifying them.

The factory maintains a logical model of the product and its work products, and this logical model maintains a runtime mapping to the physical structure of the solution. The factory is able to determine where the generated artefacts are placed in the physical structure.

The factory can do this because it attributes meta-data properties from the model to the physical solution structure containers (Solution Folders, Projects, Files), designating them as a specific work products in the product model.

Therefore, since the this product model provides a seperation and mapping to the physical artefacts that are produced, so the solution structure can be independently manipulated (re-structured) to define a suitable physical deployment model of the product, rather than attempting to describing the logical structure of it. The advantage of this is clear.

The mixture of these two concerns (logical structure vs. deployment structure) often leads to poorly named and structured solutions, and much debate on what physical structure to use per solution/project/developer. Now, you can address correctly the concern of the deployment structure of the solution - independently from the logical structure of the problem.

You can see the relationship of the Logical View and the Physical View of the product of the factory in the picture below.

Figure 1. Illustrates the 'EFx Solution Explorer' logical view of the solution, and its relationship to the physical structure of the solution in 'Solution Explorer', and meta-data attributed to the work products of the factory.

Architectural Correctness and Guidance in Context

The fact that the service has been modelled from end-to-end and the variability of the problem domain is configurable in a persisted model - offers additional advantages:

The model already describes the relationship between the logical concepts of the architecture, and therefore can validate them at an appropriate time in context with each other, preventing invalid architectures and illegal configuration of the work products.

The user is no longer expected to know how to compose a single work product (with a set of related recipes), since the model describes and maintains the configuration of the work product. The selected specialised 'Artefact Generators' determine the correct and most efficient means to construct it, and create the physical representation of it.

The work products can be re-generated over and over again by re-configuring the model, producing reliably, highly predictable and architecturally correct artefacts every time.

For more details on the other features of this factory and their advantages see the EFx Architectural Guidance Software Factory article.

The Web Service Software Factory (Service BAT)

jezzsa — Sun, 09 Apr 2006 20:41:00 GMT

Very recently p&p announced the 'Web Service Software Factory' (formerly the 'Service BAT') to the public community (official announcement here). The name is still not nailed down yet, but its drawing in close.

A number of us in the community have been busy helping the p&p team refine the requirements and design of this guidance package and basically representing you guys - the community, in shaping this offering. The outcome of this project is set to be an exciting offering from p&p and a god send for developers building services today.

At present the offering is in its infancy, but rapidly progressing. We are all hoping that when finally released this package will provide a huge step towards proving a factory for our development community that exubes automation, guidance, patterns and tools to speed the construction of services.

It's quite an interesting position to be in with both authoring the EFx Factory and advising on the p&p 'Service Factory' project, since they both share the same overall vision. However, they do differ somewhat in their scope, approaches and end goals. The EFx Factory has been a gradual evolution from its beginnings as an application framework on .Net 1.0, into a automation toolkit and now a software factory on .Net 2.0. EFx provides more of a model driven approach to constructing Service Oriented applications and services. It is geared towards providing more architectural guidance, abstractions of the solution and separation between design and technology implementation and is based upon creating components on top of an application framework, (itself based upon Enterprise Library).

It is yet to be seen what future direction the 'Service Factory' will take, which will be further influenced by the wider development community now. However, the EFx Factory has been useful in providing an alternative viewpoint to the problem space overall, and although not directly used in the development of the 'Service Factory' offering, EFx remains as an influencer in its further development.

There are a number of key influencer's in this project (Jason names a few here), that provide various key parts that the toolkit covers, and these guys are all providing valuable input into the project - so check out what they have to say.

Edward currently owns the web space on the details of the 'Service Factory' at the moment, and is going to provide many more details in the future. So no point me repeating them for you - hook into his blog.