Sample composite application in Lotus Expeditor 6.2

One of the key features of Lotus Expeditor and Lotus Notes 8.5 is the Composite Applications Environment (CAE). The CAE provides a framework for integration “on the glass” of desktop applications such as native applications, terminal emulation or browser-based applications that are not otherwise easily integrated. This posting shows a very simple example of how to use the tools provided in the Lotus Expeditor 6.2 Client for Desktop to integrate together a set of disparate browser-based applications by way of illustration.

Preparing your environment

There are two possible ways to configure a composite application in the CAE — via extension points in plug-ins created using the Expeditor Toolkit or via GUI tools provided for the Expeditor Desktop Client itself. This sample uses the GUI method to create the composite application.

The GUI tooling is not installed by default with the Expeditor Desktop Client, but is supplied in the install media. You will need to install the required feature from the update site supplied with the Client inside the desktop\updates\platform folder.

Creating a new Composite Application

Once the CAE feature has been installed, you can begin creating your Composite Application using the File menu.

Selecting New Composite Application… will launch a modal dialog box prompting you for a filename to store your Composite Application. In this case we’ve chosen to store the Composite Application under the name Radio 1 Sample.

Having clicked OK we then see a blank Composite Applications page as shown below.

The scenario we are going to create is a very simple one whereby we take two separate web applications from different vendors and integrate data between them within a simple task flow. To begin editing the page, we follow the Actions -> Edit Application menus. We see the editing screen appear.

Configuring containers

The CAE works on the principle that the applications are added into the page using a set of generic containers. These containers provide a common interface around the various different desktop client technologies such that they can ultimately be wired together in a standardised fashion. Since the applications we are integrating are browser based, we will use the Browser Container shown on the Component Palette. Dragging the container onto the page creates a default configuration of the container.

We will modify this default configuration to reflect our application. We will use data contained within the BBC Radio 1 Album Chart to pre-populate a search in Amazon for the name of the top album. I have deliberately chosen these since they are two public sites over which I could not reasonably integrate myself in any other fashion.

We will start by configuring a container for the BBC Radio 1 web site as the source of the data. To start this process we select the Edit Component Properties option from the context menu shown below.

A modal dialog box then appears allowing various settings about the container. We shall first change the title and description to something more meaningful.

Now, we will configure the details of the starting page for the container and also define the data properties that the container will expose to the environment for composition.

You will see that not only have we changed the initialURL property but we have created two further properties albumArtist and albumTitle. In the case of the latter two we have ticked the Wireable box. This tells the CAE that these are data properties on this container that can be integrated (or wired) with other containers.

We now need to specify how and when albumArtist and albumTitle are populated by the container. The CAE has the notion of a landmark with an associated set of events for containers. A landmark indicates a specific logical point in the application. In the case of a web browser, we can specify either a URL or the title of the page in question. For our example we are interested specifically in the Album Chart so we shall set a landmark of the Album Chart page using its URL. We select the Landmarks tab on the dialog, then select URL as the Type of Landmark and finally click the Add Landmark button.

 

For our landmark we can add a set of event handlers associated with it. This tells the CAE what to do when the particular landmark is reached. For a web browser, the most common event is the Content Complete event which is fired when the web page has completed loading. In response to an event we can tell the CAE to interrogate the container to set the data in one of the Wireable properties we defined earlier. In this case we will specify the XPath within the page in the browser of the HTML element containing the data elements we are interested in. A quick and simple way of finding the XPath of an HTML node is to use the Firebug utility for Firefox.

Now we can specify our event handler. We will add two operations for the Content Complete event on the page to copy the values contained in the HTML into the attributes we defined earlier. We click the Add Event button and then Add Operation with Content Complete set as the Event.

The above Operations effectively the following:

• When the page completes loading, publish the value held at the XPath /html/body/div/div[2]/div[2]/div[4]/div/table/tbody/tr[2]/td/table/tbody[2]/tr/td[4]/h4 into the property named albumArtist.
• When the page completes loading, publish the value held at the XPath /html/body/div/div[2]/div[2]/div[4]/div/table/tbody/tr[2]/td/table/tbody[2]/tr/td[4]/h4 into the property named albumTitle.

