|
|
As professional developers, it is quite frustrating to realize that we are making the same mistakes over and over again. It is hard enough to develop applications, let alone develop reusable and scalable solutions. Like most programmers, you have probably worked on a project that had you banging your head against the wall because of a problem and thought, "Ugh—that must have been dealt with before." You probably have had a similar feeling when you talked to the architect of a project about some good patterns and all you got back was a "Hmmm, if we had some more time, we could have constructed this part of the application better. But since we already have coded this section, we can't change it now."
In this chapter, we will discuss how you can avoid most of these negative experiences when creating an enterprise application. We will examine what an enterprise application needs and how you can meet such requirements with a common architecture. The following text will sometimes be a bit technical, but we suggest you read it through to have an understanding of the problems that face developers daily. The ideas and architectures together with the coding conventions and the design patterns will allow you to achieve a robust enterprise application architecture in your applications. We have used all the patterns and conventions found in this chapter with good results for a while, and therefore we can recommend you use them as well.
A well-designed enterprise application requires several important things, but most crucial are the following:
Availability: Every enterprise application has a solution or strategy to achieve high availability. Rather than measure the ability in terms of the five nines, the goal is to develop high-availability infrastructures for meeting unique customer requirements. Each customer has a different definition of availability; some common obstacles to availability exist in most applications, however. In this chapter, we will show architecture that best combats downtime and meets business requirements. This will mostly be achieved by scaling out the architecture.
Security: Security in an enterprise application is of high importance, since the system information contained therein is probably vital for the company that owns it. The architecture of an enterprise application should be of a defensive nature, which means that security is applied throughout the infrastructure—from transport security to data security. In this chapter, we will show how you can incorporate Web service security in your facade layers.
Scalability: Scaling out and scaling up lets the enterprise application grow with an organization's needs in a controlled and safe way. Scaling out is mainly used on Web servers and in application layers where load balancing can be employed in an easy manner, whereas scaling up is often used on the database layer where replication of data between different servers will sometimes introduce complex administration issues. The architecture we study in this chapter makes it possible to scale up and scale out on all layers therein.
Manageability and administration: When you are scaling out and scaling up, it is easy to forget the people who will administrate the application for years after you have left the playing field. It is important to work with an architecture that makes it easy to trace, monitor, deploy, and debug. The key here is to plan and lay out the foundation of the architecture before the realization of it begins. In our experience, this is one of the main problems in many projects.
Reliability: An enterprise application needs to be reliable. To achieve this, you need to keep a standardized architecture that can be deployed on several servers (a Web farm, for instance) in an easy manner.
Supportability: An application without support is likely to make its users frustrated. Soon or later those users will start asking questions that need to be answered by someone—probably you. Support for incorporated third-party controls is also important to be able to maintain the application in a correct and safe manner.
Repeatability: When you design your enterprise applications for availability and scalability, you need to be able to rapidly deploy such applications across your Web farms and clusters. With .NET, you have this capability.
Standardization: No customer likes "Bob's hack" or "Steve's fix" in the long term. By the time some new functionality needs to be implemented, Bob might have moved to the Caribbean and taken the source with him. The use of standardized infrastructure components through well-known architectural specifications creates predictable and reliable solutions, and also provides a basis for an organization to manage change and growth. The structure for handling the source from a project often has low priority, which can jeopardize the future maintenance of the application.
To achieve these goals, you need to have architecture and an enterprise infrastructure that can support you in the creation of your enterprise application. Microsoft has developed several servers that help you with the different "bricks" from the preceding list.
The application blocks in Figure 5-1 are used in the enterprise application architecture. SQL Server helps you to store permanent data for the application in a safe way, making it possible to scale up and scale out when necessary.
BizTalk Server serves as a gateway to other applications, providing a graphical, designable interface with the world outside your application. BizTalk Server is also used for orchestration and maintenance of business flows.
Commerce Server from Microsoft provides you with a commerce architecture designed to handle the common tasks in a commerce application. Commerce Server is discussed in Chapter 2.
Content Management Server is similar to the Commerce Server in the way it provides enterprise applications with a framework for handling content in a Web-based application interface. We have often found that the architecture from a Content Management Server system is a wise choice for developing Web-based interfaces for enterprise applications instead of developing the content handling from scratch. Later in this chapter in the section "Content Management," we will talk about two different content management systems that will boost the development of content-based Web applications.
The application infrastructure elements include five items of high importance in the enterprise application, and we discuss these next.
The first application infrastructure element, which we will only mention briefly here, is Internet Information Services (IIS). Through IIS you can host your interactive client interface (Web-based user interface) and also your interfaces with other applications in the form of .NET Remoting objects or Web services. Chapter 7 covers IIS in more detail.
As mentioned earlier, two of the requirements for an enterprise application are scalability and performance. To achieve this, enterprise architecture requires COM+ for object pooling and transaction support. COM+ also provides you with services to handle the following:
Distributed transaction coordination, which ensures the integrity of databases
Queued components, which provide asynchronous execution and can help applications to handle network failures
Object pooling, which allows applications to support larger numbers of users than would otherwise be possible
COM+ uses the notion of COM+ application, which is the place where your components are hosted to take advantage of COM+. If you are developing an enterprise application based on .NET, the hosted .NET objects in COM+ are wrapped with a COM object due to COM+ being written in unmanaged code in the current release. This gives you a slight performance hit due to the interoperation between the COM object and the real .NET object. This performance hit is something you should be able to live with, however, as COM+ gives you so much back.
Microsoft Message Queuing (MSMQ) is used to support an enterprise application with asynchronous calls that will, for instance, give you reliability even if the network connection to your database server breaks down. (At least you will not lose any incoming data.) It is also used in decoupled enterprise applications where the client interface is not connected to the data source all the time. The default behavior for MSMQ is shown in Figure 5-2.
The sending application or component prepares a message and writes it to a message queue. The message queue system handles the queue. The queues in MSMQ can be handled either as persistent queues or as in-memory queues. The in-memory queues are faster from a performance point of view because no disk access is necessary to access the queue. From a security performance perspective, however, they are hazardous. If the system goes down, the content in the queues disappears, since it was only stored in memory. If you need the content in the queues to remain there for a long period, use persistent queues, as the content in a persistent queue will be stored to disk instead of in memory.
Queues can be private or public. Public queues are published in the Active Directory. Applications running in the same network but on a different server can retrieve information about the queues via Active Directory. Private queues are only accessible locally on the machine and are not published via Active Directory.
To take advantage of MSMQ from a component, you need to do the following:
Create a queue that should be used for your messages.
Add code to the component to write to the queue and to read from it.
The System.Messaging namespace contains classes that you use when working with message queues. In Chapter 9, we will demonstrate how you can use these classes to create a queue and post messages. There we will also look at how to use queued components.
| Note |
You do not need to use Enterprise Services to take advantage of MSMQ. Since classes are exposed via the System.Messaging namespace, you are free to use them outside Enterprise Services. |
Finally, a platform is available on which to run all the previously mentioned blocks for your enterprise applications—the Windows Server 2003 and the .NET Framework. We will not talk so much about the new stuff found in this Windows version here (refer back to Chapter 4 for more information), but one change of great importance has been made for enterprise applications in terms of performance. When COM was "upgraded" to COM+, it was also more closely integrated to the Windows 2000 operating system. The difference in performance test results conducted on Windows NT 4.0 with COM objects in the MTS compared to similar tests with Windows 2000 and COM+ is dramatic. A significant improvement has been made in the number of requests per second that can be handled by an enterprise application developed with COM+ instead of only COM objects hosted by MTS.
We witnessed a similar performance boost when we moved from Windows 2000 Server to Windows Server 2003, in which many improvements have been made. In Chapter 9, we will compare Windows 2000 Server running with .NET Framework 1.1 and the new Windows Server 2003 running with the .NET Framework 1.1 and IIS 6.0.
For more information about the Windows Server families, please see Chapter 2.
The .NET Framework is the final toolbox that the enterprise architecture relies on. It is a computing platform aimed at simplifying application development. Microsoft has put a lot of effort into this so that it would fulfill the demands of a distributed application environment like the Internet. Another goal has been to use industry standards in communication (like SOAP, XML, HTTP, and XML) so that integration with other platforms, and code written on them, would be possible. With the use of Web services, it is now quite easy for developers to reuse logic written in another language on another platform. Correctly used, this could save enterprises money in the long run. Many companies nowadays offer services, both internal as well as external, built on the .NET Framework.
The .NET Framework is being developed for platforms other than Windows, too. Versions for Linux and UNIX (mostly for FreeBSD) are available or under development right now.
| Note |
A good source for news on .NET Framework development for other platforms is http://c2.com/cgi/wiki?DotNetForLinux. A good article on this topic can also be found at http://msdn.microsoft.com/msdnmag/issues/02/07/SharedSourceCLI/. |
The .NET Framework consists of two main components:
The class library
The common language runtime (CLR)
The class library offers an object-oriented collection of types that you can use (and reuse) to build your applications. Since the class library exposes a set of interfaces that you can use to extend the library, you can build your own classes so they blend seamlessly into the .NET class library.
The common language runtime (CLR) is the heart and soul of the .NET Framework. It manages code at execution time by providing memory management, thread management, Remoting, and other system core services. One of the principles of the runtime is code management. Therefore, code that targets the runtime, as shown in Figure 5-3, is called managed code, and code that does not is called unmanaged code.
In Figure 5-3, you see that the CLR is more or less an interface to the operating system. The class library and your own custom libraries sit on top of the CLR, and the managed applications either use these libraries or call the CLR directly.
Unmanaged applications access the operating system directly. IIS, for example, calls the OS without going through the framework. In Figure 5-4, you see that an unmanaged application (in this case ASP.NET, but it can also be IIS or SQL Server, for example) can host the CLR. Unmanaged applications can load the common language runtime into their own processes. From there, they initiate the execution of managed code. This way, both managed and unmanaged features are available in the environment the unmanaged application has created.
There is also a third part of the .NET Framework we have not yet mentioned. The Common Type System (CTS), shown in Figure 5-5, describes the data types and the programming constructs available to the .NET languages. Every language does not have to implement them all, so you need to be aware of this when you build applications that offer services to other platforms built on other .NET languages.
To overcome this, all .NET languages should implement a subset of these types and constructs—consider these minimum requirements for what these languages must support. This subset is included in the Common Language Specification (CLS) as you see in Figure 5-6. If you build .NET applications that only use the CLS, you can be certain all other .NET applications can understand them.
To enhance performance, managed code is never interpreted. When you compile a C# program (or any other .NET language program), the code is compiled to an intermediate language. At execution time, this is compiled by the Just-In-Time (JIT) compiler, and the managed code then runs in the native machine language of the system it executes on.
This was a short overview of the .NET Framework and its building blocks, but it should give you enough background to be able to understand the rest of this book.
Microsoft describes enterprise architecture in a way that is useful for our purposes, so we will base this section on its definition and usage of enterprise architecture. For more information about how Microsoft defines this topic, please visit http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnea/html/eaarchover.asp.
Understanding your customer's business structure and the way information flows is of great importance to be able to deliver the right application. To help you in this analysis there exists the enterprise architecture (EA). ANSI/IEEE Std 1471-2000 defines an enterprise architecture in this way: "the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution."
In clear English, the enterprise architecture is a way to analyze business and from the collected information create a map of the company's dataflow. The map will be used as basis for business and technology changes in the future. Enterprise architecture can be drawn in many ways—despite the target audience—but common to any depiction of enterprise architecture is the inclusion of a comprehensive set of cohesive models that describes the structure and model of an enterprise. The different models in the EA are arranged in a logical manner and provide deeper and deeper levels of details about the enterprise, in particular the following:
We divide the different models in enterprise architecture into four different areas: the business perspective, information perspective, application perspective, and technology perspective.
The business perspective describes how the business works, the strategies that the business follows, and the long-term goals for the business. It also contains the business processes and all the business functions performed. A rough picture of the different organizational structures is also encompassed by this perspective, together with the relationship between all the previously mentioned blocks that comprise an enterprise application.
The information perspective describes what the organization needs to know to run its business processes and operations. It contains the data models controlling the organization of the data together with the data management policies that should be used to maintain the data. The information perspective also describes how the information is created and consumed in the organization. This includes information about how the data fits into the workflow for the organization, and how the data is stored for all kinds of media.
The application perspective defines the enterprise's application portfolio and is application centered. Here you describe the different automated services that support your business processes as well as the interaction and dependencies of the existing application systems. The application perspective also contains a plan for developing new applications and modifying old applications based on the enterprise goals, technology platforms, and objectives.
Finally, it is the technology perspective that lays out the hardware and software support in the organization. It includes descriptions of the desktop and server hardware. The technology perspective also specifies the operating systems used and external equipment such as scanners, printers, and modems. This is a never-ending granularity that starts with a rough map that is refined until the organization can make decisions based on the information.
To understand subsequent discussions of enterprise application architecture in this chapter, you need to know the various terminology used to describe enterprise applications, which we will quickly cover here.
A component refers to a logical software module, mainly a .NET or COM component. A collection of components makes up an application. These components may be further grouped into various types that determine the layer to which each component belongs.
A layer refers to a logical partition of an application. This partition consists of components of a given type. The model we present here partitions an application into the following four layers, according to the application duties performed by the component types of each layer:
UI layer: Also known as the presentation layer, this includes component types such as user interface (UI) and UI process components, which deal primarily with the creation of UI elements and encapsulate the logic that handles the user's navigation of the UI.
Facade layer: Contains Facade objects that make it easier to request information from the business layer. The facade layer also makes it easier to handle processes such as wizards, since the wizard flow will be coded in a process component.
Business layer: Includes component types such as business workflow, business component (BC), business entity, and service interface (SI), which encapsulate the business processes and rules that form the core of the application.
Data access layer: Includes component types such as data access (DA) logic and service agent (SA) components, which encapsulate the complexities of dealing with data access for specific data sources (DS) and Web services, respectively.
A tier is a logical entity, composed of one or more physical hosts or devices to which the logical layers are deployed. Sometimes the physical tiers correspond directly to the logical layers (for example, the Web tier could correspond to the UI layer, the application tier to the business layer, and the data tier to the data layer), and sometimes multiple layers are deployed to a single tier.
Figure 5-7 depicts a hypothetical scenario where the UI layer, or presentation layer, is deployed to the Web tier and the business and data layers are deployed to the application tier.
|
|
