Thoughts on enterprise IT

Dustin Amrhein

Subscribe to Dustin Amrhein: eMailAlertsEmail Alerts
Get Dustin Amrhein: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: IBM Journal, Mobile Enterprise Application Platforms, Mergers & Acquisitions on Ulitzer, HTML5, HTML5 Mobile

Article

IBM Acquires Worklight

A brief look at the Worklight solution

How about we start this post off with some facts?

- Mobile data traffic exceeded voice traffic in 2010 (Wireless Industry News, August 26, 2010)

- Shipments of smartphones exceeded the shipment of PCs for the first time in 2011 (2011 Economist)

- Ten billion mobile connected devices are expected to be in use by 2020 (2011 Economist)

- 74% of surveyed CIOs indicated mobile capabilities were a top investment priority over the next three to five years (2011 IBM Global CIO Study)

As you may surmise from the above, the mobile computing space is hot. Companies are already doing mobile, and many have already or are looking to define their three to five year strategy. In that respect, this month's acquisition of Worklight by my employer, IBM, is not at all surprising. Let's take a little closer look at exactly what Worklight is and what it delivers.

A quick perusal of existing Worklight material provides us with the simplest explanation of the solution:

Worklight is an open, complete and advanced mobile application platform for HTML5, hybrid and native apps.

While I grant you that the above statement sounds like something right out of a product brochure that does not mean it is not accurate. We need to go a bit deeper than that though, and the best place to start is with an architectural diagram of the Worklight solution:

As you can see, the Worklight solution is made up of four primary components. These include the Worklight Studio, Worklight Server, Device Runtime, and Worklight Console. Let's tackle each one of these in turn, starting with the Worklight Studio.

The Worklight Studio is first and foremost and Eclipse-based IDE. When installed, it augments your Eclipse runtime with a powerful set of tools focused on helping you to develop every aspect of your mobile enterprise applications. Worklight Studio embraces open web technology such as HTML5, CSS3, and JavaScript by proffering a model where developers start with a common, shared code base for their application. From that common code base, Worklight Studio makes it easy to create subcomponents of the main application that are optimized for specific platforms. This makes it quite simple to start with a common code base and build a deployable application for Android, Blackberry, iPhone, WinPhone, and more.

All of this is not to say that you cannot create rich mobile applications that access native device functionality. Worklight Studio includes the PhoneGap library that provides a device-agnostic JavaScript bridge to native device functionality such as the camera, accelerometer, and geolocation facilities. Furthermore, Worklight Studio provides native device SDK integration as well as the ability to develop applications that freely move between native and non-native screens.

Next up is the Worklight Server. First and foremost, the Worklight Server provides a central distribution point for your mobile applications. You deploy your mobile application assets to the Worklight Server, and you have a central point where you can manage application versions, push direct application updates, and handle application versioning, up to and including disabling old versions. Beyond these capabilities, the Worklight Server facilitates many mobile application security aspects. It provides the means to enforce secure connectivity from client devices, and it is capable of checking the authenticity of applications with which it is communicating.

There are a few other capabilities worth pointing out in regards to the Worklight Server. First, the Worklight Server plays host to what Worklight refers to as ‘adapters'.  Adapters are JavaScript code that provide connectivity from mobile applications to backend enterprise information systems such as REST-based services, web services, databases, or just about anything else to which you need to connect. Seeing as these adapters run in the Worklight Server (within a Rhino container), you have the means to secure these as is necessary for services that reach into your Enterprise Information Systems. Secondly, the Worklight Server delivers a unified push architecture that makes it simpler to send push notifications to applications running on a number of different client device types. Effectively, this unified push architecture serves to hide the complexities associated with pushing messages across the different mobile platforms and lets administrators focus on simply reaching their application users.

Next up in the breakdown of the big four is the Device Runtime component. Worklight provides a client-side shell within which your mobile applications run. This shell provides several features and qualities of service, starting with cross-platform compatibility. The shell ensures that your applications have ready access to JavaScript bridges that enable accessing native device capabilities (PhoneGap) and that integrate with native display capabilities like tabs, badges, etc. (part of the Worklight client API). Another important part of the Device Runtime is the ability to create an encrypted, client-side cache. The Worklight shell extends the concept of local storage in HTML5, to provide a secure manner with which to store application data that can later be retrieved to avoid unnecessary service calls or support offline access.

In addition to all of this, the Worklight client API that is part of the Device Runtime component provides integration capabilities with the Worklight Server to enforce user authentication, check network connectivity, log user actions for reporting and analytics, integrate with the push notification capability of the Worklight Server, and much more. Finally, the Device Runtime enables the unique notion of skins. Skins allow you to apply different views for mobile applications that run on different device types within the same device family (e.g. iPhone and iPad). This means that you can reuse nearly all application artifacts across a wide array of devices in the same family, thereby significantly reducing development costs.

Our brief and I mean very brief, overview of the Worklight solution concludes with a look at the Worklight Console.  The console provides a web user interface through which you can manage many aspects of your mobile applications. First, you can manage application versions and easily take advantage of the capability provided by the Worklight Server to disable application versions. Through the console you can also manage push notifications to various applications across various devices, thereby taking advantage of the unified push architecture provided by the server. Finally, the console provides a central view of reports on mobile application usage and activity per the out-of-the-box statistics provided by Worklight as well as what your mobile applications report via the Worklight client API.

I hope this gives you a good, if not high-level overview of the Worklight solution that is new to the IBM family. I want to reiterate that this is in no means an exhaustive explanation, but more of a primer. I am sure I will be writing more on this topic in the coming weeks and months, but until then I hope to hear from you. If you have questions, let me know right here or on Twitter @damrhein. Until next time!

More Stories By Dustin Amrhein

Dustin Amrhein joined IBM as a member of the development team for WebSphere Application Server. While in that position, he worked on the development of Web services infrastructure and Web services programming models. In his current role, Dustin is a technical specialist for cloud, mobile, and data grid technology in IBM's WebSphere portfolio. He blogs at http://dustinamrhein.ulitzer.com. You can follow him on Twitter at http://twitter.com/damrhein.