Note the xpath: prefix indicating to the Browser Container that the meta-data that follows is a valid XPath string. Note that this meta-data is container specific, other containers may have different schemes.

Pressing OK on the dialog box will save the changes and present the modified container in the editor.

Now we need to configure a container for Amazon in the same way. We will now repeat the process above, note that you can drag your new container from the palette onto the page and attach it to a convenient point on the page (e.g. the bottom edge so the screen is split horizontally). This time, we will set the intialURL property to http://www.amazon.co.uk for the Amazon home page and a description and title to that effect. We will also do the following:

1. Add a Wireable property called searchQuery.
2. Create a Title landmark for the page with the title “Amazon.co.uk Music: over two million music items, including chart CDs, back-catalogue, vinyl, cassettes” (omitting the speech marks). Title landmarks are useful when the URLs can vary e.g. some sites use a URL rewriting mechanism for session affinity.
3. Add a Content Complete event with a single Operation to Receive from the searchQuery property and put the value into the XPath //*[@id="twotabsearchtextbox"].

A snapshot of the Browser Container settings for the Amazon container is shown below.

Notice that in this case we choose to Receive (rather than Publish) as we will have incoming data to be plugged into the Amazon page rather than data to be propagated out as we had before. We now have two containers configured on our page.

Wiring the containers into a composite

We now need to wire the two containers together. Note that at this point we will no longer be talking about the specifics of how the containers give and receive data (i.e. no more talk of XPaths). This is an important feature of the CAE since it means that relatively few technical skills are required to assemble a set of containers once they have been configured. At the wiring level, the user deals only in terms of properties and wires.

From the context menu shown above we select the Wiring menu option. We then see the Wiring view showing the two containers we have configured.

 

Notice how for each container we configured earlier that each Wireable property is shown on the graphical representation of the container.

What we want to do is wire the albumArtist property into the searchQuery such that when the events we configured for the container fire, the data will flow along the wire from the BBC Radio 1 Charts container into the Amazon (UK) container. We do this simply by clicking and dragging the albumArtist property and releasing it over the searchQuery property. A blue arrow appears whilst the drag/drop is in progress, once the drop is complete we see the following:

We complete our composite application by clicking OK on the Wiring screen, then the File -> Save and Close menu options on the editor screen to save the changes to the Composite Application. When we return to the Expeditor desktop, we now see a tab with our Composite Application contained within it.

Testing the application

We are now ready to test the application. To show the integration working, we simply navigate the BBC page to the album chart using the link within the page to http://www.bbc.co.uk/radio1/chart/albums.shtml and then click through on Amazon to the Music Department. We should see the following screens.

As you can see when we click onto the Music Department, the title of the top album in the Radio 1 chart has been extracted from the HTML and populated into the input field on the Amazon page. Our composite application is complete and working.

Making technology choices for client applications

When developing the end user aspect of a client/server SOA solution, there are a variety of possibilities in terms of the technology choice for the client application. The possibilities represent a spectrum of choices from browser based applications on the one hand to natively installed “fat” client applications. At one end, the evolution of Web 2.0 technologies and patterns for the browser environment means rich and aesthetically pleasing end-user applications can be delivered through the ubiquitous web channel. On the other hand, there are cases when the browser environment and web delivery model does not fully meet the application requirements and a richer client environment is required. As always there are several “shades of grey” available in between and each project will have its own specific requirements.

I’ve been asked a few times by customers as to how one determines the most appropriate approach, particularly those contemplating making the transition from traditional (“Web 1.0″) applications into the RIA world. I’ve attempted to distil down in this posting some of the high level considerations that I typically give in response when I am posed this question.

As an IBMer working in this space you’ll see that in some cases I’ve articulated the thinking in terms of IBM’s recommended products and technologies in this space, particularly

• The Dojo Toolkit for building rich, browser-based applications (RIAs).
• Lotus Expeditor for building and managing rich client desktop and mobile applications.

Application “posture”

