Steve Resnick, Richard Crane, Chris Bowen
Essential Windows Communication Foundation. For .NET Framework 3.5.

This is a well-organized and easy-to-read introductory book on WCF. It provides a thorough overview of the principles behind building and consuming WCF web services and includes real-world examples illustrating how to leverage WCF framework in your applications. The topics covered in this book include:

• Contracts: how to define complex structures and interfaces
• Channels: how to configure channels and channel stacks
• Bindings: how to choose communication protocols
• Behaviors: how to manage instances, concurrency, and transactions as well as how to add your own custom behaviors
• Serialization and Encoding: how .NET classes are serialized and represented on the wire
• Hosting services in IIS, WAS, and managed .NET applications
• Security options for authentication and transport- and message-level security for Internet and Intranet applications
• Integration with other frameworks such as WF and Silverlight
• Other topics: JSON, RSS/ATOM, peer networking, metadata publishing, diagnostics, and others

The authors did an excellent job explaining complex WCF concepts in simple terms and will help you jump right into building distributed applications in .NET. I highly recommend this book to .NET application developers and architects.

Happy reading!

While working with WCF services hosted in IIS7 with non-HTTP endpoints (such as TCP or NamedPipes), we realized that our usual way to resolve a phisycal file path corresponding to a virtual path on the web server is not supported.

In ASP.NET, we use HttpContext.Current.Server.MapPath method, but HttpContext.Current is null in WCF services with non-HTTP endpoints. What shall we do? It turns out that there is another way to map a virtual path: using the HostingEnvironment class. See the example below.

public static string MapPath(string path)
{

    if (HttpContext.Current != null)

        return HttpContext.Current.Server.MapPath(path);

    return HostingEnvironment.MapPath(path);

}

Happy coding!

I came across flash cards with class diagrams of GOF design patterns. The flash cards were created by Jason McDonald and are available for free download on his blog.

Problem Statement

Last month, I blogged about organizing code in a source control system. We looked at how release units help us represent a domain context map to support domain-driven design and distributed application development. We recommended adopting a standard release unit layout so that your release process can be clearly understood and automated.

This month, we will take a deep dive into the release unit's trunk folder. I said before that trunk contains the latest version of the release unit code. How shall we organize our code inside trunk?

Objectives

As always, let's define our objectives:

• Support domain-driven design philosophy
• Support principles of object-oriented design
• Support distributed application development
• Support a structured, repeatable, and traceable release process

Release Units in .NET

Release Unit is a collection of folders and files that are released together. In .NET environment, this is achieved with a .NET solution that groups multiple projects together for the purposes of debug, compilation, and release. Hence, if you are working in .NET environment:

Each release unit should contain one and only one .NET solution.

.NET Solution Structure

Now, we are ready to take a look at a sample .NET solution structure that will help you implement principles of domain-driven design and object-oriented programming. For simplicity, let's assume our solution consists of a single web application and a command-line data setup utility. You will have no problems extending this approach to handle your own more sophisticated scenarios.

/doc - contains release unit's documentation.

/lib - contains release unit's pull dependencies. When your project uses a .NET assembly not part of your solution, place the assembly into the lib folder and reference it from there. It ensures that all projects in the same solution always use the same version of the dependent upon library and provides you with a clear way to upgrade the library to a new version should you decide to do so.

/Database - contains database creation and modification scripts, scripts to set up users and their permissions, load data files, etc. This folder may also include command-line batch files to set up the release unit on a local machine, build, integration or test server.

/Model - contains classes of the Domain Model, a central part of the release unit. This assembly describes what can be accomplished by the release unit in business terms. Keep the model free from infrastructural detail. It will help you achieve high levels of reuse and low costs of maintenance in your applications. Next month, we will take a look at how to organize your domain model to clearly identify all supported business scenarios and transactions. This is a big topic on its own, which certainly deserves a dedicated blog article.

/ModelUT - contains unit tests for the Domain Model classes.

/Persistence - implements a persistence mechanism for the release unit's domain model. I strongly recommend keeping persistence interfaces with the model itself since it shows how aggregates and entities are designed to be loaded into memory. The purpose of the persistence library is to implement persistence interfaces with your standard tools and techniques.

