Smart clients-building distributed applications using the NHibernate and Rhino service bus

For a long time, my work was almost always a WEB application. When I was building a smart client application, I was very confused at first and didn't know how to build such an application. How do I handle data access? How does a smart client application communicate with a server?

And I've invested a lot, I've got some tools that can significantly reduce development time and cost, and I really want to continue to use those tools. It took me a while to delve into all the details, and during that time I was thinking about how to make the WEB application simpler, and of course I needed to know how to handle such an application first.

Smart client applications have pros and cons. On the positive side, smart clients are responsive and can improve their interactions with users. If you move processing to a client computer, you can also reduce the load on the server, and users can work as usual even if they are disconnected from the backend system.

On the other hand, there are some inherent problems with smart clients, including the need to address speed, security, and bandwidth limitations when accessing data over an Intranet or Internet. You are also responsible for implementing data synchronization between front-end and back-end systems, handling distributed change tracking, and dealing with problems that occur when used in an occasionally connected environment.

The smart client applications discussed in this article can be built using Windows presentation Foundation (WPF) or Silverlight. Because Silverlight has a subset of the WPF features, the techniques and methods I present here apply to both tools.

In this article, I'm going to use NHibernate for data access and reliable communication with the server using the Rhino service bus to start planning and building the smart client application process. I'm going to build an application called Alexandra, which is a front-end system for online lending libraries. The application itself is divided into two parts. The first part is an application server running a set of services (most of the business logic is on this server), using NHibernate to access the database. The second part is the smart client UI, which makes it easy for users to use those services.

NHibernate is an object-relational mapping (O/RM) framework designed to make it easy for users to use relational databases, just as they do with data in memory. The Rhino service Bus is an open source service bus built on the Microsoft. NET Framework, with the primary purpose of making deployment, development, and use easier.

Distribution of responsibilities

The first step in constructing the library is to correctly distribute the functions of the front-end system and the backend system. One way to do this is to have the application primarily responsible for the UI so that most of the processing is done on the client computer. In this case, the back-end server is almost a data repository.

In essence, this is the traditional client/server application, and the backend system is only a proxy for data storage. This is an effective design option if the backend system is just a data repository. For example, this architecture may be ideal for a personal book directory, because the application is designed to manage data for the user, and the server side does not need to manipulate the data.

For such applications, I recommend that you use a WCF RIA service or WCF data service. If you want a back-end server to provide a CRUD interface to the outside world, using WCF RIA Services or WCF Data Services can dramatically reduce the time it takes to build your application. While both of these technologies allow you to add your business logic to the CRUD interface, any attempt to add logic to the implementation of critical application functionality can eventually lead to unmanageable chaos.

I'm not going to explore how to build such an application in this article, but Brad Adams blogs.msdn.com/brada/archive/2009/08/06/on his blog business-apps-example-for-silverlight-3-rtm-and-net-ria-services-july-update-part-nhibernate.aspx details the use of NHibernate and WCF RIA Services build the operational steps for this application.

A completely different approach to this is that you can choose to implement most of the application's functionality on the backend, and the front-end is just for display. This approach may seem reasonable at first, because it's usually the way you write web-based applications, but it also means that you can't run real applications on the client. State management will become more difficult. In essence, you are still writing WEB applications, and all of its complex problems are unavoidable. You will not be able to transfer processing to the client computer, nor can you handle the problem of disconnected connections.

Worse, from a user's perspective, this approach means that the UI you are showing is slow, because all operations need to be passed to the server before returning.

I'm sure the method I used in this example resides between the two, and it won't surprise you. I want to run on the client computer to take full advantage of the opportunities that arise, but at the same time, most of the functionality of the application will run as a service on the back end, as shown in Figure 1.

Figure 1 Architecture of the application

The sample solution includes three projects that you can download from Github.com/ayende/alexandria. Alexandria.backend is a console application that contains back-end code. Alexandria.client contains front-end code that alexandria.messages the message definitions that are shared between the first two. To run the example, both Alexandria.backend and alexandria.client need to run.

One of the benefits of hosting a backend in a console application is that you can easily simulate a situation when a connection is disconnected: Simply close the back-end console application and reopen it.