The nature of the application concerned provides an indicator as to the type of client technology required to construct it. “Posture” is a term coined by Alan Cooper in his book “About Face” which is used to describe the behaviour of an application in terms of their interaction with the user. Cooper defines three postures to describe interactive applications: sovereign, transient and daemonic. Each posture has different requirements in terms of the fidelity of the user interface technology. Sovereign and transient applications are the most commonly applicable to business applications.

Sovereign applications are those that will monopolise the user’s focus such as a word processor or banking teller application. Speed and power are typically of the essence and users of sovereign applications become expert users quickly due to the sheer amount of time spent with the application. User interface short cuts using the keyboard are a common feature. The sovereign application will typically expect to benefit from the full range of user interface services available on the machine. For this reason, rich client technologies (such as Expeditor) that are installed natively (i.e. tighter integration with the operating system and hardware) are often the most appropriate choice for this posture. The richness now possible in the browser with AJAX frameworks (such as Dojo) and other RIA technologies are starting to blur this boundary, however, though the web browser itself will still ultimately restrain the application’s access available to the native UI.

By contrast, transient applications are those that come and go and respond to a particular request and service a particular set of constrained goals. Good examples of this are a consumer banking or insurance quotation application. Typically users visit less often and as such ease of use and instruction is of higher concern than speed. From a posture perspective, the browser comes into contention due to the lesser need for full control over the desktop, reach and easy-to-use presentation and controls.

Connectivity available to the application

Connectivity is one of the most important considerations for the client technology choice for the application. Will the user be permanently connected to a network or does the nature of their role mean that they will be connected only sometimes when using the application?

Whilst AJAX techniques changed the architecture and model of interaction between the client and server (i.e. more functionality is loaded for a given single page request), web applications remain inherently a “connected” technology. A typical operating environment of a desktop PC connected via a high-speed LAN such as wired Ethernet or Wifi is a sound infrastructure platform for a web-delivered application. Corporate intranets are a prime example of this type of application.

When the connectivity model for the application is “sometimes connected”, the application must function irrespective of whether a network is available. This requires a richer environment to insulate the application from the network breakage. For example, we might want to reliably batch up requests to the server until such a time as the network is available again. A good example of such an application is a mobile sales representative in the field collecting orders from customers where typically they are not connected to a network or are reliant on patchy network coverage. In this scenario, the representative typically collects the orders during the day and synchronises with the back-office in the evening when connected again. Web browsers do not as standard offer sufficiently rich capabilities to support this mode of operation.  For example, without the addition of additional plug-ins, network connectivity is limited to HTTP and data cannot easily be persisted whilst working offline. Rich client technologies like Expeditor can store data to disk or in a relational database and leverage more sophisticated connectivity technologies to reliably store and forward the data to the enterprise when connected.

Access to the operating system and hardware

Closely linked to the question of connectivity is the requirement to be able to communicate with resources native to the installation environment. Files on the local file system are a simple example, Windows registry entries are another. Another common scenario is accessing specialised devices connected to the desktop machine, for example a chip and PIN reader in a banking scenario.

Where access to the native file system or devices is required, the browser becomes an increasingly problematic environment. Signed Java Applets are intended to allow increased access to native resources but can be complex to install and configure correctly, particularly at enterprise scale due to the variety of JVM and browser combinations. As we have already noted, the primary I/O mechanism of a web browser is HTTP which is well suited to consuming documents and feeds but less well suited for more complex resources such as proprietary hardware device drivers. Furthermore the browser is restricted by the same-domain security restriction that further limits its capabilities even with HTTP. A browser plug-in would be required to extend the browser to provide richer I/O support which is not only a relatively complex task but also adds dependencies on both the browser brands and operating systems. Rich clients typically offer better access to more primitive interfaces of the native platform, devices and so on through richer programming environments such as Java. In the case of Expeditor the benefits of Java are further augmented by a standardised (OSGi-based) plug-in architecture facilitating the development and reuse of components.

Management model

A key driver in terms of the business case for the client technology solution is the target infrastructure for the application, and its associated cost to the business. The requirements for provisioning the application are a factor central in the cost/benefits analysis of the solution.

Natively installed applications generally require more time and supporting IT skills, both of which naturally increase the cost of ownership. Native applications offer the richest functionality but add a tight dependency on the operating system and hardware. Furthermore, some aspect of installation is always required which in an enterprise scenario will often require IT support and management along with the associated costs that implies.

