To continue this series that started with KISS Architecture (part 1), I will now talk more about a modern mobile multi-tier architecture. Because a picture always says more than a thousand words, let's start with a classic one.

This image should be familiar to anyone who read the Application Architecture for .NET from back in 2002. Interestingly, the Microsoft's patterns & practices team are working on a new version of this guide called Application Architecture Guide 2.0 that is already in its second beta (there is also a specific pocket guide for mobile architectures). Building on the discussions in that guide, I have taken the old diagram (because I like the colors) and created an updated version with a small modification. The modification is related to the placing of the business entities, that I think belong in the data tier. The main reason for that is that the ORM technologies (in my case, LINQ to Entities or ADO.NET Entity Framework) take care of defining the business entities. For more details on multi-tier architectures, please read the guide, it's a great resource.

A nice addition to the traditional diagram is to show how other systems ("External Systems") access my system's services that are published as service interfaces with WCF, and that is exactly how other systems ("Services") are accessed by my system.

However, the biggest changes compared to my previous architecture blueprint are probably in the data tier. Even if I was a big fan of LINQ to SQL, the ADO.NET team have announced that the long-term plan is that in ".NET 4.0, LINQ to Entities will be the recommended data access solution for LINQ to relational scenarios". Therefore, I now use LINQ to Entities (ADO.NET Entity Framework) in the data tier.

However, the changes in the data tier doesn't stop there. Another (probably even bigger) change is that the data tier is now made loosely coupled for the first time. Many attempts have been made in this direction (SQLXML to mention one) before, but I think that this time Microsoft got it right with ADO.NET Data Services. In short, it's a way of accessing data through a simple RESTful interface over HTTP using formats like ATOM and JSON.

Even if this means that it becomes very easy to access the data source directly form the presentation tier, it doesn't mean that a sound architecture should use or even suggest such nonsense. It may be interesting and fun for quick demos, but doesn't belong in any serious enterprise solution - mobile or not. Therefore, the thinking that I introduced in A New Mobile N-tier Architecture (part 2) about keeping the data and logic as logically bound together as possible (in what I call domains) still holds. I strongly believe that the data should only be accessed through the logic.

In the next part I will talk about the benefits of having tiers that are loosely coupled.

In the previous parts of this series, I have discussed the changes that affect the architecture design. It's now time to conclude what this all leads up to architecture-wise, and I propose that the architecture should look something like this:

Most of the fundamental parts (three tiers, common services, etc), and even many of the more specific (service interfaces/agents, data access, business entities, etc) are exactly the same as in the Application Architecture for .NET that I've mentioned before in this series of blog posts.

Note that a significant change is the merge of the lower part of the middle (business services) tier and the bottom (data services) tier. As I've outlined before, this is where the business logic and its data comes together in a nice mix called the business domains. With technologies like LINQ to SQL and WCF, most (if not all) of the data services tier are actually created using code generation. This means that any changes made to the different sources (data sources and services) can be captured by regenerating the code. The tools support is actually prepared for this kind of evolution in the integration between systems, and a simple "Update Service Reference" menu selection is all that is needed.

Another similar change is the clear separation between the service interfaces and the business domains. Where the business domains have a clear responsibility to handle the logic and data for a certain business domain, the service interfaces (designed according to the facade pattern) has a different set of responsibilities. The primary distinction of a service interface is that it probably fulfills a specific part of the system's functionality (use case). Also, as they are the "first line of defense", they should handle things like basic security (authentication, authorization, encryption, etc) as well as secure coding techniques (parameter checking, prevent things like SQL/code injection, etc), compression, transactions, logging, etc. A consequence of the separation with the business domains is that the service can be placed in a separate assembly. This is a good thing because a service interface probably uses a number of business domains that may (or may not) exist in numerous assemblies.

Finally, the user interface parts have been renamed to align with the use of the MVC pattern, and as already mentioned in previous posts, this will allow for better testing and the use of the same user interface logic for different clients (thin Web interfaces built with ASP.NET, rich interfaces built with WinForms, WPF or Silverlight, and of course mobile clients built with .NET CF and soon Silverlight, etc).

