In an earlier entry, I talked through a simple example of how to construct an iWidget for IBM Mashup Center. This afternoon I presented at the WebSphere User Group meeting at IBM Bedfont and was asked about the persistence of state in iWidgets, saving and loading and so on and so it seemed a sensible next step to augment the earlier sample to show how this is done.
ItemSets and attributes
As well as local instance variables inside the Dojo class, the iContext instance provides us with hooks into a standardised structure of instance-specific attributes. These attributes can be defined and set declaratively using the XML descriptor for the iWidget. To extend the earlier example, first modify the XML to contain the following element structure inside the <iw:iwidget> tag:
This will make the pollInterval property we coded earlier as an instance variable into a managed attribute inside an ItemSet. The iWidget specification defines the ItemSet data type (and ManagedItemSet sub-type) to describe a generic key-value pair data store for iWidgets. The iContext exposes to us the attributes as an ItemSet instance, with accompanying accessors to get, set and save changes to the values contained within it.
The next step, therefore, is to wire this logic into our existing Dojo class to exploit this feature. At the top of the onLoad method, add the following line:
This reads the currently saved (or indeed default) value for the given attribute, and populates our instance variable with the value.
Similarly, our routine to save changes to the iWidget now needs to update the attributes and save the changes so they can be persisted with this instance on the page. Add the following lines after the call to set the pollInterval instance variable in the saveParams method:
What you will now discover is when you modify the setting and save the page, when the page is reloaded, you will see the attribute load with the modified value.
I’m a great believer in a simple worked example so rather along the lines of my earlier jump-start for SSL and MQTT, I thought I would compose a similar posting for developing iWidgets to use in the IBM Mashup Center. For a deeper dive on iWidgets, have a look at the iWidget Programming Guide, Specification and also the IBM Mashup Center wiki, all of which are there to support the developer. There are several different examples floating around that show various different aspects of iWidgets, I’m going to show a really simple example that reads an ATOM feed and displays the result.
In simple terms, a widget is a user interface component. With particular regard to mashups, the widget is mechanism by which data feeds are visualised. In IBM Mashup Center, when you choose to add a feed to your workbench, you can specify a particular widget to handle the visualisation. iWidget is an emerging standard for defining these user interface components. This is to promote highly reusable and interoperable components that behave in a common way and expose their services in a consistent fashion. This enables the rapid assembly of business applications from components produced by different developers and providers. IBM Mashup Center’s implementation is based on the Dojo Toolkit and the iWidgets come as a package of some JavaScript code and configuration files all wrapped up in a WAR file for deployment.
The iWidget itself is a combination of a Dojo widget class and an XML definition file.
The iWidget XML definition
The XML definition describes the widget configuration with details such as:
The modes the iWidget supports. Rather like portlets, iWidgets can have a View mode, an Edit mode and a Help mode, the former being the primary presentation logic, the latter two being the interfaces for the user to modify or gain help about the widget respectively.
References to any required resources such as JavaScript files. You should have at least one referenced resource which is the .JS file containing the Dojo widget definition.
Markup content for each of the required modes. This is the basic display logic for the iWidget and can of course contain other Dojo widgets within it.
The name of the Dojo class implementing the programmatic logic for the widget. This is referred to as the iScope in the XML definition.
As you can see, the iWidget supports both View and Edit modes. The View simply shows a value, the Edit mode allows us to modify how often the underlying data feed is polled for updates. You will notice from the JavaScript URL link in the Edit markup how we invoke methods on the underlying Dojo widget instance for the iWidget — iContext.iScope()returns the object reference. I am reusing some of the Mashup Center CSS styles for the Save and Cancel triggers so the widget fits into the overall look and feel.
The iWidget Dojo class
In MVC terms you can regard the Dojo class as a controller for the iWidget — for example orchestrating how it responds to events, reads a feed (i.e. the model), manipulates the UI (i.e. the view) and so on. The class implements lifecycle methods for the iWidget such as:
onLoad() triggered when the iWidget has finished loading.
onview() triggered when the View mode has rendered.
onedit() triggered when the Edit mode has rendered.
iWidgets also have a number of name/value pair attributes for storing configuration and data about the widget. These can be anything of your choosing but the one to remember is feedURL since this is set by the Mashup Center when you choose to use your widget to visualise a particular feed. The following snippet is my onLoad() handler and you will see how we extract the content of feedURL and store it as an instance variable.
There are a few points to note. Firstly, because this is essentially a Dojo widget, we are free to use all the various capabilities of the Dojo Toolkit such as the publish/subscribe framework which I am using here for triggering polls of the ATOM feed. Secondly, you can see how we can interrogate the surroundings of the widget using the iContext instance variable, in this case to generate ourselves a unique identifier to namespace the pub/sub topic and to gain access to the attributes for the instance.
The onview method in my widget is very simple since all I am using it for is as a signal to start polling.
onview: function() {
if (this.feedURL) {
console.info("Feed URL is "+this.feedURL);
this.pollForData();
}
}
The pollForData() method uses standard Dojo xhrGet to retrieve the ATOM feed. Once processing is complete, the routine simply sets a timeout to poll again.
pollForData: function() {
// Request data from the given ATOM feed
var feedURL = this.feedURL;
var context = this;
console.info("Polling for data from "+this.feedURL);
var bindArgs = {
url: feedURL,
error: function(error, ioArg)
{
window.alert("Problem loading feed: "+error);
}
,
load: dojo.hitch(context, function(xmldata, ioArg){
if (xmldata != null ) {
var xmlDoc = null;
if ((xmlDoc = dojox.data.dom.createDocument(xmldata)) === null) {
window.alert("No data returned");
return;
}
// Simply reads the text in the content field of an ATOM entry
var itemNodes = xmlDoc.getElementsByTagName("content");
for (var i = 0; i < itemNodes.length; i++) {
var childNodes = itemNodes[i].childNodes;
for (var j=0;j<childNodes.length;j++) {
// Should only be one <content> node in the ATOM
// but if there are more we will take the last one.
var val = childNodes[j].nodeValue;
this.iContext.getElementById("valueNode").innerHTML = val;
}
}
} else {
window.alert("No data returned by feed URL.");
}
// Now poll again
this.pollTimeout = window.setTimeout("dojo.publish('events/"+this.domID+"/poll',[]);", this.pollInterval*1000);
})
};
dojo.xhrGet(bindArgs);
}
onedit populates the form field on the Edit view so that the correct value is presented to the user. In order to activate changes (or indeed undo changes and return to the view) we also need to add two additional methods of our own.
cancel: function() {
this.iContext.iEvents.fireEvent("onModeChanged",null,{newMode:'view'});
return;
},
saveParams: function () {
this.pollInterval = this.iContext.getElementById("pollInterval").value;
// Restart any polling with the new interval
if (this.feedURL) {
if (this.pollTimeout) {
window.clearTimeout(this.pollTimeout);
}
}
this.iContext.iEvents.fireEvent("onModeChanged",null,{newMode:'view'});
return;
},
onedit: function(){
this.iContext.getElementById("pollInterval").value = this.pollInterval;
}
These methods demonstrate a few key features. The first is how to switch modes from within the widget — in both the cancel() and saveParams() methods we wanted return to the View mode so we fired an event into the surrounding context which the Mashup Center will pick up and cause the widget to switch back from Edit. The second point of note is that the iContext provides a getElementById() method of its own — i.e. return the named DOM element within this specific widget’s context rather than the whole HTML page (which may contain other instances of the same widget).
Here is the full listing for the iWidget class.
dojo.provide("lm.samplewidget");
dojo.declare("lm.samplewidget", [], {
domID: null,
attributes: ["feedURL"],
feedURL: null,
pollInterval: "5",
pollTimeout: null,
onLoad: function(){
this.feedURL = this.iContext.getiWidgetAttributes().getItemValue("feedURL");
console.info("feedURL = "+this.feedURL);
this.domID = "_" + this.iContext.widgetId + "_";
dojo.subscribe ("events/"+this.domID+"/poll", this, "pollForData");
},
onview: function() {
if (this.feedURL) {
console.info("Feed URL is "+this.feedURL);
this.pollForData();
}
},
pollForData: function() {
// Request data from the given ATOM feed
var feedURL = this.feedURL;
var context = this;
console.info("Polling for data from "+this.feedURL);
var bindArgs = {
url: feedURL,
error: function(error, ioArg)
{
window.alert("Problem loading feed: "+error);
},
load: dojo.hitch(context, function(xmldata, ioArg){
if (xmldata != null ) {
var xmlDoc = null;
if ((xmlDoc = dojox.data.dom.createDocument(xmldata)) === null) {
window.alert("No data returned");
return;
}
// Simply reads the text in the content field of an ATOM entry
var itemNodes = xmlDoc.getElementsByTagName("content");
for (var i = 0; i < itemNodes.length; i++) {
var childNodes = itemNodes[i].childNodes;
for (var j=0;j<childNodes.length;j++) {
// Should only be one <content> node in the ATOM
// but if there are more we will take the last one.
var val = childNodes[j].nodeValue;
this.iContext.getElementById("valueNode").innerHTML = val;
}
}
} else {
window.alert("No data returned by feed URL.");
}
// Now poll again
this.pollTimeout = window.setTimeout("dojo.publish('events/"+this.domID+"/poll',[]);", this.pollInterval*1000);
})
};
dojo.xhrGet(bindArgs);
},
cancel: function() {
this.iContext.iEvents.fireEvent("onModeChanged",null,{newMode:'view'});
return;
},
saveParams: function () {
this.pollInterval = this.iContext.getElementById("pollInterval").value;
// Restart any polling with the new interval
if (this.feedURL) {
if (this.pollTimeout) {
window.clearTimeout(this.pollTimeout);
}
}
this.iContext.iEvents.fireEvent("onModeChanged",null,{newMode:'view'});
return;
},
onedit: function(){
this.iContext.getElementById("pollInterval").value = this.pollInterval;
}
});
Here is a sample of the ATOM feed that is consumed by the sample.
I have assembled my iWidget in a WAR file structure with the XML definition and JavaScript in the root.
Two further files are required in the WEB-INF folder, mashup.properties and catalog.xml. The former contains lower-level information about the widget such as a unique identifier and the name of the context root, the latter contains more descriptive information about the iWidget.
<catalog>
<category name="Demo">
<title>
<nls-string lang="en">Demo</nls-string>
</title>
<description>
<nls-string lang="en">Demo Widgets</nls-string>
</description>
<entry id="SampleWidget" unique-name="SampleWidget">
<title>
<nls-string lang="en">Sample Widget</nls-string>
</title>
<description>
<nls-string lang="en">Shows a value read from an ATOM feed.</nls-string>
</description>
<definition>SampleWidget.xml</definition>
<content>http://www.ibm.com</content>
<preview>http://www.ibm.com</preview>
<icon>images/icon.png</icon>
</entry>
</category>
</catalog>
With all these files in place, we simply export the structure (I am using RAD 7.0) to a WAR file and we can now install it into the IBM Mashup Hub for people to use. One thing to note, if you specify an icon in the XML, ensure this is exported as part of your WAR otherwise the WAR will not install correctly into the Mashup Hub.
Using the iWidget
The final step is to try out the iWidget. We shall do this by adding a feed to the Mashup Hub and then in turn to Lotus Mashups specifying our widget as the viewer. As I’ve done previously, I’ve made a short video to show how it is done.
I’ve spoken before about how MQTT and Web 2.0 technologies can be used to extend the reach of the enterprise. When you put those pieces together, powerful possibilities emerge. We can reliably gather data from the remotest parts of the network (e.g. power stations, oil rigs, underground pipelines) and now thanks to mashup technologies rapidly put that data into the hands of users to manage their business. I’ve shown how this is possible by demonstrating how data from MQTT can be received by a messaging server and rapidly consumed into a functioning business application. I’ve uploaded a video to YouTube for posterity (hence the slightly sketchy video quality), but those inside the IBM firewall can obtain a higher quality version if they would like to see it.
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.
Interesting stuff, particularly as it mentions specifically WOA and enterprise mashups, both of which I’ve discussed earlier and described in my observations on 2008. The Green IT piece also resonates with me, as the focus on low power consumption and many of the power monitoring requirements that are starting to emerge all plays to the strengths of the pervasive messaging and edge SOA technologies I’ve described previously. Cloud is also related, especially in terms of how users interact with the cloud and rapidly build what they need — WOA again becomes important.