Browser-based applications have a broader reach due to the higher level of abstraction of the application tier from the operating system. Since the mid-1990s the presence of a web browser can be taken for granted on every desktop and as such web applications represent what is known as the “zero footprint” option since they require no native installation process at the client. The browser simply requests the application via a URL and the latest version of the application is downloaded on demand simply by virtue of  being there when the request was made. There is little or no associated cost of deployment from the client perspective when introducing new function as it will be provisioned the next time the application is requested.

There is, however, an approach that blends the richness of a native application with the lowered cost of ownership of a centralised management model. Expeditor provides what is known as a managed client for desktop PCs and mobile devices. The native installation of the Expeditor client installs a base application container into which the functional components of an application can then be deployed and managed from a central server. In this way new applications or updates to existing business function can be provisioned without the need for intervention by the end user or IT support.

The legacy on the desktop

When considering deployment infrastructure we also need to consider any legacy applications that a client solution needs to accommodate. In a “greenfield” environment (i.e. where we are developing a new solution from scratch) it is very often the case that a homogeneous technology platform can be adopted, such as a browser-based web portal or such like. When there are existing applications that are too costly to replace (i.e. “brownfield”) a solution is required to accommodate the legacy applications alongside new functionality and provide a transition path into a common technology platform.

If there are existing applications to accommodate that are delivered via web-based channels, then a web portal can be deployed to aggregate the applications together within a single browser application. Depending on how the original applications are constructed some functional integration can be achieved through the portal infrastructure. At the very least the applications can be functionally grouped within the user interface according to their function to help streamline the task flow. This allows some degree of integration for the web channel without a “rip and replace” of the legacy applications.

In many scenarios, however, the incumbent applications are implemented in a variety of technologies e.g. web, native applications, terminal sessions that cannot easily be aggregated with a purely browser-based portal. Consider a call centre where often a user task involves interacting with a number of individually installed desktop applications, often due to the organic growth of the desktop platform with point application choices over a period of time. In such environments, Lotus Expeditor provides support for efficient composition of a heterogeneous desktop through its Composite Applications Environment (CAE). In CAE, applications built using different technologies can be integrated at-the-glass in a similar fashion to a portal (or indeed mashup) using a simple wiring model and GUI tools – i.e. integrating data from one application with that of another without the need for code or ripping and replacing the applications. This can bring not only the benefits of application integration in terms of time and cost savings, but also provides a strategy to transition the legacy applications over time onto a common technology base whilst the enterprise can protect its investment in the existing applications.

Communication with existing business services

In an SOA the client application must be able to invoke the underlying services to fulfil the business function. The popularity of AJAX applications in the web browser environment has seen a growth in popularity of simple and lightweight service endpoints exposed using HTTP and REST. This style of SOA (known as Web-Oriented Architecture or WOA) is well suited for the presentation of information in the web browser and for invocation of logic in the application server where a particularly high quality of service between client and server is not required (i.e. HTTP is good enough). I’ve previously discussed WOA in an earlier posting and the value it can add to SOA.

In some cases, however, applications may have higher quality of service requirements for other more complex protocols to underpin the business function. For example a retail point of sale application might use reliable messaging via a JMS messaging server to ensure that details of a transaction are delivered to a payment processing service. Typically such providers require a richer programming runtime than the browser such as Java or C. Similarly the application may require direct transactional access to a database using JDBC. Again, Expeditor in its various flavours provides such an environment though its support for Java and enterprise standards such as JMS and JDBC, and connectivity into enterprise middleware and database servers.

Availability of skills within the enterprise

The pragmatics of delivery have significant impact not only on the technology choice but also the associated costs and benefits of the solution. For example, selection of an unfamiliar technology platform will require the development or acquisition of new skills. In some cases the requirements of the application may dictate a particular technology choice and the benefit to the business of the solution will be sufficiently significant that it outweighs this cost. By the same token, the ability to leverage skills already available within the organisation may reduce the associated cost of development and ownership to such a degree that the benefits become more compelling in a borderline business case.

