Editor's note: This article is the eighth in a series of articles on composite applications being published on developerWorks® Lotus®. See the previous developerWorks articles,"The Lead Manager application in IBM Lotus Notes V8: An Overview," "Designing composite applications: Component design," "Designing composite applications: Design patterns," "Designing composite applications: Unit testing," "Designing composite applications: Writing an Eclipse component for IBM Lotus Notes," "Designing composite applications: IBM Lotus Notes components, " and "Developing composite applications: Composite application assembly, part 1."

About this article series

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 intercomponent 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. For example, one department might 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.

IBM® WebSphere® Portal developers are already familiar with the composite application model. This approach has been extended to IBM Lotus Notes® 8, 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 8 also supports the inclusion of Eclipse components. A composite application can have any combination of Lotus Notes and Eclipse components. These components can be presented together in the same user interface (UI) for on-the-glass integration or, if extended to use the property broker, they can fully interoperate. You can define composite applications using the composite application editor (CAE) or the WebSphere Portal application template editor.

Back to top

Introduction

This article is the second of two articles covering aspects of application assembly. In the first, we discussed what choices an application assembler has in laying out pages and how to navigate between them to improve productivity. Here we consider designing for change, wiring strategies, and how to prototype the layout (because, as we all know, requirements change). You frequently need to add or remove components and, using the techniques described in this article, you'll find it can be easy to incorporate these changes.

Back to top

Prerequisites

This article assumes that you are familiar with composite applications in Lotus Notes, so it can 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 first three articles in this series, cited in the previous editor's note, which provide an overview and explain design patterns. Also, be sure to read "Developing composite applications: Composite application assembly, part 1," which discusses the layout and application patterns in the context of application assembly.

Back to top

Designing for change

One of the advantages of composite applications is that they can be easily modified to suit specific business needs or customized by subject matter experts to fit into their work process. Here are some suggested design methods that can help ensure that your applications are easily modified and adapt well to growth.

Wide horizontal folders

We discussed in Part 1 how the ability to stack components into folders is very powerful. We can place as many components as we need into a small piece of screen real estate. With the ability to maximize tabbed components to the full screen, this method of deployment is also forgiving with respect to accommodating different component layout styles. It is quite easy to add or remove components from tabbed folders without changing the user experience very much; that is, more changes can be made with less user retraining.

Thin vertical columns

This arrangement is not as accommodating as wide horizontal folders with respect to components of varying size. Developing a standard size for narrow-column components, though, can be an effective way to make space for new components that are added later. Vertical columns cannot selectively show single components such as horizontal folders and are best suited for component additions that are best visible at all times.

Cross-domain components

Being able to integrate components from different information domains is the greatest hallmark of composite applications. With careful planning and design, this integration is easy to do, although merging independent efforts or integrating with purchased components is slightly more challenging. One common mistake is to include additional components "just because they are there." A multi-time-zone clock is a cool widget, but if it isn't essential to your user's work, then there is no point in cluttering the UI with it.

Another fairly common problem can arise when different types or namespaces are used, which can prevent you from wiring properties from one set to actions of another set. To avoid the issue, use the type and namespace identifiers to prevent your application assemblers from making connections that are nonsense, and consider developing standards to support the development process going forward.

Sometimes the data can be made available in a variety of types to allow flexibility downstream. Another approach is to create a converter component, which is a component that consumes an action of one type and produces a property of another type. It can be a purely nominal conversion of type (say, from eMailAddress to SametimeID) that leaves the data the same, or it can be a more involved conversion that does a lookup (say, from EmployeeID to eMailAddress).

Back to top

Wiring strategies

Simply placing components on the work surface does not complete a composite application; the components must be wired together. There are usually several ways to wire components together, but not all of them make sense. Here are some examples of good design patterns that can make sense for your application.

As-needed

