Composite Web Client Applications
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies.
A composite Web client application is an application that is composed of discrete, functionally complete pieces. These modules are integrated within a Web server environment to create the application. Users access the application with a Web browser. To users, the application appears as a single Web client solution with many capabilities.
Composite Web applications are based on the Composite pattern. This pattern is popular because it provides a flexible and scalable architecture that has several benefits, including the following:
- It allows a higher degree of separation between the application infrastructure and the business logic.
- It allows independent development of the individual business logic components.
- It provides flexibility because business logic components can be quickly combined to yield a specific solution.
- It promotes code reuse because it allows business logic components and the application infrastructure to be reused across multiple solutions.
- It provides an excellent architecture for the front-end integration of line-of-business systems or service-oriented systems into a task-oriented user experience.
The Composite pattern also allows you to separate the roles of the developer and the architect. Developers typically focus on implementing modules that provide the business logic for a specific piece of functionality such as providing access to the inventory, customer relationship management (CRM) system, enterprise resource planning (ERP) system, and the human resources (HR) system. The architect provides an approach to a business problem such as the overall design for a call center or an on-line banking program.
Figure 1 illustrates a composite Web client application that presents an integrated view of multiple modules to the user. These modules can include Web services and functionality from other applications and other systems (Web client applications often interact with multiple back-end systems).
A composite Web client application presents the functionality to the user as a single application, such as those shown in Figure 2.
A Web client application that is based on the Composite pattern generally uses a shell module to provide the overall user interface structure. A shell module typically registers user interface components shared by other modules and contains global pages and one or more ASP.NET master pages that module developers can use to create a consistent layout for pages.
|Note: You can use ASP.NET master pages to create a consistent layout for the pages in your application. A single master page defines the appearance and behavior that you want for all the pages (or a group of pages) in your application. After you have a master page, you can create the individual content pages. When users request the content pages, they merge with the master page to produce an output that combines the layout of the master page with the content from the content page. For more information about ASP.NET master pages, see ASP.NET Master Pages Overview on MSDN.|
Modules contain functionally discrete pieces, but they integrate with the user interface and communicate with each other. The shell module provides access to common services that all the modules can use. Using the services that the shell provides instead of implementing them for each module allows you to develop Web client solutions quickly because the infrastructure is already in place. Each module should only implement the business logic that applies to a particular piece of the overall solution.
An architecture based on the Composite pattern fits extremely well into a service-oriented architecture. Frequently, an organization defines its Web service granularity based on business functions (which, in turn, is typically how the IT infrastructure itself is structured). This means that there will be a family of Web services for the ERP system, another for the CRM system, another for the inventory systems, and so on. This is a natural way for a service-oriented architecture to be developed and to evolve. Solutions are then built on top of these services, or on composites of these services. This forms composite solutions.
Typically, in a service-oriented architecture, each service needs a certain amount of knowledge about the consuming client (for Web applications, the client of the service is the code that runs on the Web server) so that the service can be properly consumed. For example, a client application might need to gather the appropriate security credentials, perform appropriate data caching, handle the semantics of dealing with the service in terms of tentative and cancelable operations, and so on. Typically, the client-side piece of logic that handles these issues for a service is known as a service agent.
There is a natural correspondence between the service agents and the modules that comprise a composite Web client application. By using modularity, developers who implement the business capabilities and the Web services that expose them can also develop the user interface and the client-side logic to take maximum advantage of those services. This means that in addition to a number of business capabilities and Web services, you can also have a number of service agents that allow you to construct a composite Web client solution.
Updates and Deployment
Because the modules that comprise the server-side solution are loosely coupled (that is, there is no hard dependency between them because the shell provides a standard but simple mechanism for them to interact with each other), these modules can be independently updated, developed, and deployed.