In this part, I will continue the implementation of the middle tier by publishing a WCF service, and if you want some background, please see the previous parts:

The implemented architecture is published on CodePlex in a project called KISS Architecture, and this means that you can access the full source code as well as discuss it, come with suggested improvements, etc. As I walk you through the creation of the architecture, I suggest you keep the source code handy to check out more details.

It's time to create the service, and I do that by creating a new project of type "WCF Service Application" and name it Kiss.Service. First I add a reference to the Kiss.Domain project, and then I rename the automatically generated interface to IOrderService.cs. I change its code to...

...and make sure all references to it is refactored (there are a number of places, like in the Web.config file). Then I rename the generated service class to OrderService.cs and update its (references and) code to:

This is the actual implementation of the service that implement the interface mentioned above, and each method simply use the domain class to do its work. The decoration (attribute) of the service class is needed to make the service available for a Silverlight 2 client. Even if no such client exist for Windows Mobile yet, this is a good measure to prepare for the future.

Another similar measure is to include two more files in the service project, and the first is clientaccesspolicy.xml and the second is crossdomain.xml. The purpose of these files is to make the service available for applications that make cross domain calls, and the first is specific to Silverlight and the second is used by Flash applications, among others. Here is a sample clientaccesspolicy.xml file...

...that allow any client to access the service. A final measure that is necessary for both Silverlight and Windows Mobile WCF clients is to make sure that the service use the basicHttpBinding, and here is an extract of the Web.config file:

In the next part, I will start implementing the Windows Mobile client.

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.

We will continue the more practical part of this series by showing how the new mobile architecture looks in code, and if you want some background, please see the previous parts:

• Part 1 was a general introduction
• Part 2 talked about the changes in the lower tiers (logic + data, LINQ2SQL)
• Part 3 discussed the changes in communication (WCF)
• Part 4 covered important stuff in the user interface (MVC)
• Part 5 summarized the theory and outlined the new architecture
• Part 6 started the walkthrough of the architecture code by looking at the business domain
• Part 7 continued the code walkthrough with a look at the service (WCF)

The implemented architecture is published on CodePlex in a project called Windows Mobile Architecture Blueprint, and this means that you can access the full source code as well as discuss it, come with suggested improvements, etc. As I walk you through the creation of the architecture, we suggest you keep the source code handy to check out more details.

We are now ready to consume the WCF service that we created in the previous post, and therefore we have added a new "Smart Device Project" and selected to create a Device application targeting Windows Mobile 6 Standard (a.k.a Smartphone) and the latest .NET Compact Framework (3.5).

As the tools support is not yet in place in Visual Studio, to consume a WCF service, you need to first download and install the Power Toys for .NET Compact Framework 3.5. The tool that you are after is named NetCFSvcUtil.exe, and you use it like this...

