Composite Web Clients

A composite Web client application is a Web application that is composed of a number of discrete and independent 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.

wcsf-Intro-compositeclient.png

A composite Web client application presents the functionality to the user as a single, composite application, such as those shown in this figure:

wcsf-Intro-compositeclientUI.png

Shell and Modules

A Web client using the Composite pattern generally involves a shell, which provides the overall user interface structure. For a Web client, the shell is a master page.

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 look and feel and standard 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, communicate with the shell, and communicate with each other. The shell provides access to services required by modules throughout the application. This means that the modules can leverage 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 higher and more broadly focused level of abstraction (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, leading to form "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 used properly; for example, so the client can 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.

Last edited Jan 8, 2007 at 10:04 PM by blainew, version 5

Comments

scharada Mar 26, 2007 at 4:50 PM 
Would you please provide the themes associated with the samles shown above. TIA

andyfromfl Jan 30, 2007 at 4:11 PM 
This depends on the app domain that the component is run in. If you load a module, it loads in the current app domain by default- assemblies are always in the app domain once loaded into it. Loading an assembly or module into a new app domain allows you to unload that app domain (and all the modules in it).

ashithmr Jan 11, 2007 at 7:09 AM 
I would like to know how is the loading and unloading of modules handled by the shell. Is it possible to unload a module(.dll) in runtime.

Please throw some light on this.