/PersistenceUT - contains configuration files and unit tests for the Persistence. In our case, these tests verify the release unit's persistence classes and their configuration files as well as the database. Strictly speaking, they are integration tests. However for the purposes of the domain modeling, we prefer to think about the whole domian model persistence as a black box.

/WebInfrastructure - contains web infrastructural classes which would otherwise be placed in the App_Code directory on the web site. Extracting these classes into a dedicated library allows them to be unit tested.

/WebInfrastructureUT - contains unit tests for the web infrastructural components.

/Web - contains a web application, a top application layer responsible not only for user interface but also for referencing and configuring all its depencies.

/WebUAT - contains user acceptance test scripts, such as Selenium or WatiN.

/WebLT - contains load testing projects, such as JMeter or LoadRunner.

/DataSetup - contains a command-line process to perform backroom administrative tasks.

/DataSetupUT - contains unit tests for the data setup components.

Dependencies

To better understand this sample solution structure, take a look at the package diagram below:

Summary

1. For each release unit, create a .NET solution file.
2. Place all of your external pull dependencies into the lib folder.
3. Keep your model classes free from any infrastructural detail.
4. Make your top layer responsible for connecting and configuring all its dependencies.

Happy coding!

Based on the comments received, I have updated my last month's article in the Architect column. In the end of the article, you will now find a 5-step summary on how to structure your source control repository in order to support:

• Domain-driven design philosophy
• Distributed application development
• Structured, repeatable, and traceable release process

Thank you for reading Modelus Blog!

Problem Statement

One of the first questions facing development teams is deciding how to organize their code in a source control system. In this article, I will describe an approach that we have applied successfully at multiple organizations over the last decade. I hope it will help you and your team make your development environment and processes leaner and more efficient.

Objectives

First, let's understand what capabilities we are looking for from our source control system:

• Support of the domain-driven design philosophy
• Support of a distributed application development
• Support of a structured, repeatable, and traceable release process

Release Unit

Our source control system is organized around release units. Release Unit can be thought of as a collection of folders and files that are released (and thus, reused) together. It is a job of application architecture to break down a large monolithic application into multiple release units so that they can be tackled independently by different development teams.

Pull and Push Release Unit Dependencies

We recognize two types of dependencies between release units: Push and Pull. Let's assume that Release Unit A depends on Release Unit B. Push dependency means that every time B is changed, it is automatically integrated with A. Pull dependency means that B is integrated into A when A's development team decides to pull a new version of B into A.

An example of Pull Dependency: an application that depends on a shared domain. Even though a new version of the shared domain may be released each month, it does not force the application to be integrated, tested, and redeployed on a monthly basis. Instead, the application integrates with the shared domain only when the application development team decides to pull a new version of the shared domain into the application.

An example of Push Dependency: a web application that depends on the portal's header and footer. Every time, the new header and footer are implemented, each web application is automatically integrated with the new header and footer code.

Implementing Release Unit

We recommend to store a release unit in its own source control folder with the following layout:

/trunk - contains the latest version of the release unit code (may be in progress)
/tags - contains read-only copies of the code (e.g., previous releases of the code into production or test environments)
/branches - contains branch copies of the code

Implementing Pull Dependency

Create /lib folder in your release unit's trunk and place all release unit's pull dependencies there. Configure your release unit to automatically integrate with the dependencies placed in the lib folder. Next month, I will demonstrate how to set up a sample .NET solution structure with pull dependencies.

Implementing Push Dependency

Configure your release unit to link and automatically check out or export all its push dependencies. In Subversion, this can be achieved by using the svn-externals property.

Organizing Release Units

Even a medium-sized organization is likely to have hundreds or even thousands release units in their source control repository. In order to keep the repository manageable and easy to navigate, group release units belonging to the same bounded domain contexts together. For example, you may have a set of release units stored in the Accounting folder, another set stored in the HR folder, and another set stored in the Finance folder. You will need to refer to your domain context map in order to learn what bounded contexts exist in your organization.

5-Step Summary

