Composite Web Application Block | Modularity Patterns

Composite Web Client Applications

A composite Web client application is a Web application that is composed of a number of discrete, independent, yet functionally complete, pieces. These pieces are integrated together within a Web server environment; they are presented to the user in a Web browser as a fully coherent Web client solution. The Composite pattern is a popular and recurring theme because it provides a flexible and scalable architecture that provides several key benefits, including the following:
  • It allows a higher degree of separation between application infrastructure and business logic.
  • It allows more independent development of the individual business logic components themselves.
  • It provides solution agility because business logic components can be flexibly combined to quickly yield a specific solution.
  • It promotes code re-use because it allows business logic components and the application infrastructure to be re-used 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.
A composite Web client application consists of functionality from several different sources. These sources include Web services, functionality in other applications, or entire systems (often, it interacts with multiple back-end systems). Figure 1 illustrates a composite Web client application that presents an integrated view of multiple services to the user.
CompositeWebClient.PNG
Figure 1
Composite Web client

A composite Web client application presents the functionality to the user as a single, composite application, such as those shown in Figure 2.
ExampleInterfaces-CompositeWebClientApp.PNG
Figure 2
Example interfaces of composite Web client applications

Modules

A Web client application that uses the Composite pattern generally involves a shell module, which provides the overall user interface structure. A shell module typically registers user interface components shared by other modules, 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. You can then create individual content pages that contain the content you want to display. When users request the content pages, they merge with the master page to produce output that combines the layout of the master page with the content from the content page.

Modules contain functionally discrete pieces, but they integrate with the user interface and communicate with each other. The shell module provides access to services required by other modules throughout the application. This means that the modules can use these capabilities instead of having to implement them themselves. This allows a solution to be developed much more quickly because the Web client infrastructure is already in place—the modules can focus on the business logic and their piece of the overall solution instead of focusing on the basic foundation that is required to provide the necessary Web client capabilities.
This provides a number of advantages in terms of a separation of roles between the developers of the modules and the solution designer/builder. Module developers are typically focused on implementing the business logic required to provide specific business focused functionality (for example, providing access to the inventory, CRM, ERP, and HR systems). The solution designers are able to define a solution to a business problem at a level that is higher and more broadly focused (for example, providing a call center solution, a bank teller solution, or a document collaboration solution).

Service-Oriented Architecture

This kind of architecture 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, the CRM system, 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, each service needs a certain amount of knowledge by the consuming client (for Web applications, the client of the service is code that runs on the Web server) so the service can be properly used, such as for a client application that must 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 solution. With this architecture, developers of the business capabilities, and the Web services that expose them, can develop the user interface and client-side logic to take maximum advantage of those services. This means that in addition to a menu of business capabilities and Web services, you can also have a menu of service agents that allow you to quickly and easily 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.

Composite Web Application Block | Modularity Patterns

Last edited Jan 17, 2008 at 3:02 PM by siacomuzzi, version 3

Comments

No comments yet.