In upcoming posts, I will continue with more of my thoughts on the changes in mobile architecture, and of course also some code samples to show the theory in practice. Stay tuned!

I'm continuing the series that started with part 1 and part 2 by talking more about the changes in a modern mobile multi-tier architecture. We can see that the most important changes are happening on two levels, and the first is the tighter bond between the business logic and it's data that I talked about in my previous part in this series.

As I already mentioned in the previous post in this series, the second major change to the classic Application Architecture for .NET that you see on the left is the change in the way that clients exchange information with the server (or more general, the way that two systems or peers exchange information). As soon as Web Services arrived, we instantly understood that this would be the future way of communication between systems. At the time when we wrote our book, the basic plumbing wasn't in place, and most had to be done by hand. Since then the basic Web Service technologies (XML, SOAP, HTTP, etc) has been complemented with both new exiting ones to enable better support for security, sessions, transactions, etc, as well as much better tools support. The beauty of Web Services is that they can open up a "locked" architecture (that can only deliver a fixed UX, like most Web sites on the Internet) to any client. That client could be anything from a custom made application to another system that simply want to use only the services and the data. This is what my series on Windows Mobile Web Services (e.g. Movie Lookup Web Service) is all about. Most of you probably agree that cool sites like IMDB, and FlightExplorer become even better when they can participate in a mash-up application to deliver greater value.

One technology that is important in this change is WCF as it builds on the good things about Web Services, and also takes the concept one more step. It's what .NET Remoting should have been in the first place, and even if it can be confusing as a consequence if its versatility, the main message is that you can do everything that you can do with Web Services and so much more (and it also performs very well). Therefore, my recommendation is to take a hard look at this technology and evaluate if it brings something that you need in your mobile applications. Just to make you more interested, it can travel over a number of transports (HTTP, TCP, Named Pipes, MSMQ, etc). However, not all of these transports are supported out-of-the-box on .NET Compact Framework yet, but a great thing about WCF is that it can be extended on multiple levels (transport, bindings, etc). What is supported though, is the ability to solve a classic problem with mobile applications: How can I communicate efficiently with a device that may be shut down and that is very hard to address (changing IP addresses, etc)? It's possible using the WindowsMobileMailTransport class that allow messages to be sent as e-mail. In combination with Exchange Server, and it's push e-mail technology (a.k.a. DirectPush or Always-Up-To-Date), this means that mobile application can be built that communicate very efficiently with the server (or another peer).

In upcoming posts, I will continue with more of my thoughts on the changes in mobile architecture, and of course also some code samples to show the theory in practice.

To continue this series that started with A New Mobile N-tier Architecture (part 1), I will talk more about the changes in a modern mobile multi-tier architecture.  We can see that the most important changes are happening on two levels, and the first is the tighter bond between the business logic and it's data.

Before, we had a distinct separation in the two lower tiers between the logic and the data. The thinking was that the data services could be used by several parts of the business logic to handle basic CRUD operations. This is shown in the Application Architecture for .NET from 2002 that you see on the left where the business logic and the data access was divided into the lower two of the classic three tiers. However, the problem was that data without logic is almost useless, and even if the logic existed (in various business components) the natural relation with the data was not manifested.

The other change is the change in the way that clients exchange information with the server (or more general, the way that two systems or peers exchange information), and that will be the focus of the next part in this series.

If we look at technologies like LINQ and specifically LINQ2SQL (LINQ to SQL) the traditional separation between the logic and the data is encouraged. On the right you find an illustration what is happening in the lower two of the traditional three tiers. The observant note that the business entities is moving down to he data tier (where they belong), but more importantly, the two tiers are actually moving together. With a LINQ2SQL, the business logic can be implemented in the same data context (the ORM) class (by using the ability to define partial classes). I would like to call these merged entities domain components as they define and handle both the data and the logic for a specific business domain. So, the service interface (facade) would actually work with a number of domain components to deliver functionality to its clients. The challenge is how the functionality (logic + data) is spread among the domains to make them a perfect tradeoff between versatility and reusability. The bigger, the more versatile, the smaller, the more reusable. The general message is probably to keep them small and distinct.

In upcoming posts, I will continue with more of my thoughts on the changes in mobile architecture, and of course also some code samples to show the theory in practice.