As-needed wiring is the most general pattern for wiring. Each time you add a component, you wire it into the needed information source. For pages with small numbers of components, this approach is all the structure that you need. When there are few components, properties, and actions, then anything you can wire probably makes sense. As your applications get larger, with more components, pages, and wires, then problems might creep in.

Many actions have cascading effects and cause additional properties to be fired. Some properties fire only when the value changes, others when the input changes. It's also possible to set up infinite or recursive loops. In general with as-needed wiring, use as few wires as possible to make the application work, which leads to fewer problems later as the number of components, pages, and wires increases.

Inside-out

In a typical layout, in which you have a few domain-centric components and several peripheral contextual-domain components, there is often a pattern of wiring that radiates from the central components to the periphery. Context changes due to page switching with a cross-page wire or selection change take place in the central components. As they are initialized, they activate the properties containing the values of the information set they represent. These properties are then wired to peripheral components that use them as the index to the data they show. Occasionally a third tier exists in which the data surfaced by one peripheral component is used by another. In general, however, the data flow is from the inside to the outside, which is easier both for the assembler to wire and the user to understand.

Context preservation

In an application that maintains a complex context, the use of a cross-page wire to communicate a single value to a new page is insufficient to establish the full context. Instead, an aggregation component is used in these cases, as discussed in a previous article in this series, "Designing composite applications: Design patterns." To preserve context across pages, that context must be established in a place that is accessible to various components.

Rather than wiring the property from the broadcasting component directly to the consuming action on a display component, wire the property to the action for that value on the aggregation component. Then wire the property on the aggregation component corresponding to the broadcasting component to the action on the display component. This approach allows the context to be preserved while letting the component be involved in all data transactions.

Example: Suppose the Lead Manager CompanyBrowser component broadcasts a CompanyID property that you want to wire to a CompanyDetail component's showCompany action. You could wire the CompanyID property to a setSelectedCompany action on the aggregation component. The showCompany action on the CompanyDetail component would then get the getSelectedCompany property from the aggregation component.

By using the aggregation component as a clearinghouse for all data exchanges, your application is guaranteed to have the most recent context for all the values that it tracks.

NOTE: In Lotus Notes 8.0.1, a new tool was added to view all the wires in your application at once. You can access it from the normal wiring page by clicking the View All Wires button. The view lets you sort the information based on the page, components, or properties linked, and it's a handy way to understand the overall data flow of an application.

Another enhancement in version 8.0.1 is the ability to relax the type checking by wiring components together using the "Disable strict type checking" button in the wiring view. In normal circumstances, you can wire a property only to an action that has an identical type. Suppose, though, that you acquired components from another company that does not use the same type conventions as your company. You now have the choice, at assembly time, to override the usual type checking and create a wire between a property and an action of different types. Be cautious, however, in how you use this feature: If you pass a value to a component that it was not designed to handle, unexpected errors can occur, so first consult with the component developers, where possible.

Back to top

Prototyping your layout

One of the most exciting benefits of composite applications is that your developers can concentrate on developing components while the subject matter experts can build applications from those components, tailored to meet their needs. As with all application development, the subject matter experts must be able to communicate their needs to the technical component developers.

Another benefit is that components developed by one group for one application can be used by other groups in their applications. To create the most flexible components, however, the original applications might need to be modified. This task can be an arduous and sometimes contentious effort in organizations.

Generally, a prototype or strawman is used to convey the changes and the effort that is required to make the changes. The underlying workflow or process improvements might not be readily visible in a traditional slide-show-based presentation. A model of the application showing some of the clickable actions or placeholders for additional features can help communicate both the need for change and the benefits to everyone involved.

As part of the Lead Manager sample, we created a mockup Eclipse component that presents a variety of user interfaces based on settings made to the advanced properties. Figure 1 shows a mocked-up version of the first page of the Lead Manager sample, in which all of the user interface has been simulated using multiple instances of the mockup component. It is not functional; clicking on the buttons or making selections in the lists does not have any effect on what is displayed. The purpose is to convey a feeling for what the finished application is like. Usage scenarios can be explored, and design issues can be surfaced early in the process.

