|By Dustin Amrhein||
|March 2, 2012 09:00 AM EST||
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.
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.
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!
- Forget Defining Cloud Computing
- IBM & Cloud Computing: Self-Service Clouds with Fine-Grained Control
- IBM & Cloud Computing: How WebSphere CloudBurst Delivers Consumability
- Cloud Computing and Virtual Images
- Bringing Cloud Computing to SOA
- Five Reasons to Choose a Private Cloud
- What's in a Cloud Appliance?
- Should Developers Care About Cloud Computing?
- Reference Architecture for Cloud Computing
- Confronting The Culture of Cloud Computing