What are composite applications and how do they help me? In this three-part series we will introduce the concepts behind a new class of applications called composite applications and explain their need and structure. In this article, we will present a high-level overview of composite applications, the benefit they provide, and how WebSphere Portal supports them. In the next two articles we will explore the WebSphere Portal features that support composite applications in more detail.

The term composite application suggests that there is a class of application whose fundamental construction model is the composition of parts or components. These applications are formed by choosing components from a catalog or palette, placing those components on some design surface, and interconnecting the components to create the behavior desired.

A simple composite application is shown in Figure 1. This hypothetical application allows the user to choose a major or minor application function from a navigator of choices in the upper left area. Each function is imagined to consist of a record set and a detailed view of that record set. In addition, a context-sensitive area for help and advice is provided for each of the major function sets in the application. A typical application might include a layout like the one shown in Figure 1.

There are, of course, many approaches to building this kind of Web application. Many Web application developers might approach the structure of this application as a frame set where clicks in the function selection area trigger JavaScript actions that select a new URL target for the record summary frame and for the instructions frame. Similarly, clicks in the summary area cause a new target selection for the detail area. Developers familiar with the Struts framework might see this as a set of tiles interconnected by the event handling mechanism of the Struts model.

With composite applications, we offer another alternative for the construction of this kind of application. More and more independent software vendors (ISVs) and corporate developers are searching for better ways to reuse and repurpose computing assets. Developers have used techniques like code libraries, object-oriented class libraries, and other mechanisms to achieve reuse; but the advent of portals and the standardization of a component model in portals (the portlet) bring with it a new and more flexible mechanism for composite applications within WebSphere Portal v5.1.

Composite Applications within WebSphere Portal v5.1
The uses of WebSphere Portal are as diverse as the customer base that has adopted this technology. Portal implementations range from simple information sharing to customer relationship portals to corporate performance dashboards, and even advanced applications suites. What has made WebSphere Portal such a flexible and productive platform is its architecture.

WebSphere Portal removes from applications many of the design elements related to infrastructure and GUI support, and allows the developer to focus on creating business functions in his/her application. Support for security, workflow, transcoding, internationalization, navigation, integration, and more are provided by the WebSphere Portal platform while the developer creates portlets or "composite applications" to provide a container of business functionality.

WebSphere Portal also enables segmentation of the development among a team of people that minimizes dependencies on the deployment process. The creation of the page layout, the design of the look and feel, and the creation of the portlet/composite application can all be done independently of the development of the application components. The developer creates the composite application based on business needs. They do not have to worry about look and feel since that is controlled by the "themes" and "skins" that are created independently by the Web designer. Support of navigation, security, and devices is made simpler by WebSphere Portal's infrastructure features.

More and more, we see WebSphere Portal becoming the basis for advanced suites of business function. Figure 2 shows an example of a composite application built by combining portlet components in WebSphere Portal.

In this example, each of the components is a small, independent application. But when composed together on a portal page, these independent applications can work together as one composite application. The drop- down menu in the portlet on the upper left is used to "send" information from the Orders for October portlet to all of the other portlets on the page; each of those portlets responds by displaying information related to information from the orders portal (e.g., the order details or shipping information).

A further example of an advanced suite of business functionality is IBM Workplace, which is a system of composite applications. Each major function is a composition of advanced "portlets" on a portal "page" using capabilities of the portal framework to interact with other components on the page. It provides a suite of collaboration and communication components that can be customized on a page based on a user's preference. IBM Workplace provides support for word processing, spreadsheet support, presentation generator, messaging, team collaboration, collaborative learning, Web content management, and collaborative document management.

Figure 3 shows the IBM Workplace architecture and the layered design. The Workplace infrastructure services/components are provided by WebSphere Portal server, which in turn is built on the infrastructure/middleware services provided by WebSphere application server.

Portlets: The Modular Building Blocks
As illustrated in Figure 3, composite applications within WebSphere Portal are based on portlets. Portlets can be considered to be modules of the composition model since they are each self-contained applications that support multiple states and view modes.

