Composite Applications in WebSphere Portal
Overview
Composite applications are a class of application whose fundamental construction model is the composition of parts or components. Applications are formed by choosing components from a catalog or palette. Placing those components on some design surface. Interconnecting the components to create the behavior desired.
Object oriented mania has waned, and the age of services is upon us. Object oriented programming is notoriously brittle when you try to combine components. It is conceptually difficult to do functional composition programming with objects.
With service oriented programming, you think about what kinds of services kind be brought into the equation. We start with an elemental behavior, and then supplement that initial behavior with other behaviors. For example, the first element would be to look up a customer record. We could compose another service that would then look up customer record details.
Portal provides a "late binding" of the application components. The binding is not complete until is page is aggregated. Allows different application compositions depending on users roles or permissions.
Makes possible end-user enhancement and extension of applications. WebSphere Portal page assembly provides ways for the user to compose portions of their own pages. Helper applications can be added to pages by users to blend together just the right capabilities for their business purpose.
Here is 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).
Composite applications within WebSphere Portal are based on portlets, which can be considered to be modules of the composition model since they are each self-contained applications that support multiple states and view modes.
To create a composite application portlets 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.
Portlet Messaging
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.
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.
Create 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.
Brokered
Allows independently developed portlets to exchange information. Portlets register their intent to work with the broker.
Cooperative Portlets
Two related communication paradims are supported:
- Click-to-Action - Constrols for triggering interactions can be dynamically generated.
- Wired Portlets - Behaviors of multiple portlets can be integrated, through configuration rather than programming.
Cooperative Portlets are associated with Properties and Actions. A Properthy is an exchangeable data item, which the portlet can produce or consume. An Action which is logic that can be executed to process a Property, or logic which after execution produces Properties. Properties and Actions are intrinsic to a portlet, and are defined by the portlet developer. Multiple instances of the portlet may be created after deployment but all share the same Action/Property set.
Wires connect a specific source portlet instance with a specific target portlet instancdes. Does not connect all instances of the portlets. Not created by the developer, establsihed after portlets are instantiated.
The property broker is a Portal runtime entity supporting portlet cooperation. Maintains a registry in the portal database of Portlet Properties, Actions, Parameters, and Wires. At deployment time, processes portlets to register their Property/Action information. At runtime, examines registered Property/Action/Wire information and facilitates information exchange between portlets.
Think of each portlet as being a cell in a spreadsheet.
Click-to-Action
A click-to-action portlet can place a clickable control in its markup which is associated with a Property.
You can use cooperative portlets to create clickable maps.
You can use the Portlet Wiring Tool to create cooperative portlets. Much easier than programming.
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, 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.
Workplace Web Content Management is a trademark of the IBM Corporation in the United States, other countries, or both.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.