Application Architecture

Modern enterprise applications are built using several components connected to one another, each providing a specific functionality. Components that perform similar types of functions are generally grouped into layers. These layers are further organized as a stack in which components in a higher layer use the services of components in the layer below. A component in a given layer will generally use the functionality of other components in its own layer or the layers below it. The diagram below shows a popular layer structure for an enterprise application.

• Presentation Layer: The presentation layer contains components needed to interact with the user of the application. Examples of such components are web pages, rich-client forms, user interaction process components etc.
• Business Layer: The business layer encapsulates the core business functionality of the application. Simple business functions can be implemented using stateless components whereas complex long running transactions can be implemented using stateful workflows. The business components are generally front-ended by a service interface that acts as a facade to hide the complexity of the business logic. This is commonly known as Service-Oriented Architecture (SOA).
• Data Access Layer: The data access layer provides a simple API for accessing and manipulating data. The components in this layer abstract the semantics of the underlying data access technology thus allowing the business layer to focus on business logic. Each component typically provides methods to perform Create, Read, Update, and Delete (CRUD) operations for a specific business entity.
• Data Stores: Enterprise applications store their data in one or more data stores. Databases and file systems are two very common types of data stores.

Note that layers are simply logical groupings of components that make up an application. How these layers are deployed on physical machines can vary widely depending on several factors. In the very simplistic scenario all the layers can reside on one machine. In a slightly more complex scenario, the presentation layer can reside on one machine, the business and data access layers on a second machine and the database on a third machine. More elaborate scenarios are possible. For example, a high traffic web site can deploy the presentation layer on a web farm consisting of tens of machines.

Architecture of AndroMDA Generated Applications

Now that we understand the basic concepts behind modern enterprise applications, let's discuss how AndroMDA implements these concepts. AndroMDA takes as its input a business model specified in the Unified Modeling Language (UML) and generates significant portions of the layers needed to build a .Net application. AndroMDA's ability to automatically translate high-level business specifications into production quality code results in significant time savings when implementing .Net applications. The diagram below maps various application layers to .Net technologies supported by AndroMDA.

• Presentation Layer: AndroMDA does not currently offer any generation for the front end, but typically applications are built with either Windows Forms or ASP.NET 2.0.
• Business Layer: The business layer generated by AndroMDA consists primarily of services that generated from classes defined in the model.  These services can be used directly as classes in application code or they can easily be wrapped in an ASMX web service.
• Data Access Layer: AndroMDA leverages the popular object-relational mapping tool called NHibernate to generate the data access layer for applications. It generates data access objects (DAOs) for entities defined in the UML model. These data access objects use the NHibernate API to convert database records to objects and vice-versa.
• Data Stores: Since AndroMDA generated applications use NHibernate to access the data, you can use any of the databases supported by NHibernate.

Data Propagation Between Layers

In addition to the concepts discussed above, it is important to understand how data propagates between various layers of an application. Let us start from the bottom up.

As you know, relational databases store data as records in tables. The data access layers fetches these records from the database and transforms them in to objects that represent entities in the business domain. Hence these objects are called business entities.

The data access layer passes the business entities to the business layer which performs business logic using these entities.

The last thing to discuss is the propagation of data between the business layer and the presentation layer. There are really two schools of thought on this subject. Some people recommend that the presentation layer should be given direct access to business entities. Others recommend just the opposite, i.e. business entities should be off limits to the presentation layer and that the business layer should package necessary information into so called "value objects" and transfer these value objects to the presentation layer. Let's look at the pros and cons of these two approaches.

The first approach (entities only, no value objects) is simpler to implement. You do not have to create value objects or write any code to transfer information between entities and value objects. In fact, for simple small applications where the the presentation layer and the service layer run on the same machine this approach will probably work just fine. However for larger more complex applications this approach does not scale well. Here's why:

• Business logic is no longer contained in the business layer. It is tempting to freely manipulate entities in the presentation layer and thus spread the business logic in multiple places - definitely a maintenance nightmare. In case there are multiple front-ends to a service, business logic must be duplicated in all these front-ends. In addition, there is no protection against the presentation layer corrupting the entities - intentionally or unintentionally!
• When the presentation layer is running on a different machine (as in the case of a rich client), it is very inefficient to serialize a whole network of entities and send it across the wire. Take the example of showing a list of orders to the user. In this scenario, you really don't need to transfer the gory details of every order to the client application. All you need is perhaps the order number, order date and total amount for each order. Later if the user wishes to see the details of a specific order, you can always serialize that entire order and send it across the wire.
• Passing real entities to the client may pose a security risk. Do you want the client application to have access to the salary information inside the Employee object or your profit margins inside the Order object?

Value objects provide a solution for all these problems. Yes, they require you to write a little extra code, but in return you get a bullet-proof business layer that communicates efficiently with the presentation layer. You can think of a value objects as a controlled view in to one or more entities that is relevant to your client application. Note that AndroMDA provides some basic support for translation between entities and value objects as you will see in the tutorial.

Services and NHibernate Sessions

Another key concept about AndroMDA generated applications is the strong association between service methods (i.e. operations exposed by a service) and NHibernate sessions. But before we introduce this concept we must lay out some ground work. The NHibernate session is a runtime object that allows an application to create, read, update and delete entities in the data store. As long as the session is "open", these entities are attached to the session and you can navigate from one entity to another using relationships between them. If a related entity is not yet in memory NHibernate will automatically pull it in for you (this is called "lazy loading"). However as soon you close the NHibernate session, the entities that exist in memory are considered to be "detached", i.e. NHibernate no longer knows about them. You are free to hold references to such entities but NHibernate will no longer pull in associated entities if they don't exist in memory already. If you accidentally try to access such associated entities you will get a NHibernateLazyInitializationException.

Now that we understand this background material, let us discuss the relationship between a service method and a NHibernate session. When a client application calls a service method a new NHibernate session is opened automatically. You do not have to write any code to do this. Similarly, when the service method exits the associated NHibernate session is closed automatically. In other words, the lifespan of a NHibernate session is bounded by the beginning and ending of a service method call. Consequently, entities are attached to NHibernate session for the entire duration of the service call, but are detached from this session as soon as the service call ends. As a result, if your service method returns raw entities, the client must be extra careful not to access related entities that are not in memory already. Anyway, you can avoid all this by following the recommendation in the earlier section, i.e. transfer all relevant information into value objects while the session is still open and pass these value objects back to your caller as a return value. In other words, think of a service method as a logical transactional boundary - do everything you need to do within the method and then return the results as value objects.

Another implication of the strong association between a service method and a NHibernate session is that client applications should not try to bypass the service layer and interact directly with the lower layers. You may be able to brute force your way into one data access object, but sooner or later you will get into trouble!

What's Next?

Now that you understand the basic tenets of AndroMDA, let's describe the sample application we will implement in this tutorial. Click here to get started.