While simply exposing business data and operations through a portlet offers a lot of value, even greater value can be obtained when portlets work together. To create a composite application they must be able to pass data to each other, react to the data, trigger events, and respond to events. Communication and interaction with other composite applications are through defined interfaces such as messaging, event handling, or services. Each portlet can be removed/added from the model or page without impacting other portlets. The foundation of the composition model is the portal infrastructure which provides access to user profile information and remote content, the ability to communicate and trigger other portlets and to participate in windows and action events, store persistent data, and look up credentials.

Now let's explore the different methods that portlets provide to support the composite application model.

The simplest and most basic method to implement is portlet messaging. The portlet messaging API enables a portlet to send a message to either a specific portlet on the same page or all the portlets. In this model, the message is sent through the portlet action listener and received through the portlet's message listener. Of course the biggest limitation of this interface is that it is programmatic and the message logic needs to be explicitly coded in each portlet. Further, any portlets that want to communicate using portlet messaging must have prior compile time knowledge of each other.

Messaging only enables you to send and receive data ? a very limited functionality. The ability to trigger an event based on the data comes with cooperative portlets. Cooperative portlets are portlets that can declare, publish, and share information with each other using the WebSphere Portal property broker. The WebSphere Portal property brokers enable portlets to publish their typed data items, or properties, and to declare actions that they are willing to execute based on the data types published by other portlets.

The portlet that provides a property is called the "source portlet" while the properties that the source portlet publishes are called "output properties". The portlet that receives a property is called the "target portlet" and the properties that are received by the target are called "input properties". With cooperative portlets, the target portlet can provide an action based on the property/data it receives. This greatly enhances and supports our composition model by enabling triggering/workflow models. The whole topic of cooperative portlets as the critical component of WebSphere Portal composition applications will be discussed at length in the next article.

Creating composite applications with portlets still requires best programming practices. For a portlet to be part of the composition model it must have a well thought out set of capabilities, which it exposes as actions on data types. It must also publish data types that are meaningful to users who will be combining portlets in applications. We will discuss these considerations in more depth in the next articles. Portlets used in composite applications should always adhere to a well-patterned framework such as the Model/View/Controller pattern and ensure that the portlet model is not circumvented by linking portlets by passing information through cookies or URLs (work around to perform page-to-page communication). Portlets have to be designed as session-independent, loosely coupled, encapsulated components that use instance and class variables only for read-only values. Your JSPs should have minimal Java and JavaScript. JavaBeans should be used to encapsulate the interface and pass data to the view JSP for rendering.

Enterprise Extensions Support for Composite Applications
In an enterprise environment, composite applications cannot be limited to inter-module/portlet communication. The components of an application must be able to communicate/interact with other applications on other platforms in local or remote locations.

WebSphere Portal provides this support using multiple vehicles. The most basic support can be done using Web services or J2EE connector architecture (JCA). JCA is the J2EE standard architecture to enable integration with enterprise information systems. WebSphere Portal provides JCA connectors for systems such as SAP, PeopleSoft, Oracle, CICS, IMS, Host-on-Demand, etc.

Integration can also be performed with Web services. Using the wizards provided with WebSphere Studio Application Developer, portlets can be developed that are Web service enabled. The Web service wizard enables you to use the UDDI explorer to:

• Search a UDDI registry for a Web service
• Find the service you need
• Find the WSDL file describing the Web service
• Import the WSDL definition, which creates a Java proxy object with the same interface as the object implementing the Web service

But a true distributed enterprise composite application requires more than back-end integration. It needs to seamlessly integrate applications over multiple platforms while executing the applications on their native platforms. WebSphere Portal provides this support with support for Web Services Remote Portlets (WSRP). WSRP enables you to publish your JSR 168?compliant portlets to be used by other portals, or you can use remote portlets from within your own WebSphere Portal instance.