...and in the source code you can find a batch file (CreateServiceClient.bat) that will run this command (note that you may have to change the path to the NetCFSvcUtil utility depending on whether you're running on 32- or 64-bit). Note that the WCF service must be running when you run this command, and the out of running this batch file looks something like this...

...with the result that two files are generated (Service.cs and CFClientBase.cs). As there files are already part of the source code, they will simply be replaced and the procedure with running the batch file is the next best thing to what you would expect from integrated support in Visual Studio.

Now, with these two files in place, we can start consuming the WCF service with code like this...

...and the first thing we do is to set an endpoint of the service that the mobile device can reach (in this case an IP address). Then the service proxy (ServiceClient) is instantiated and used to retrieve the list of categories. Note that the business entity (Category) that was declared back in the business domain (automatically generated by LINQ2SQL, and automatically serialized by WCF) is readily available on the mobile client (thanks to the proxy we generated above).

In future posts, we will cover more parts of the architecture blueprint implementation.

In some projects, we have used a very simple and straightforward implementation by our former fellow MVP, Alex Yakhnin (he's now employed by Microsoft), that he published as a small blog series last fall (see part 1 and part 2).

I will continue the more practical part of this series by showing how the new mobile architecture looks in code, and if you want some background, please see the previous parts:

• Part 1 was a general introduction
• Part 2 talked about the changes in the lower tiers (logic + data, LINQ2SQL)
• Part 3 discussed the changes in communication (WCF)
• Part 4 covered important stuff in the user interface (MVC)
• Part 5 summarized the theory and outlined the new architecture
• Part 6 started the walkthrough of the architecture code by looking at the business domain

The implemented architecture is published on CodePlex in a project called Windows Mobile Architecture Blueprint, and this means that you can access the full source code as well as discuss it, come with suggested improvements, etc. As I walk you through the creation of the architecture, I suggest you keep the source code handy to check out more details.

The next step in building the architecture is to create the service interface (i.e. the service), and therefore I have added a new "WCF Service Application" project called Blueprint.Facade to the solution that already included the business domain project (Blueprint.Domain). My first service will be publishing the very simple functionality that the business domain provides (the ability to retrieve all categories from the database). First, I have renamed the service interface to IService and the service implementation to Service (removed the "1" at the end on both), and here you need to make sure that all references are updated (four occurences in the web.config file and don't forget the one in Service.svc). The implementation of the service interface (IService.cs) can be done like this...

...and with a reference to the business domain project, the service implementation (Service.svc.cs) can be implemented with this code...

...to complete the implementation of the service. When the project is built and run, the WCF is ready to be consumed, and therefore it's a good idea to remember the URL to the service as we will need it in the next post when we will look at how this service can be consumed from a mobile client application.

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.

When we wrote our book Pocket PC Development in the Enterprise back in 2001, one of our goals was to help developers with an architectural blueprint for building solid mobile multi-tier applications. At that time, most focus for mobile developers was on the user interface and the device side of the mobile solution.

Since then, a lot of things have changed. The Windows Mobile development platform with .NET Compact Framework as the foundation, has evolved into a very powerful offering to mobile developers. Technologies has constantly migrated from the desktop (full) framework, even if it sometimes seems too slow when one is eagerly waiting. Who else is eager to use LINQ to SQL with SQL Server Compact, full WCF support, or build mobile Silverlight applications?

But, some things remain the same, and one of these is the view on mobile solutions as being a part of a bigger whole. Almost no mobile applications live alone! In most cases, they are part of an integrated solution that extend existing business processes to reach further out in the hands of the employees. Therefore, a modern mobile architecture starts with a solid architecture on the server, and can be extended to support multiple channels (thin/rich clients, fixed/mobile devices, etc).

During the years since we wrote the book, the blueprint has evolved with the changes in technology. I say evolve, because most changes only meant that the architecture was upgraded to embrace the new technologies. Recently, however, some major changes has occurred that force some more drastic changes to the architecture. The most significant are LINQ (specifically LINQ to SQL and the upcoming ADO.NET Entity Framework), WCF, and Silverlight. The observant reader notes that these technologies span the whole architecture spectrum from data access, via communcation links to UX. In addition to these, there are also a number of enhancements for the mobile developer that spice up an architecture that in addition to support traditional clients, it also needs to support mobile clients as well.

As you will see, when we move forward in this series of blog posts, I'm a big fan of the KISS principle. Therefore, the primary goal is to keep things as simple as possible to minimize the learning curve while at the same time still create a valid architecture that is easy to implement, test, and maintain.

In upcoming posts, I will continue with more of my thoughts on the changes in architecture in general and more specifically on architectures that suite mobile solutions.

So, my first CodePlex project is in the air, and it's called Web Service Compression for Compact Framework. I have made the first public released available today, and if you want to take part in further development, just let me know and I'll add you to the project.

This project started with an article called Web Service Compression with .NET CF that focused on standard HTTP 1.1 Compression, and in that article you can find some interesting results from using compression. The main lessons learned was "On small payloads the saving is at least 50%, and on larger payloads, more than 90% compression, and cost saving, can be achieved. When it comes to performance, the tests show that for small payloads, we have to pay a performance penalty of about 20%, but for larger payloads, we actually get a performance win of about 50%". The idea was developed further in the article Two-Way .NET CF Web Service Compression when the idea of also compressing the requests from the WM device was introduced. The approach used SOAP Extensions, and that is still true for the code in the new CodePlex project.

The fact that compression is now included in CF means that I had to say goodbye to an old and dear friend - SharpZipLib (many thanks, Mike Krüger and the rest of the team). I have used this library in numerous projects through the years, and it has served me very well. The best thing with saying bye was, when converting to the System.IO.Compression namespace, that only two lines of code needed change.

I think that a future direction for this project could be to support WCF services, and as there are several ways to approach that, I was thinking about behaviors...