HTML skills have become widely available and are common entries on the resumes of application developers. In this respect the development of HTML-based applications for browser environments is an attractive proposition financially when planning for the development and maintenance of the solution. HTML and Javascript are open, supported and widely accepted technologies for the presentation tier of an application. Their adoption in an application represents less of a strategic risk to the enterprise since they are not tightly coupling the application to a native platform or proprietary programming model. Furthermore, proprietary technologies (such as Flash) can be accommodated within it. Toolkits such as Dojo provide comprehensive programming models and rich widget libraries as accelerators to shorten time to value in developing the application.

When a richer client platform is required, the provision of a web container inside the Lotus Expeditor client provides the capability to exploit the prevalent skills and short time to value of the browser environment in conjunction with the additional capabilities of the rich client. The example below is from a scenario where desktop client applications in a retail branch connect to a local micro broker in an edge SOA solution.

Web 2.0 – my experiences in 2008

I have been reflecting recently on this year and the various different projects I have worked on. What is interesting is that in the last 18 months of working fairly and squarely in the “Web 2.0″ space, the bits of Web 2.0 that I’ve seen most interest in is around the architectures that underpin modern web applications rather than purely the social aspects of it. In particular the following themes seem to resonate:

Aggregation of data in the form of feeds on the client.

Sounds like plain old common sense but in the “Web 1.0″ days, mingling of presentation and data channeled many an application down into a dead-end silo, despite the best intentions of things like Struts. The flexibility to bind applications together in a way that isn’t necessarily intrusive to the application server but doesn’t require embracing the complexities of WS-* is something people see value in because it means that future change will potentially cost them less. Further more, aggregating feeds on the client means they are not necessarily forced to migrate a whole load of applications to different application server technology just to integrate with a new vendor. Again a cost consideration.

Well defined widgets and loosely-coupled browser component models.

Again, flexibility facilitates change and therefore potentially reduces costs. Frameworks like Dojo and the OpenAjax Hub mean that a modern web GUI can be constructed of well defined components with loose linkages between them — we design with change in mind at the outset rather than consider change to be some other project in the future. All of these things are resonating.

The browser as a platform and software-as-a-service

Sounds obvious but it’s worth stating — people where possible want to commoditise the desktop (or indeed mobile) platform so they aren’t locked in to one vendor’s view of the world and the hardware is increasingly disposable. Any modern operating system comes with a browser supplied and web applications can be centrally managed — no IT skills required to deploy the application, it just arrives on demand via a URL. Google clearly recognise this with Chrome which reveals a fairly clear strategy of creating a robust and performant browser that increasingly offers some of the qualities of service we’d associate with a desktop OS (witness their focus on better thread management for starters). For many organisations managing multiple native installers and the various things that can go wrong is a pain they are keen to lose.

“Mashups” and composite applications

People and organisations I have spoken to and with others about are starting to see the value that mashups can bring to their organisation, particularly in terms of making use of (note I avoided the word “leveraging”) data they already have in the enterprise without the need for deep IT skills to help them realise that aim. This does drive a slightly different thought process when discussing the merits of an architecture based on separation of concerns between data (i.e. feeds) and rendering widgets since adopting such an architecture facilitates a move towards mashups in the future.

I’ve included under the mashup banner the term “composite applications”. Now many organisations already have at least some legacy line of business applications that they cannot replace quickly, in terms of the sheer cost and risk of “rip and replace” and the skills and investment they have already made. This is where products like Lotus Expeditor become compelling because it allows you to aggregate browser-delivered content in its Composite Applications Environment (CAE) whilst maintaining a centrally-managed model for the client platform.  Effectively what is created is a richer client “mashup” environment, where heterogeneous desktop technologies can be wired together with browser content and Java/native programming logic. This also provides a pathway to transition over time to a thinner client solution if required as the rich client components are migrated onto a browser-delivered model. Sounds a bit boring I know but the reality is that it’s a “brown-field” world out there.

Anyway, those are the things that I personally have seen and heard working in this space. Part of the reason for my recording them for posterity here is to review this next year and see how things have changed, especially as budgets are inevitably pressurised even further in the current economic climate.