Advantages of Using a Portlet/Page-Based Composition Model
You may ask, "Why should I adhere to this model? There are plenty of models out there, why is this better?"

The portlet/page composition model enables rapid implementation of business functionality and reuse by using out-of-the-box portlets from a public catalog such as the IBM portal and Lotus workplace catalog (http://catalog.lotus.com/wps/portal/portalworkplace), or from a private catalog with custom portlets. It also enables ease of customization (which will be discussed in detail in the third article), and built-in authorization and access control to application features since each major feature is a page and each minor feature might be a portlet on the page. It provides built-in support for styles and branding and, most importantly, the ability to seamlessly bring together application functions from a variety of back end systems. Portlets are fundamentally about providing access to back-end information and transaction systems; composition of application function from these differing back-end systems is a natural for portal-based systems.

Tool Support for WebSphere Portal Composite Applications
Now you agree that this is a good model and that it could provide many benefits to your organization. However, at first glance it looks like it requires low-level Java coding, which can be challenging. Wrong! WebSphere Portal provides many tools to rapidly develop components or portlets that adhere to the composite application model.

At the basic level, you can use WebSphere Studio, which provides a sophisticated portlet development wizard that, within a few clicks, can enable you to develop a native or JSR 168 portlet. Within the native portlet, you can make it Struts compliant, support actions, messaging, Web services, cooperative functionality, JCA, JDBC, etc. After you create it and modify the code to support your functionality, you can debug it in the WebSphere Portal test environment local to WebSphere Studio.

At the next level, you can use the WebSphere Portal Application Integrator (WPAI). This portlet-based tool enables users to create portlets that can access and manipulate data in an enterprise application. Using a wizard, users specify what data should be displayed in your portlet by selecting business objects and fields exposed by the enterprise application. No programming is involved. The tool supports PeopleSoft, Siebel, SAP, and JDBC connections to Oracle or DB2 through WebSphere data sources and Lotus Domino.

The Web clipping portlet enables you to quickly take a Web fragment and make a component out of it. You specify how to obtain the external HTML pages and then identify the area of those pages that should be displayed in the portlet. The resulting Web clipper is stored as an instance of the Web clipper runtime portlet.

Finally, the tool that makes composite applications possible is the portlet wiring tool. Programming cooperative portlets can be challenging and also unnecessary for many of the composite applications. The portlet wiring tool allows you to configure connections, or wires, between portlets on a page that register with the property broker to share information with other portlets. Portlets that are wired together will react based on the relationship established in the portlet wiring tool. Once these portlets are wired, they will react to changes to the other portlet(s) relationship that has been established resulting in a simultaneous update to one or more portlets with minimal user interaction.

Web content is a fundamental building block of any portal. It can be organized into components by the tools exposed in the Lotus Workplace Web Content Management content viewer. These viewers allow their content as well as the navigational method to be displayed in a portal page. They are also designed to allow a navigational tree or menu to be displayed in one portlet on the page to control the content that is rendered on another portlet on the page.

These are just some of the tools to assist the implementation of the composite application models within WebSphere Portal. Improved support will come in WebSphere Portal v5.1. This will be discussed in greater detail in the last article of this series.

What's Next?
Clearly this article presented a high-level discussion on how WebSphere Portal supports the composite application model. In the next articles we will go into more detail (with programming examples and architecture diagrams) on the various methods that are provided in WebSphere Portal v5.1 to support this model.

Specifically, we will focus on cooperative portlets and methods to provide end-user customization. The last article will focus on advanced topics for composite applications such as enhancements in WebSphere Portal v5.1 to support composite applications, performing portal navigation from your components, using labels, using portlets as pop-up windows or "dialogs," enabling "Solo Mode," and forming URL commands to open new windows.

By the time we have finished, you will appreciate the composite application model and how WebSphere Portal's support of it will enable rapid development and deployment of your Internet or intranet applications.

• Figure 1
• Figure 2
• Figure 3