This chapter has given a broad overview and introduction into architecture design and its advantages and disadvantages. You have seen how .NET implements different technologies for achieving enterprise applications and different ways in which you can leverage .NET in an enterprise environment. The next chapter introduces you to the application that you will create throughout this book as well as how to set up the application infrastructure. It will employ a number of techniques discussed in this chapter. You will find as you read this book that it is far from theoretical; specifically, you will put into practice all of the techniques needed to create an enterprise-level application by building a working n-tier application.
Chapter 2: Building an N-Tier Application
Chapter 1, "Understanding Application Architecture: An Overview," covered the basic structure and the pros and cons of different types of application architectures. You will spend the rest of this book building an n-tier application with a Windows, Web, and Web service interface that is accessible by virtually any device in one way or another. By the time you are done building this application, you will have an in-depth understanding of the process involved in building n-tier applications, including the ability to build them quickly and efficiently and the tradeoffs you need make.
This application uses the Northwind database that ships with SQL Server. Microsoft Access also supplies this database, but because of the way this application is being written, you cannot substitute Access for SQL Server. You can download the 120-day trial version of SQL Server at http://www.microsoft.com/sql.
Making Design Choices
The application you will build is flexible yet easy to maintain and extend. To that end, you have some choices to make early on to really understand how your objects are going to communicate and the tradeoffs you need to make.
Understanding Cross-Process Communication: Remoting Channels
The first decision to make is always which technologies the components will use to communicate remotely. This choice will have a wide-ranging impact on your application, both for the present and for the future. The .NET Framework provides several methods for communication that include COM+ and a new technology called remoting. Remoting is the .NET term for cross-process communication and is the preferred method for communication in .NET. There are many different aspects to remoting that would fill a book or two, so I will not cover all of the details here.
An excellent book that explains a great deal more about remoting and all of its permutations is Advanced .NET Remoting by Ingo Rammer (Apress, 2002). This book contains an in-depth explanation of all of the remoting techniques and options.
When using remoting, you create a channel to the remote objects, and you pass data over this channel. You can create two types of channels to communicate between objects: a Transmission Control Protocol (TCP) channel or a Hypertext Transfer Protocol (HTTP) channel. This choice is an important one that will influence everything from transmission speed to extensibility to security. In this chapter, you will use an HTTP channel because the objects will be hosted in Internet Information Server (IIS). This gives you the ability to use Windows Integrated Authentication, which provides a more secure environment. It also allows you to upgrade to a Secure Sockets Layer (SSL) connection with no changes to the code if you choose to do this.
The ability to upgrade to an SSL connection is indeed great. You can create a highly secure application without having any real knowledge about how to encrypt and secure data. However, you must also measure the impact of this to your application. An SSL connection means the channel will be encrypted, but an encrypted channel will be slower and will degrade the performance of an application.
Using IIS to host your remote components also gives you the ability to load balance your application by placing it into a Web farm; again, this requires no additional effort on your part.
Understanding Cross-Process Communication: Data Serialization
The data that is passed over the remoting channel is serialized. You use two built-in data formats when serializing data over a remoting channel: binary and Simple Object Access Protocol (SOAP). Picking the right format is just as important as picking the right type of channel. Binary data is just that—it is binary data, and as such it is a compact stream of data. Data that is serialized into the SOAP format is not very compact and will always create a larger "payload" to deliver across the channel.
If you are not familiar with SOAP, it is a type of Extensible Markup Language (XML) format in that it is a self-describing text format. You do not need to know anything about it when serializing the data, but because there are so many things you can do with a SOAP message, you should become familiar with it. You can find out more about SOAP at http://msdn.microsoft.com.
One advantage that the SOAP format has is that it is nonexecutable code and is therefore "safe." That is, it can pass through firewalls where binary data cannot. However, because this is a book about enterprise development, let's assume that all communication will occur within the firewall. Because you want the fastest possible communication speed, you will use the binary format.
This choice does indeed have far-flung consequences. If you are creating a Web site that is hosted externally of your enterprise, using binary format will not work. If you envision the application expanding beyond the firewall, then you must use the SOAP format. However, .NET gives you the ability to change the type of serialization with almost no effort if you decide to make a change later.
Now that you have made these crucial choices, it is time to set up IIS to host your middle-tier components.