Designing composite applications: Design patterns

Learn how to recognize and optimize the design patterns that occur when you develop composite applications.


Jo Grant (, Senior Software Engineer, IBM

Jo Grant is a Senior Software Engineer for IBM Lotus, specializing in Eclipse-based technology.

Craig Wolpert (, Senior Software Engineer, IBM

Craig Wolpert is a Senior Software Engineer for the IBM Lotus Software ISV Technical Enablement program.

27 June 2008 (First published 11 December 2007)

Also available in Chinese Russian Japanese

Editor's note: This article is the third in a series of articles on composite applications to be published on developerWorks Lotus over the next few months. See the previous articles, "Designing composite applications: Component design" and "The Lead Manager application in IBM Lotus Notes V8: An Overview."

Composite applications are a key element in a Service-Oriented Architecture (SOA) and contextual collaboration strategy. They support business flexibility for companies and organizations that must rapidly respond to changing demands in today's competitive markets. Composite applications are aggregations of user interface components that are loosely coupled to support inter-component communication.

Components can be reused in multiple composite applications. The ability to combine multiple technologies into a single application provides significant business value. It enables companies to protect and extend their existing assets with increasing degrees of flexibility, and it allows them to respond quickly and cost effectively to their emerging business requirements with applications that are significantly easier to create than multiple application development environments.

This loose coupling of the composite application architecture also enables diverse groups in different locations to leverage each others' efforts and to interoperate with each other. For example, one department may be working on the accounting application for a company, while another group is working on a sales lead tracking application. The composite application vision is to add to the accounting application some components from the sales lead tracking application to give pertinent views of assets in an accounting context. Similarly, the sales lead tracking application could incorporate components from the accounting application to give accounting information within an asset context. As your company develops more and more composite applications, the potential for integration increases exponentially. The goal is that the whole is greater than the sum of the parts.

The composition application model is already familiar to IBM WebSphere Portal developers. This approach has been extended to IBM Lotus Notes V8, enabling Lotus Notes developers to surface their Lotus Notes applications as one or more components in a composite application. IBM Lotus Domino Designer has been extended to leverage the property broker and to provide a more intuitive user environment. Lotus Notes V8 also supports the inclusion of Eclipse components. A composite application may have any combination of Lotus Notes and Eclipse components. These components may be presented together in the same user interface (UI) for on-the-glass integration, or if extended to use the property broker, they can interoperate with each other fully. You can define composite applications using the Composite Application Editor or the WebSphere Portal Application Template Editor.

The development of components for composite applications is different from traditional Eclipse or Lotus Notes application development. It is highly desirable to create components that are sufficiently flexible so that they can be deployed in applications at later dates without significant rework. This article discusses approaches to take in designing such components and best practices to consider adopting along the way.


This article assumes familiarity with composite applications in IBM Lotus Notes, so it may be useful for you to review the introduction to the composite application section in the IBM Lotus Domino Designer Help.

You should then review the developerWorks Lotus articles, "The Lead Manager application in IBM Lotus Notes V8: An overview" and "Designing composite applications: Component design," which cover component design from a high level. They discuss domain-centric components and contextual domain components, which are meta-patterns in and of themselves.

Patterns of development

The idea that in development we are often solving similar problems in similar ways has achieved great traction. Beyond its original application to object-oriented programming, people have found that there are many environments in which it is fruitful to look at work done in terms of patterns; in other words, to come up with generic solutions to generic problems that have wide applications. Composite application design and development are no different, and in this article, we look at patterns that make sense in this respect.

To organize the material, we break the types of patterns into a few different categories:

  • Patterns that define common types of components
  • Patterns that define groups of components in terms of how they are laid out and how they interoperate
  • Patterns of applications or overall design techniques that can be used to structure your entire composite application or suite of composite applications

Component patterns

This section describes various common types of components.

Selection components

Selection components allow values to cross between information domains. For example, a travel request submission may contain an employee number referring to a record in Human Resources, or it may contain a cost center identifying a control center in the accounting package. The travel request application tracks these values only for reference and in its business logic, where it intersects with those other information domains. At a UI level, the fields for values not defined by this information domain are frequently just boxes that a user must fill in, which leaves room for typing mistakes.

Each application can create a number of selection components appropriate to the information in its domain. Because an application has complete knowledge of its domain, it can present to the user all the appropriate methods for selection. This is a classic example of a contextual domain component as discussed in the developerWorks Lotus article, "Designing composite applications: Component design." In our previous example, the Human Resources application might produce a selection component for choosing employees, letting you search by name, email, phone, location, or any of the other fields that the application tracks. The output of the component can be any one of those fields or the employee number, which is required for a travel request.

The component can render itself in one of two ways:

  • It can have a UI presence that is designed to live in the periphery or dashboard of an application page in which the composition of the primary record occurs. Edit fields of the composition area are tied to the selection component. If the value is known, it can just be typed into the editor; if not, the selection component can be used to select and search, after which the value is populated back into the editor.
  • It can have an invisible component with minimal UI. In addition to properties and actions to consume and broadcast the indexed value in question, there is another value telling it to display its UI. This is a pop-up dialog box containing the same search choices as with the component rendering. Although this requires a Lookup button on the originating component (thus making it a bit less loosely coupled), it does make more efficient use of the UI. The search palette is brought up only when it is needed.

Information component

This component style provides details on a single data record. It can be a full, detailed view showing every data element in the record, or it can be a summary showing just the high-level information. It can also target a particular subset of information from the record. In the Lead Manager sample application now available on developerWorks Lotus, there are information components for Companies and Leads. For each of these, there is a Detail component, which contains the original complete Lotus Notes form, and a Summary component, which contains only the basic information.

As with a selection component, you can also have an information component with a minimal on-page display. Upon activation, either programmatically or through the UI, it can then create a pop-up dialog box with the contained information. This conserves the visible screen real estate without compromising functionality. Such pop-up windows are used frequently in the Lead Manager sample.

Launcher component

The launcher component is another contextual domain component. Instead of enhancing the containing application by adding information, it adds functionality. It can be wired to receive data elements from the containing application context and to display options for acting on that information with processes from its own domain. It can present its own UI that lets the user select the action from there, or it can consume an action. This allows another domain-centric component to direct it to take an action similar to the selection component in pop-up mode. Though it's a bit less loosely coupled than might be desired, it makes for a tighter UI. If the component is enabled to work using either direct action or user interaction, then that decision can be left up to the application assembler.

For example, future versions of the Lead Manager application are expected to bridge the sales lead information domain and the mail and instant messaging domains. The mail component exposes an action that lets you compose an email, and when this action is triggered, a new mail memo is started. When you view a sales lead or company information record, you see an option in the UI to send a mail message to the contact for that lead or company. The component does so by firing a wire to the mail component. A similar technique is used to give you the option of starting an instant messaging session.

Because many sales leads start with an email, you can create a launcher component that consumes a number of properties corresponding to the input entries for a new sales lead and exposes a single Create Sales Lead button. When you click the button, context switches to the sales lead application, and the component invokes the UI for creating a new sales lead and populates it with the available information. You can deploy this component in your mail template (or other database that is a relevant starting point) with the To field of the currently selected mail message tied to the Salesperson property of the launcher component and the From field to the Customer property. When you click the Create Sales Lead option while viewing a mail message, the UI for creating a new sales lead displays with the Salesman and Customer fields already filled in.

Calculation component

The purpose of a calculation component is to take one or more values as an input and to produce one or more derived values as output. It can take many different forms from simple arithmetic general calculations to contextual domain lookups. In many circumstances, these components do not have any interactive UI. They can be blank and positioned in unobtrusive areas of the application, or they can be used to display a logo or other branding.

A simple example of an arithmetic component is one that takes a comma-delimited list of values as an input and reports the total as an output. If you then had a list component that could export a column as a list of values, it would be wired to the summation component with the result wired back to another component for display of the total.

Another view of this type of component is as a specialized form of the selection component. Imagine that you have a purchase order application. Purchases over a certain value need manager approval. Part of the purchase submission requires you to fill in your manager's name and email address. You could use a selection component here, but that does not prevent the user from selecting the wrong person for his manager. As an alternative, you could develop a domain-contextual component from your employee database application that receives an action containing an employee's name, and then publishes various details of that employee. The application assembler could then wire the manager's information to the input part of the form. You could even change the form from an input field to a calculated field, thus preventing any user input errors.

Aside from surfacing data, these components can also surface business logic. In the preceding example, suppose that the spending limit was different for each employee and dependent on internal rules, such as region. A calculation component surfaced from the accounting information domain can capture the employee name and return a value of that person's spending limit. The domain-centric component in the purchasing application can then be enabled to check the limits in real time, instead of waiting for it to be flagged by a backend process.

A specialized form of this component works with data type conversion. Defining strong data types for the properties and actions of your components facilitates easier and more accurate application assembly. There may be circumstances, though, in which you want to use generic components that use weakly typed properties and actions. A simple calculation component can consume an action of one type and publish a property with the same data, but be described as a different type. When deployed, these utility components can be made invisible -- or with minimal UI -- and be wired as format converters between two otherwise incompatible components (for example, a component that has an action to consume a zip code and publishes a string containing a city and state).

Aggregation component

Some composite applications may be composed of several pages. Simple application context can be maintained across pages using cross-page wires, which are provided by the platform and supported by the Composite Application Editor. When a page context change is desired, a property is connected to an action on another page by a cross-page wire. The act of firing the property causes the page change and instills the context into the new page. In a more complicated scenario, simply maintaining context with a single item and requiring page transitions to be coupled with context transmission may not be sufficient. Context could involve tracking multiple values, and page transitions can be initiated using other user actions.

An aggregation component is a data warehousing component. It maintains a number of values with symmetrical properties and actions for each value. When a value is set by an action, the corresponding property is fired. Additionally, when the component senses that the page it is on has become visible, it fires all known properties. The key is that the component maintains a single data model for all instances in an application. That means that, when placed on multiple pages, the values set on one page are available for retrieval on another page.

When you use an aggregation component you do not use the normal method of wiring values directly from one component to another. Instead, contextually important values are wired from the property on the first component to the action on the aggregator, and then from the corresponding property on the aggregator to the action in the destination component. In normal operation on a single page, it all proceeds the same. The property change on the first component is propagated through the aggregator to the target component. But during a page transition, the aggregator publishes all known values when the destination page is made visible. In this way, all target component(s) on the destination page are updated along with wires connected from the aggregator.

For example, a sales tracking application needs to track the current company, sales lead, and sale representative. One page may show details on a company, along with a list of the sales representatives for that company. With the sales representative selected, a pop-up window shows details about the sales representative such as phone number and email address. You can choose to create a new lead, which brings you to another page in the composite application. You want the company name and associated sales representative fields to be pre-populated based on the current value for those settings, however, and you can't do this with a simple cross-page wire.

To accomplish this, you introduce an aggregation component on the first page. Components responsible for selecting companies and sales representatives route their wires through the aggregation component. You then put another instance of the same aggregation component on the second page, where you compose a sales lead. You then wire the properties for the current company and sales representative to the corresponding input fields, and when the page switch occurs, the aggregation component detects this, fires the properties, and pre-populates the form.

Other component patterns

In the coming months, a future installment in this article series will discuss detailed information components, edit mode components, summary components, list components, and constrained list components. Although the article will be written from the context of Lotus Notes, these patterns apply to any form of component development.

Layout patterns

This section describes the types of layout patterns.

Radiating dashboard

Composite applications can add relevant information to the context of the process on which you are working; however, you still must be able to devote the majority of your attention to your central activity. One way to balance these two needs is to use a pattern in which the main components required for the main activity for this page occupy the central space. These are usually domain-centric components for viewing, manipulating, or processing individual records and collections of data.

Along the periphery of the screen, other contextual domain components are then arranged, bringing in additional information and context to the central operation. This dashboard can wrap around the left, bottom, right, or even top of the main central area, depending upon your design needs. You can arrange components in folders, which is a useful way of managing screen real estate and of providing a wealth of immediately accessible information -- without taking up large areas of your layout. Similarly, you can manage space by using pop-up components that display minimal UI items until needed.

The wiring of a radiating dashboard page is relatively simple. In general, you may have some data source wires coming from where context is established (for example, user selection, cross-page wires, or an aggregation component) to the main domain-centric components. Further wires radiate from there to the dashboard, providing the keys they need to index the data they display.

Several pages in the Lead Manager application are arranged in this layout, notably the Sales Lead Details and the Company Details (see figure 1). The central area of the screen is occupied by a component detailing the primary record under focus. The dashboard contains a tabbed folder that includes additional information sets relating to the record.

Figure 1. Company details
Company details

When in read-only mode, clicking the Info button brings up pop-up components (see figure 2) that show more information. When in edit mode, the pop-up components become selection components to aid in composition.

Figure 2. Company details with pop-up component
Company details with pop-up component

List page

A list page is designed to show aggregate information on a range of data records. The central area of the page is usually composed with a list or constrained list component, offering a variety of methods of sorting or displaying the list of data records. To supplement this, there are additional information components that summarize collective information on what has been displayed or selected. In a Help Desk application, you can view the call logs of a particular employee in the list component, and an information component can list the average call time for the displayed calls. In an accounting application, you can list transactions on an account, and a summary component can list the total value of the transactions being viewed.

Selection page

The selection page is a variant of a list page. In a list page, aggregate information is viewed to gain understanding about the information set as a whole. In a selection page, the aggregate information can also be viewed as a step toward zooming in on specific data elements. To this end, you can have pages of your UI that exist to guide you to further pages of specific detail on other areas (for example, a radiating dashboard).

Selection pages are often composed of one or more selection components that let the user select criteria by which a data set is viewed by constrained list components. The selection or focus state in the constrained list components may be further projected onto a dashboard of information components to give more details and to further guide the choice. When you've finished making an informed choice about what data you want to view in detail, you activate your selection using, for example, a button click or double left-mouse click that sets the context and switches to the correct page. If the context is simple, this could be through a cross-page wire; if it is not, an aggregation component could be used with a page-switching component to perform this action.

Wiring a selection page is a little more complicated than wiring radiating dashboard pages. Your selection components must be wired to your constrained list, which in turn is wired to the dashboard components. If you have multiple selectors or multiple lists, you may need a number of sets of parallel wires to ensure that the correct data flow occurs when the corresponding control is activated.

NOTE: Take care if you use tabbed folders. For example, if non-tabbed information components are tied to tabbed constrained lists, those lists must broadcast their selection state not only when the selection changes but also upon visibility to ensure that the information components are displaying information pertinent to what is visible.

In the Lead Manager application, the Sales Leads page (see figure 3) is arranged using the Selection Page layout. The Lead Browser component is on the left side of the screen and can display several modes of selection. You can list companies (sorted and selected by revenue size, field of activity, and so on), and you can choose to list leads from a specific company. You can also list your sales personnel and list the leads belonging to individuals. All this feeds into a set of constrained list components on the right side, which displays pending and closed leads that are constrained by the choices made in the lead browser, and further by the state of the lead.

As a selection is updated in these components, information components at the bottom of the screen give a summary of the selected lead and the company owning the selected lead. If you double-click a lead, a cross-page wire transmits the lead information and initiates a page change to a page of details on that lead.

Figure 3. Sales Leads page
Sales Leads page

Record display page

This page is devoted to detailed information on a specific record type. The primary display area shows detailed information on the record type in question. In the dashboard area, additional components are arranged to give supplementary information pertaining to that data record.

In the Lead Manager application, the Company Details screen is arranged in this pattern (see figure 1). The central area of the screen is taken up with a full description of the company record. The dashboard contains a tabbed folder containing components showing the leads for that company, discussions about the company, its corporate Web page, and so on. Clicking the Info buttons brings up pop-up components containing more information (see figure 2).

Record edit page

This page is similar to the record display page except that the record in question is under construction. A dashboard of related data doesn't make sense at this point because the values of the record are incomplete or being created. Instead, the dashboard contains components that aid in the composition of the record.

For example, you may have a selection component indexing your corporate database that is tied to fields requiring an employee to be entered; you may have a view into your recent emails to allow you to compose contact fields; you may have a Web browser for general searching that is instrumented to import the current Web address into appropriate fields.

Depending upon your needs, you may be able to create a page that is both a record display page and a record edit page. This has the advantage of always presenting the record details in a fixed format, but if some information components are relevant only to read-only or edit mode, then you need to ensure that enablement or visibility of them is handled correctly.

Application patterns

This section discusses the application patterns.

Data centric

A data-centric application focuses on the data being managed. You design it by selecting a number of primary data records from the information domains to be covered. List pages are constructed to show aggregate information about collections of the data records. A record display page can be created for each record type covered as well as record edit pages for each record type that can be created or edited. These can be grouped into a tree with the list pages as the branches and the record pages as leaves. You can use the built-in composite application navigator to switch pages, and an aggregation component can maintain context across page transitions. You can also make the leaf pages hidden from navigation by using cross-page wires to activate the pages and establish context.

The Lead Manager sample application is designed primarily according to this pattern. Because you can go into edit mode, you can view Sales Leads, Companies, Contacts, Discussions, and Contracts in lists (for example, selection pages) or individual entities (for example, record display page). Top-level access is given to each of these main areas from which you can drill down to more detail. Cross-linking is also supported, which lets you move from one detailed context to another where appropriate. In the Lead Manager sample, cross-linking is exposed between the distinct application domains of Leads/Companies, Discussions, Contracts, and Contacts.

Process centric

A process-centric application focuses on accomplishing certain tasks rather than specific data. Based on a workflow scenario for an individual employee's role, you create a series of pages in an application that let the employee work through assigned tasks. For example, in an application that manages the creation of advertising collateral, the workflow moves you through the different stages from defining objectives and definitions, to finding an agency, to managing and approving that agency's work, and finally to archiving.

In all cases, you can have the same set of data records. When you are determining objectives and definitions, you can link the campaign record to a discussion area or activity set in which contributors work out what defines the campaign. When in the agency search phase, you may have some components that digest the previously defined objectives into keywords for search, or you may have directory components that list feedback on agencies used previously. When managing the project you may want to use your mail database to track correspondence and to manage sign off. Finally, in the archival stage, you may need to work with aggregate listings of previous campaigns or the assets that were generated by those campaigns.

In the case of process-centric applications, you have sets of pages tailored to the tasks at hand and to the state in the workflow of your primary record. Employees in different roles see only the pages that matter to them, which you achieve in a WebSphere Portal-deployed application by setting permissions on the pages of your composite application. That method is not available in NSF-deployed composite applications; for these, it is simplest to create a different composite application for each role with only the pages they need in it.

In fact, one of the great things about composite applications is that with relatively little work you can devise different applications that are tightly focused on specific areas. By reusing components, you don't have to do a lot of redevelopment and redeployment to gain the advantage of relevant, productivity-enhancing applications.

As currently defined, the Lead Manager sample leverages the data-centric pattern. In addition, you can create a new composite application by reusing many of the components from the Lead Manager sample to leverage the process-centric application pattern -- for example, one that manages the process related to contracts. After a contract for a specific lead is created by the lead owner, it would be reviewed by the legal department, and then by the customer. The composite application can define and aid in this review process.

Aggregation model

An aggregation application is one in which several processes are brought together, but mostly on the glass. The benefits include presenting in one place all the tools the user needs to get the job done. It's a light level of integration with little interoperation, but it's quick and easy to develop and can be the first stage of a plan for interoperation between users' tools. It can be used to roll out some of the benefits of composite applications to a wide range of users as your team learns more about them.

You can solicit feedback from users for suggestions of where interoperation makes sense and may be helpful to their process. This can drive the approach of successive division. You start with a single monolithic component that encapsulates a whole application, and based on user needs, you can break off parts of this component into smaller components that can be surfaced elsewhere.

The aggregation pattern was initially used when the Lead Manager sample was developed. A user interacts with four applications: Leads/Companies, Discussions, Contracts, and Contacts. The benefit of composite applications was first realized by assembling these separate NSF applications into a single multi-page composite application that grouped previously separate applications.


The patterns described in this article are merely a subset of the possible composite application and component patterns. They have been classified by component, layout, and application, and -- depending upon your role -- may not all be applicable. It is beneficial to have an overview of all pattern categories to understand how others could use components and assemble applications.

We have found many of these patterns useful while developing the Lead Manager sample and other composite applications. Some of the patterns may appear obvious, but learning to recognize various patterns of development can help you create applications that have a consistent look and feel and that rely on tested techniques and components.

As you explore the field of composite applications, you may discover other ways of solving the problems you encounter. Take note of them, look for repeated approaches that are successful at solving the same problems, and start creating your own library of patterns.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into IBM collaboration and social software on developerWorks

ArticleTitle=Designing composite applications: Design patterns