1. Structure source control to represent your domain context map
2. Develop your applications using multiple release units
3. For each release unit, assign ownership to a dedicated development team
4. Integrate release units via Push and Pull dependencies
5. Establish standard integration and release processes for all release units

Contact me if you have any questions or comments. Happy coding!

We noticed today that one of our ASP.NET cloud applications incorrectly identified the end user's IP address. Our Request.ServerVariables["REMOTE_HOST"] and Request.ServerVariables["REMOTE_ADDR"] were initialized with the load balancer information instead of the end user's data.

We found the end user's IP in a different place: Request.Headers["X-Cluster-client-IP"].

Happy coding!

I have been moving a number of web applications from 64-bit Windows Server 2003 and IIS 6 running in 32-bit mode to 64-bit Windows Server 2008 and IIS 7. During testing we discovered the following COM exception when trying to pre-populate an FDF form using FDF toolkit 6:

0x80040154: Retrieving the COM class factory failed.

It turned out that FDF Toolkit 6 has been compiled only for a 32-bit OS. Thus, in order to make it work with IIS 7, you will need to register FDF Toolkit using the 32-bit version of regsvr32.exe. You will also need to enable 32-bit applications in your application pool.

Happy coding!

According to our web statistics, IE8 user base is growing fast at the expense of IE6 and IE7 users. This prompted us to test our web applications using IE8 and, as a result, we discovered a number of CSS and JavaScript compatibility issues.

Most of the JavaScript problems were related to the Dojo 1.1 JavaScript toolkit and all of them have been resolved by upgrading to Dojo 1.3.

If you are wondering which browsers your applications should support, we recommend establishing a rule based on a percentage of your user base. For example, we support 95% of our users, which results in IE 6/7/8, Firefox 3, Chrome 2, and Safari 3 browsers.

Happy coding!

Problem Statement

Each issue of "The Architect" will address a common problem in object-oriented programming. This month, we will take a look at how to get a reference to an instance of the class that you would like to use in your code.

Potluck Principle of Getting Objects You Want

If you want to get a reference to an instance of the class, you should first understand what type of object you are trying to create. Is it an Entity, Value Object, DTO, or something else? Once you answered this question, select one of the options below. Choose the option that better fits your situation:

1. You may be able to create the object yourself
2. You may be able to ask another object to give the object to you
3. You may be able to reconstitute the object from a previously stored state

When I discussed these options with Svetlana, she said that they reminded her of organizing a potluck. Potluck suggests an assortment of dishes, just like an object-oriented code is an assortment of objects. When you want a particular dish to be prepared for a potluck, you can do it yourself, assign it to one of the guests, or pick it up from a local grocery or a restaurant.

Option 1: Create the object yourself

You can create the object yourself by calling its constructor or using one of the Creational Design Patterns. Here are some examples when it may be applicable:

1. New Entity. Entity, aka Reference Object, is an object defined by its identity as opposed to its attributes. Examples: a new Account, a new Person, a new Application.
2. Value Object. Value Object is an element of the domain model with no concept of identity. Examples: Money, DayPoint, Address.
3. Policy, Specification, or another member of the Decision Making layer. Examples: IsCosignableApplicationSpecification, IsEligibleFor401KEmployeeSpecification.
4. Data Transfer Object

Option 2: Ask another object to give the object to you

Here are the examples:

1. Local Entity inside of an Aggregate. Aggregate is a cluster of associated objects treated as a unit for the purposes of data changes. The root is the only member of the aggregate that outside objects are allowed to hold references to. To find an object inside the aggregate, you need to traverse its associations. Examples: Order Items of a Purchase Order, Wheels of a Car.
2. Value Object used to describe an Entity or another Value Object. Examples: Age of a Person, Amount in a Bank Account.

Option 3: Reconstitute the object from a previously stored state

1. Existing Aggregate or Global Entity. For each aggregate (or global entity) in your domain model, create a repository responsible for performing a database query and recreating the aggregate (or global entity) based on the query results. Examples: a Car, an Application.

Note that the Potluck Principle does not attempt to answer where and when object references may be obtained and how long they can be kept in memory. These are good themes for our future blog articles.

Let me know what you think. Happy coding!