In the first article of our three part series, we introduced you to the composite application model and how WebSphere Portal supports it. A composite application is a class of application whose fundamental construction model is the composition of parts or components. It is 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.

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.

In the second article, we showed how to make composite programs with co-operative portlets, both programmatically and with the Portlet Wiring Tool. We showed how easy it was to add a third party portlet on to composite portlet and how IBM was committed to this technology.

In the last article of this series, we will dwell into some advance techniques that will highlight the power of composite applications.

Filters and Adaptors
Composite applications are made up of loosely coupled portlets or co-operative portlets. However sometimes output or input properties change and you will want to integrate the portlets without having to touch the original source code. You may not even be able to touch the source code since you don't own it.

This is where Filters/Adaptor portlets come in. The Filter/Adapter portlet massages an output property of a co-operative portlet such that it is recognizable by the input property of another co-operative portlet. You place the Filter/Adaptor portlet in a 1 pixel container on a Portlet Page (which makes it appear invisible) and wire the source portlet to the Filter/Adapter portlet and then wire the Filter/Adaptor portlet to the target portlet.

So let's show you how to do it! We are going to use the property broker shipping example that comes with WebSphere Portal. The source code can be found in [WP-HOME]/installableApps. The shipping example consists of five C2A portlets. The first portlet, Orders, displays order information for a given month and provides information on order id, customer id, and status. To find more detail information, click on the icon associated with the field you are interested in.

Now for our example (and for simplicity sake), we are going to pretend that the customer 2867377 has merged with customer 3542877 and has been assigned its customer number. So rather then recoding the target or the source portlet or change the database, we are going to create a portlet that will intercept the value transmitted by the source portlet, massage the value, and re-transmit it to the target portlet. Basically this is a poor man's WebSphere Message Broker.

No changes have to be made to the original target and source portlets (order and customer detail) however for clarity sake the type associated with customer id should be made for both the input and output. So the input and output of Customer Id type associated with the order portlet and the composite adapter is compositeType while the output and input associated with composite adapter and order portlet is CompositeType2. This prevents multiple menu action selections appearing on the C2A menu drop of the original source portlet (causing mass confusion on the user).

The following is the declarative code for the WSDL;

?xml version="1.0" encoding="UTF-8"?>
<definitions name="CompositeportletadapterPortlet_Service"
   targetNamespace="http://www.ibm.com/wps/c2a/examples/shipping"
   xmlns="http://schemas.xmlsoap.org/wsdl/"
   xmlns:portlet="http://www.ibm.com/wps/c2a"
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
   xmlns:tns="http://www.ibm.com/wps/c2a/examples/shipping"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<types>
   <xsd:schema
   targetNamespace="http://www.ibm.com/wps/c2a/examples/shipping">
    <xsd:simpleType name="compositeType">
      <xsd:restriction base="xsd:string" />
    </xsd:simpleType>
    <xsd:simpleType name="compositeType2">
      <xsd:restriction base="xsd:string" />
    </xsd:simpleType>
   </xsd:schema>
</types>

   <message name="Compositeportletadapterportlet_Request">
     <part name="Compositeportletadapterportlet_RequestPart"
     type="tns:compositeType" />
   </message>

   <message name="Compositeportletadapterportlet_Response">
     <part name="Compositeportletadapterportlet_ResponsePart"
     type="tns:compositeType2" />
   </message>

   <portType name="Compositeportletadapterportlet_Service">
     <operation name="new_customer_ID">
       <input message="tns:Compositeportletadapterportlet_Request" />
       <output message="tns:Compositeportletadapterportlet_Response" />
     </operation>
   </portType>

   <binding name="Compositeportletadapterportlet_Binding"
   type="tns:Compositeportletadapterportlet_Service">
     <portlet:binding />
     <operation name="new_customer_ID">
       <portlet:action name="map_customer_id"
       caption="map.customer.id" type="simple">
       </portlet:action>
       <input>
   <portlet:param name="customerId"
   partname="Compositeportletadapterportlet_RequestPart"
   caption="customer.id" description="input.customer.id" />
     </input>
     <output>
   <portlet:param name="customerIdOutput"
   partname="Compositeportletadapterportlet_ResponsePart"
   description="input.customer.id" boundTo="session" />
      </output>
     </operation>
   </binding>

   </definitions>