This mockup component is capable of eight display modes:

• List. The primary area contains a list of items that can emulate a view or other table-driven component.
• Combo. The primary area has a drop-down box of items that can emulate various selection controls.
• Button. The primary area contains a horizontal button bar.
• VButton. The primary area contains a vertical button bar.
• Info. The primary area contains a list of labeled values that can emulate a form in read-only mode.
• Edit. The primary area contains a list of labeled fields that can emulate a form in read-write mode.
• Browser. The primary area contains a browser component set to a specific URL that can emulate a component linking to an internal Web application. Or, if pointed at a static image, it can be used to display a graphical representation of a more complicated component.
• Blank. The primary area is empty and can be used to fine-tune layout.

In addition to what is displayed in the primary area, you can manipulate the name that displays on the tab for the component, an optional title in large font on the top of the component, and the list of action buttons that displays as a horizontal bar along the bottom of the component.

Using this Lead Manager mockup example, you can create your own mockup components incorporating other common UI themes that might be useful in illustrating the composite applications that you design.

Back to top

Conclusion

Creating a composite application that increases productivity is your primary goal, but we all know that applications are not static and must always adapt to the changing needs of business. Obviously, you don't want to redesign the application every time you add new components. Adding to the discussion of page layouts, we suggested ways for you to incorporate the ability for future change into your designs. We also discussed strategies for maintaining consistent wiring on the pages of your application and finished with a simple component for quickly mocking up UI designs for previewing.

Resources

Learn

• Get started with IBM Lotus Notes and Domino V8 technical content.
  
  
• Read the introductory article in this series, "The Lead Manager application in IBM Lotus Notes V8: An overview."
  
  
• Read the developerWorks article, "Designing composite applications: Component design."
  
  
• Read the developerWorks article, "Designing composite applications: Design patterns."
  
  
• Read the developerWorks article, "Designing composite applications: Unit testing."
  
  
• Read the developerWorks article, "Designing composite applications: Writing an Eclipse component for IBM Lotus Notes."
  
  
• Read the developerWorks article, "Designing composite applications: IBM Lotus Notes components."
  
  
• Read the developerWorks article, "Designing composite applications: Composite application assembly, part 1."
  
  
• Read the developerWorks article, "What's new in IBM Lotus Notes and Domino V8."
  
  
• Read the developerWorks article, "Extending the IBM Lotus Notes V8 mail with Eclipse."
  
  
• Read the developerWorks article, "Integrating IBM Lotus Notes data into the Lotus Notes V8 sidebar and toolbar."
  
  
• Read the developerWorks article, "Extending the IBM Lotus Notes V8 sidebar and toolbar."
  
  
• Read the developerWorks article, "Leveraging user context in the IBM Lotus Notes V8 sidebar and toolbar."
  
  
• Get started with IBM Lotus Domino Designer 8 Help.
  
  
• Refer to the developerWorks Lotus composite applications page.
  
  
• Read the "Lotus Notes and Domino 8 Reviewer's Guide."
  
  
• Read about the Eclipse project resources on developerWorks.
  
  

Get products and technologies

• Download a trial of IBM Lotus Domino.
  
  
• Download a trial of IBM Lotus Notes, Domino Designer, and Domino Administrator clients.
  
  

Discuss

• Participate in the discussion forum.
  
  
• Participate in the developerWorks Lotus team blog.
  
  

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• About this article series
• Introduction
• Prerequisites
• Designing for change
• Wiring strategies
• Prototyping your layout
• Conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: Lotus Notes and Domino Administrator
• Demo: Lotus Notes 8 composite applications
• Webcast: Modernization approaches to reduce the total cost for multi-platform enterprise applications
• Briefing: Smarter collaboration with IBM Lotus solutions
• Buy: Lotus Notes and Domino Administrator

My developerWorks community

Dig deeper into Lotus on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers