Composite applications

Composite applications are applications that consist of two or more components that may have been independently developed, working together to perform tasks that none of the member applications could perform by itself. Each component publishes and consumes messages from other components, and performs actions based upon user interaction or information received from other components. Support for composite applications is one of the central points for Notes/Domino 8. Composite applications in Notes 8 can wire together multiple components from Notes applications, Lotus Component Designer applications, and Eclipse into a single application context for the end user.

Composite applications, whether they are based on Notes/Domino 8, Web Sphere Portal, or Lotus Expeditor, are the frontend or user interface to an enterprise’s SOA strategy. They, in effect, consume the services that are offered by the composite architectures put in place to support SOA.

An example of a composite application would be a simple customer relationship management application. This application needs to display a list of accounts, opportunities, and contacts to end users.

The accounts component should display accounts owned by the end user. When the end user selects an account in the account component, the opportunities for that account should be displayed in the opportunities component, and all of the contacts for the first opportunity should be displayed in the contacts component.

In the application described, the components are “communicating” with each other by publishing and consuming properties via a property broker. When the user clicks on an account, the account component publishes the accountkey property to the property broker. The opportunities component has been written to “listen” for the accountkey property to be published, and when it is, it performs a lookup into a data store, pulling back all the specific opportunities for the published account key. Once it has displayed all of the opportunities for the account, it selects the first opportunity for display and then publishes the opportunitykey property to the property broker. The contacts component then performs a lookup to display all of the contacts for the opportunity.

When the user selects a different opportunity, the opportunity component again publishes an opportunitykey property and the contacts component receives this new opportunitykey property and displays the correct contacts for the selected opportunity

Using component applications, developers can respond quickly to requests from the line of business for functionality changes. For example, in the case of the customer relationship management application described, the line of business may decide to purchase a telephony component to dial the phone and log all phone calls made. The developers of the application would need to simply modify the contact component to publish the phone number of a contact with a name that the new telephony component listens for and the call could be made on behalf of the user.

In addition to being used within the customer relationship management application, the components developed could be put together with other components to form entirely different applications. Each component already understands what data it needs to publish and consume to perform its actions, and contains the code to perform those specific actions on backend systems. The reuse of the components will save the developers and the organization time whenever they are reused.

Composite applications also require a new programming model for Notes/Domino 8. This model mirrors the model within WebSphere Portal 6, in that multiple components are aggregated into a single UI with the property broker acting as the “glue” that allows the various components to interact and share data, even if the components are from different systems. This programming model is something new in Notes 8 and required some changes to Domino Designer 8.

As a side note, the new programming model of composite applications will most probably bring its own set of problems. For example, what happens in a composite application when one of the components fails? In this “composite crash” situation, what does the composite application need to do in order to recover?

Additionally, from an infrastructure point of view, composite applications will only be as available as their weakest component. What good would a reservations system, implemented with many components, be if one of the components were not hosted by a highly available infrastructure, while the others were? We see these sorts of issues being dealt with currently by customers venturing into the composite world via SOAs.

There are two main categories of change for development related to composite applications in Notes/Domino 8 application design and programming. We will look at both of them in the following sections.

Application design

In order to allow your Notes or Domino application to participate within a composite application, you must first decide which design elements need to be accessible to other components. To make these components available to other components within your composite application, they are specified within a Web Services Description Language (WSDL) file. The composite application property broker then uses this WSDL file as a map into your application and its published properties and actions.

To allow this mapping to occur, the Composite Application Editor is used. Without making changes to legacy Notes/Domino application functionality, the Composite Application Editor can be used to surface the elements of the application such as forms, views, documents, and other Notes elements to the composite application.

Another element of composite application design is deciding where the application components will reside. Composite applications can be hosted within a local NSF file on a Notes client, on a Domino 8 application server, in the WebSphere Portal, or in Lotus Expeditor. The Notes/Domino application components are created with the Composite Application Editor, while WebSphere Portal composite applications can be created with the Composite Application Editor or the Portal Application Template Editor.

Programming

As mentioned earlier, the addition of composite applications to the development strategy for Notes/Domino 8 required some changes and additions to the existing programming model.

Within a composite application, the components must be able to interact even if they were defined with different tools and technologies. Some components may even be stored within different database technologies. One component may be NSF-based while another may be stored within a relational database store. The components need a standardized way to define the properties and actions that they support, so that an application developer can wire them together into a composite application. The standard way to define these properties and actions is via a WSDL file.

Let’s take a quick look at properties, actions, and wires

Properties

Component properties are the data items that a given component produces. They are either input properties (consumed by the component) or output (produced by the component) properties. Each property is assigned a data type, which is based on the WC3 primitive data types. These include String, Boolean, decimal, time, and date. The primitive data types can also be utilized to build new data types. For example, within Notes 8, some new data types for components will be available that map to common data available within the mail, calendar, and contacts applications. Some of these new data types are listed in the following table:

Actions

Actions are the logic that is used to consume a property. For example, a component may implement an action that sends an e-mail when it receives a mailTo type property from another component. The code within the component that sends the e-mail based on the information consumed from the property is the action for the component. Components can obviously contain multiple actions depending on the business logic required for the component.

It is easy to confuse a web services action with a Notes action. The web services action is a name in a WSDL file that represents functionality that will consume a property. Notes actions can be coupled with a web services action so that the Notes action gets called to consume a property. The LotusScript in the Notes action can then implement code to act on the property.

The following screenshot shows a Notes action in the Notes 8 mail template that is coupled with a web services action, NewMemoUsingMailtoURL. You can see that in the code, the LotusScript is using a property broker to gain access to the property:

Wires

Wires are the construct by which components interact within a composite application. A wire is simply a programmatic definition of which components talk to each other. The components must share common properties and then produce and consume them via actions. More simply put, wires connect properties to actions.

For example, an application developer could wire together a contact list component with an e-mail component. When the user selects a contact from the contact list, the contact list component would produce and publish a mailTo type property, which could then be consumed by the e-mail component. The e-mail component would consume the published mailTo property and compose an e-mail using the data contained within the property.

The following screenshot shows the components available within the Notes 8 mail template that are available for use in other component applications as well, shown from the Component Palette within the new Composite Application Editor: