Getting Started with IBM Worklight
IBM Redbooks Solution Guide
Published 26 August 2013
Authors: Steeve Chwojko-Srawley
IBM® Worklight is a platform for the development of mobile applications. It consists of five parts:
· Worklight Studio. A plug-in that is added to the Eclipse integrated development environment (IDE). It provides a development framework for Worklight applications.
· Worklight server. An application that runs on an application server. It gives access to deployed Worklight applications.
· Worklight console. An application that is distributed with Worklight server. It is used to manage deployed Worklight applications.
· Device run time. A collection of application programming interfaces (APIs) that are used to develop hybrid Worklight applications.
· Application Center: A private app store where developers can upload applications and users can upload feedback on the application.
This IBM Redbooks® Solution Guide describes how to build a mobile application with IBM Worklight Studio and deploy it to a test or production environment.
IBM® Worklight is a platform for the development of mobile applications. It is a member of the MobileFirst family of products. Worklight consists of five parts:
- Worklight Studio. A plug-in that is added to the Eclipse integrated development environment (IDE). It provides a development framework for Worklight applications.
- Worklight server. An application that runs on an application server. It gives access to deployed Worklight applications.
- Worklight console. An application that is distributed with Worklight server. It is used to manage deployed Worklight applications.
- Device run time. A collection of application programming interfaces (APIs) that are used to develop hybrid Worklight applications.
- Application Center: A private app store where developers can upload applications and users can upload feedback on the application.
This IBM Redbooks® Solution Guide describes how to build a mobile application with IBM Worklight Studio and deploy it to a test or production environment. The components of the Worklight platform are illustrated in Figure 1.
Figure 1.The components of the Worklight platform
Did you know?
Worklight builds applications on a common environment, which means that when you view an application on, for example, an iPhone and a BlackBerry, by default they automatically have the same appearence. You can modify this default as much as you want because Worklight provides environments for each device operating system that it supports. Worklight server can alert the user to the availability of a new version of an application, and it can even block an application so that it cannot be used until the new version is installed.
Worklight Studio provides a single environment for the development, testing, and deployment of an application. It has its own integrated server, a console view that provides a mobile browser simulator, and, if the Android Software Development Kit (SDK) is installed, an Android Emulator, which can give a more precise indication of the rendering of the Android environment (see Figure 2).
Figure 2. Worklight as an integrated development environment
Worklight can integrate with iOS by exporting the environment to Xcode. This exported environment runs only on an Apple computer.
From the developer’s point of view, there is no need to install extra software, or to package code to send outside of the environment for testing. From the governance point of view, Worklight can manage application accessibility and updates, security, and authentication. Worklight provides analytics for smart application usage activation of events, and can integrate with other analytics tools, such as Business Intelligence and Reporting Tools (BIRT), and IBM Tealeaf®.
Developers can be provided with a predefined shell component that includes web coding, such as company headers and logo, or contact information, and native coding and security. This shell ensures uniform development across teams: headers always have the same appearence, security always is implemented in the same way, and so on.
This section examines each component of the Worklight platform.
This is a plug-in that runs on Eclipse. It is an IDE that provides a single location for developing application and adapter code in the following languages:
- HTML5: The design language of web pages. Used for presentation of information in a browser.
- CSS3: Definitions for style elements, such as font type, colors, and cell padding.
- XML: Used to transmit data in a predefined format.
- Java: A server-side programming language. Widely used for the Internet.
Figure 3. Common folder structure
With this fundamental structure, you can create a web application that is tailored to the mobile environment by providing style information in the CSS file. However, Worklight is above all a hybrid environment; that is, it provides applications that mix web code and device native code. A decision must be made: which device or devices will use the application? A specific environment is added for each device (Figure 4).
Figure 4. Device environments
Figure 5. Skin folder structure
How do common, device, and skin environments all fit together in the application? It is simple: the code is cumulative, unless there is a conflict, in which case the innermost code wins out. In Figure 6, the common CSS specifies a background color of red, but this is overridden by the Android CSS. The skin specifies a minimum height of 100%, and because this does not conflict with any other value, it is added into the final mix.
Figure 6. Cumulative and overridden code
- HTTP: Retrieves information from a web service, for example.
- SQL: Retrieves data from a database.
- IBM Cast Iron®: Communicates with a private or a public cloud.
- JMS: Sends or receives messages from a Java message service.
A typical scenario is shown in the "Usage scenarios" section.
The Worklight server is an application that runs on an application server, such as IBM WebSphere® Application Server. Worklight applications and adapters do not run directly on an application server, but are controlled by the Worklight server, which itself is controlled by the application server.
The server manages two things: communication with the back end, and communication with the device. When an application starts, or is brought to the foreground, it can call the server automatically and check whether there is any available update. The server can respond in one of three ways: it can indicate that there is no new version, it can warn you that there is a new version that you should get, or it can block the device from using the application until the new version is installed. The server also provides application management and updates, push notifications, user authentication and device authentication, and so on. The server can provide only a new version of web content. Native content is available only through the app store where the application was downloaded.
This is an application that is installed with the Worklight server. It is used to manage applications and adapters that are deployed to the server (Figure 7).
Figure 7. Worklight console
Device run time
This term refers to the APIs that provide functionality to an application. They do not function as stand-alone components, but may be used by applications. Device run time includes these capabilities:
- Troubleshooting: Detection and correction of connectivity problems.
- Analytics: Collection of information about application and device usage.
- Skins: Optimization of appearence, features, and functions of different types in a single device family.
- Authentication: Managing the authentication sequence for an application.
- Local security: Encryption of data that is stored on a device.
- Version control: Apply new versions, or disable old versions in accordance with the information that is received from the Worklight console.
This is a private, enterprise store that can provide feedback for developers. Applications that are placed in the store are not necessarily complete; the developer might want users to download it to a device, use it, and then provide criticism or suggestions through the app store. Native applications can be distributed only through an app store, which leads to the following limitations:
- App stores review applications to verify that they are complete and non-malicious. An incomplete application is rejected.
- There is typically a lengthy delay between submitting an application and having it accepted. Developers need a fast response to their application.
- There is no feedback mechanism, where the user can provide suggestions, advice, criticism, and so on, to the developer.
- This application store is not intended as a place to get new applications; it is a work tool for interaction between developers and users.
The five components of Worklight fit together as shown in Figure 8.
Figure 8. Worklight platform
The Worklight platform is packaged with other components of the MobileFirst family, and the choice of package depends on two factors: what other components are required, and what licensing is required.
The Mobile Foundation package includes IBM WebSphere Cast Iron (in the Consumer Edition) and IBM Endpoint Manager for Mobile Devices (in the Enterprise Edition). WebSphere Cast Iron is an integration framework that enables companies to connect to clouds, as well as on-premise application, with a minimum of coding (the coding is declarative, which means that it is done by configuration rather than development language coding). IBM Endpoint Manager for Mobile Devices addresses issues of security, Bring Your Own Device policies, and connectivity issues. The Worklight package includes no component other than the Worklight platform.
Worklight can be licensed based on the number of devices that are connected, or the number of applications that are deployed.
The first decision is whether the scenario is business-to-employee or business-to-consumer. In the first case, the number of devices is known (or can be calculated). The license is therefore related to the installation and the number of devices. In the second case, the number of consumers cannot be known and therefore licensing is based on installation and the number of applications that are deployed.
The second decision is whether there is need for other components. If the answer is yes, the Mobile Foundation package is used; otherwise, the requirement is for Worklight alone. It could be, for example, that a company has IBM WebSphere Cast Iron, or some other solution for connectivity to the cloud, and does not require that component.
Figure 9 sums up these four high-level scenarios.
Figure 9. Packaging of Worklight
This section provides two scenarios for using Worklight.
Mashup of web service information
A mobile user might need to book a flight to a particular location. They have no preference for an airline company, so they provide just the destination and the flight date. The application that they use is local to their device, but it has the URL of the Worklight server to which it should link (this is stipulated as a part of the configuration of the application), and the name of the adapter and the function to call.
On the server side, the SQL adapter starts by querying a database to retrieve a number of URLs. There are the URLs of the airline companies, and maybe also a weather report site to retrieve the expected weather conditions on the flight date. There might be sites that provide entertainment information or restaurant information. The adapter then calls an HTTP adapter and hands in each URL. The HTTP adapter makes the request to each web service and returns the response to the adapter. When each site has responded (or timed out), the information may be assembled and formatted by using an XSL transformation that is a part of the adapter, and the resulting data is passed back to the device that sent the original request (Figure 10).
Figure 10. Mashup scenario
The flight in the previous scenario is booked, and the client wants to be informed if there is any delay or cancellation. Typically, interactions with the server are initiated by the client, but for notification, it must be the server that initiates the call and returns the information to the device.
The numbers in the following paragraphs refer to Figure 11. Register the device so that it requires notification. The first communication is with a push service mediator, which registers the device that called, and returns a token (1). This is not a part of Worklight: it could be an Apple or a Google push server, for example. The token is used to subscribe to an event source through a Worklight adapter. As a part of this process of subscription, the token is passed in (2). The adapter event source has two options: it can poll the back end for events, or it can wait until the back end pushes a notification to it (3). In both scenarios, the adapter calls the push service mediator and hands it the notification and the token (4). The push service mediator retrieves the device URL that is associated with the token, and pushes the notification out to the device (5).
Figure 11. Push notification scenario
Worklight Studio is a plug-in for Eclipse. A plug-in is a software component that adds functionality to an application. Eclipse accepts plug-ins (you can even write your own), which means that Worklight can benefit from the utilities that are provided by Eclipse, such as editors, a code completion feature, and syntax problem reporting. Worklight also can link to Java classes that are developed in Eclipse.
Worklight server is an application in itself, so it requires an application server in order to function. It integrates with WebSphere Application Server, including the Liberty profile, or Apache Tomcat. Applications that are served by Worklight server can benefit from the security environment of the application server, the data sources, and so on. It has access to the application server components.
For more information about supported platforms, see http://www.ibm.com/support/docview.wss?uid=swg27024838.
Ordering information is shown in Table 1.
Table 1. Ordering information
|Program name||PID number||Charge metric|
|IBM Mobile Foundation Enterprise Edition||5725-I41||Client Device Install|
|IBM Mobile Foundation Consumer Edition||5725-I42||Application|
|IBM Worklight||5725-I43||Client Device Install Application|
|IBM Mobile Application Platform Pattern||5725-G24||Client Device Application Virtual Server|
For more information, see the following documents:
- IBM Worklight product page
- IBM Worklight V6.0 - technology overview
- IBM Worklight V6.0 Information Center
- IBM Worklight V6.0 data sheet
- IBM Offering Information page (to search on announcement letters, sales manuals, or both):
On this page, enter IBM Worklight, select the information type, and then click Search. On the next page, narrow your search results by geography and language.
Others who read this publication also read
This material has not been submitted to any formal IBM test and is published AS IS. It has not been the subject of rigorous review. IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a client responsibility and depends upon the client's ability to evaluate and integrate them into the client's operational environment.
Follow IBM Redbooks
Follow IBM Redbooks