Modified on by Christian Karasiewicz
This blog post is contributed by Vittorio Della Rossa, an IT Executive Consultant in GTS.
Nowadays the word mainframe is mistakenly used to refer to an old world. New frontiers are monopolized by mobile technology, and most people believe that these two worlds oppose each other, or are even competitors.
I believe many are not aware that IBM System z technology is so up-to-date that it can be efficiently mixed to build a mobile-ready and cost-affordable infrastructure.
The mobile challenge
The new aspects that mobile app developers must consider are the consequence of moving from traditional environments. An unpredictable number of users, multiple technologies and not-so-stable connections lead to the need for more functionality and more secure and cost-effective mobile enterprise application platforms (MEAPs). So IBM MobileFirst was announced last year to provide answers to all of the following requirements:
A solid application and data platform
Integrated management functions
IBM MobileFirst helped developers by providing IBM Worklight, which is designed to help organizations build, run and manage mobile apps. It is a comprehensive set of tools, application programming interfaces (APIs) and runtime components that help give developers the freedom to quickly build the following types of apps:
Native: By using device native languages, these can use all sensors’ data.
Hybrid: These are a combination of the previous types. Apps are written for the browser but are wrapped in a container that enables them to access the device hardware.
The IBM Worklight Foundationd is built around five components (these can be seen in the next figure):
Worklight Studio is a development platform designed for coding, testing and completing integration tasks for web, hybrid or native mobile apps. It interfaces with native tools, such as XCode and Android Studio.
Worklight Application Center enables a company to set up an app store to distribute mobile apps.
Worklight Server is a horizontal, scalable middleware that sits between the mobile app and the back-end, enterprise services. It acts as an auditable control point for mobile devices, and it provides a strong security layer with functions for multi-factor authentication and mobile app authenticity checking.
Worklight Device Runtime is a client-side runtime code compiled into hybrid apps that embeds functionality, such as offline, encrypted and syncable data stores that can interact with the Worklight Server.
Worklight Console is a web-based user interface for monitoring and administering the Worklight Server and its deployed applications.
You can find more info from the IBM Worklight technology overview.
System z brings good news to mobile
The System z platform is not only one of the most reliable and flexible platforms but also one of the most innovative ones. Some technologies, like transactional memory or out-of-order execution are exploited by software like IBM DB2, IBM CICS and compilers, allowing performance at a best-of-breed level. System z platforms can scale, both vertically and horizontally, without service interruptions. Spare resources and control mechanisms also make this the right infrastructure for the highest availability requirements. These characteristics and solid virtualization capabilities are available to a wide range of operating systems that can be run on the System z platform.
Another unique aspect is the ability to connect virtual machines with HiperSockets (a no-cost feature). This builds a secure and fast TCP/IP network within System z, running at memory speed. Data transfers between Worklight Server and software like IBM MQ, DB2, CICS and IBM Information Management System (IMS) will benefit from such speed. The adjacency with existing database and transaction systems will also allow faster data access and reuse of old applications.
How do you put mainframe and mobile together?
The Worklight Server will gain the benefit of all these characteristics when deployed on a typical Linux environment on the System z platform. Linux on mainframe? Yes, of course; this has been possible for almost fifteen years using the dedicated processor called Integrated Facility for Linux (IFL).\
Considering all the adapters of the Worklight Server with MQ, DB2, CICS and IMS, its ideal deployment is on a Linux for System z. The coexistence with database and transactional environments will be easy and cost effective, allowing you to reuse existing data and programs with no changes. From a performance point of view, the System z platform is so flexible because it allows you to add more IFL processors in-flight when needed in order to deal with your workloads’ peaks. Your recovery needs will be easier to address by adding the same number of IFL processors to your recovery site and adapting your existing data replication solution.
So what about those who do not already own a System z? The mobile challenge is an opportunity to rethink your data center and start consolidation initiatives of all your Linux systems on a new System z. I will be happy to help you in this journey or be in touch with any colleague of mine that might be engaged with you, so connect with me on Twitter @vidierre.
Modified on by Christian Karasiewicz
This blog post is contributed by Jorge Gonzalez Orozco, a Senior Mobile Solution Architect in IBM.
A few days ago IBM released the new IBM Worklight version 6.2. This is a major update with many new features and a product rename. The new IBM Worklight Platform now includes three independent components that are sold separately:
IBM Worklight Foundation (previously "IBM Worklight") is the mobile-focused, standards-based middleware and tools for enterprise-ready mobile application and services development.
IBM Worklight Quality Assurance is the component that lets you analyze the application user sentiment and collect beta test feedback and crash data.
IBM Worklight Application Scanning is the feature that lets you find source code vulnerabilities early in the software development lifecycle.
You can download and try this latest version of Worklight Foundation at no charge. There is also extensive documentation about the Worklight platform:
The new IBM Knowledge Center allows you to create your own personal collection of Worklight help documents, share them through email, LinkedIn or Twitter or export the document collection as a PDF file.
IBM developerWorks has a great portal focused on getting started with Worklight where you can get tutorials, sample code, integration guidelines and best practices.
There is a Worklight developer support community in Stack Overflow where you can submit questions and get answers fast.
Here are my top ten new features in IBM Worklight Platform:
1. IBM Worklight Quality Assurance (sold separately)
Mobile Quality Assurance lets you discover and set up mobile quality services for your apps. You can view high-level quality metrics for your mobile apps to get a quick understanding of the issues for apps that you are working on. These metrics include information for crashes, bugs, user feedback and user sentiment. By viewing this information for your apps, you can determine whether to investigate specific issues further.
2. IBM Worklight Application Scanning (sold separately)
3. Command-line interface
The command-line interface (CLI) feature provides basic scaffolding, as well as project and app support for native and hybrid development environments. This provision enables developers to use their preferred text editors to create mobile applications outside of the traditional Worklight Studio environment. When your apps are developed, the CLI provides the commands necessary to build and deploy them to a local development Worklight Server. Adapter creation, deployment and local testing can be performed with the CLI.
4. Improved operational analytics
The operational analytics feature enables searching across apps, services, devices and other sources to collect data about usage or detect problems. All this information is accessible from the Worklight Console. The analytics feature enables enterprises to search across logs and events that are collected from devices, apps and servers for patterns, problems and platform usage statistics. The data for operational analytics includes the following sources: interactions of any app-to-server activity, client-side logs and crashes and server-side logs that are captured in traditional Worklight log files.
5. Ability to mix web and native components across your application
6. Native development enhancements
In addition to developing hybrid Windows Phone 8 applications, you can now use the new Worklight C# client-side API for Windows Phone 8 native applications to access Worklight services. The API exposes two main capabilities: calling enterprise services to retrieve data and perform enterprise transactions and writing custom log lines for reporting and auditing purposes. Also, there is now support in native applications for the no-SQL JSON store. (For more, check out David Pearson's post “Native developers, welcome to IBM Worklight!”)
7. USSD support
Unstructured Supplementary Service Data (USSD) is a communication technology that is used by GSM (Global System for Mobile Communications) cellular telephones to send text messages between a mobile phone and an application program in the network. USSD support is now available in IBM Worklight Foundation V6.2. It works on both smartphones and feature phones. USSD provides near-real-time interactive messaging and is particularly useful for building interactive menu-driven applications. It provides a cost-effective alternative to mobile applications in emerging markets where feature phones are widely used.
8. Client-side log capture
Applications in the field occasionally experience problems that require a developer's attention to fix. It is usually difficult to reproduce problems in the field because developers often do not have the environment or exact device where the problem was found. In these situations, it is helpful to be able to retrieve debug logs from the client devices as the problems occur in the environment in which they happen. Starting in Worklight Foundation V6.2, developers that use Worklight client-side APIs who want to capture both platform (IBM Worklight Foundation) and application (your code) logs for debug and problem determination can instrument the application to make debug log data available for capture and submission to the server.
9. New architecture of the Worklight Server components
Starting with Worklight Foundation version 6.2, there is a new architecture for Worklight Server, which is now composed by the following components:
The Worklight runtime environments, which are packaged as web applications (WAR files) and host one or more Worklight applications.
The Worklight Console application, which is the web-based interface that is used to run administration tasks on the mobile application. The Worklight Console is supported by the Administration Services application and can manage several Worklight runtime environments.
The Administration Services application, which hosts all the Representational State Transfer (REST) services and administration tasks. You can now use REST services to administer the Worklight server.
The Application Center, which is the Worklight application store.
The Worklight Operational Analytics dashboard.
10. Zero-downtime fix pack upgrade on the server
With IBM Worklight 6.2, you can perform a rolling upgrade to apply a fix pack or an interim fix to an installation of Worklight Server V6.2.0 without downtime of the Worklight runtime environment. Performing this rolling upgrade ensures that there is no interruption of service for the mobile applications that connect to the Worklight Server. This procedure applies to a Worklight Server installation, including the Administration Services, the Worklight Console and the Worklight runtime environment.
These are only ten of the many new features available in the Worklight platform. Which new features do you find useful? You can share your thoughts by leaving a comment below or connect with me on Twitter @jorgego11.
Modified on by Christian Karasiewicz
This blog post is contributed by David J. Pearson, Enterprise Mobile Solution Architect and Technical Staff Member (TSM) working for the IBM WebSphere Software Services (Mobile Practice) based in the UK.
With the recent launch of IBM Worklight V6.2, native mobile application developers have never had such a rich set of tools to innovate and create terrific cross-platform applications. Here are five highlights of Worklight 6.2:
1. Bring your own IDE
If you are not familiar with Eclipse or simply do not want to learn how to use a new integrated development environment (IDE), that’s OK. With Worklight 6.2, you can carry on using Apple Xcode, Microsoft Visual Studio or other tools that you already use. By creating the native application programming interface (API) within Worklight and adding it to your native code, you will be able to take advantage of Worklight features such as its security model, unified push notifications and integration to enterprise data using adapters.
2. Command-line interface
In addition to APIs, Worklight 6.2 introduces command-line interface (CLI), and, as the name suggests, it allows you to perform common Worklight developer tasks without the need for the Eclipse-based studio client. Available commands include create a Worklight project, add environments, build applications and build or test adapters.
3. Combine native and hybrid code
Most native developers usually create mobile applications for one platform only. A key value proposition of Worklight 6.2 is to enable them to have their application available across other platforms through the use of web standards hybrid code. Additionally, as can be seen in the diagram below, combining native and hybrid code can allow innovation around common user experience, application flow and application startup:
(On a related note, check out Nathan Hazout’s post on how to debug a hybrid Worklight application.)
4. Bluemix API catalog in the cloud
IBM Bluemix is an implementation of IBM's open cloud architecture, based on Cloud Foundry, that enables you to rapidly create, deploy and manage your cloud applications, including mobile apps. For native developers, Bluemix provides a range of mobile backend as a service (MbaaS) options that allow cloud infrastructure to be leveraged in your apps, giving you enterprise-grade quality, security and integration options. Additionally, you can use cloud APIs (the following diagram shows a selection for mobile). These allow you to reduce the time to build, test and deploy your mobile applications.
5. Quality control and testing
One of the most important aspects of the design, build, and deployment of mobile applications is quality. A great, high-quality app typically gets positive feedback and creates or maintains a good reputation for the developer. Worklight 6.2, alongside services from Bluemix, provides you with ready-made capabilities to improve the testing and quality of your apps:
In-app bug reporting: The ability for users to submit bug reports from inside your app
Automated crash reporting: Aggregated crash logs providing details needed to address app and infrastructure issues
User feedback and supplemental analysis: Feedback from within your app from users and ratings to analyze your apps
In summary, IBM Worklight 6.2 and IBM Bluemix combine to create a compelling set of capabilities that native developers can use today to build, test, deploy and maintain enterprise grade mobile applications. Take a look today!
Connect with me on Twitter @DJPearson1
and tell me what you think.
Modified on by Christian Karasiewicz
This blog post is contributed by Steven Kim Yong Yeo, an experienced network architect and consultant.
Globalization has changed the way businesses should operate. To achieve better revenue, organizations have relocated various business functions to different locations, either where the operation cost is lower or where the location can bring significant advantages to the business. This operation model has affected the user computing experience. Since many companies have offices located in different locations or even in different countries, along with varying time zones, users are expected to work and get connected in any place and at any time. As such, handy mobile devices have been adopted for user computing convenience and ease of access.
The traditional way of computing is the client-server architecture, also known as fat-client computing, where a distributed application requires frequent communication between the user and server applications over the computer network. This computing model has become unsuitable for global operations. Application transaction responsiveness, reliability and high performance network connectivity are the critical requirements for supporting a worldwide operation. However, some requirements, for example network connectivity, are beyond the average user’s ability to manage and control, because they rely on the service provider’s capability and availability.
Industry analysis reports have shown that most users have switched from the client-server model to the thin-client model. Thin-client computing depends heavily on some other computer, whereas normally the application servers fulfill the computational roles. Compared to fat-client computing, as mentioned above, the client’s computer is designed to take on these roles by itself.
The specific roles assumed by the application server may vary, from providing data persistence (for example, for diskless nodes) to actual information processingon the client's behalf. Thin clients occur as a small application footprint located inside the user system, where many users share their computations with the same server. As such, thin-client infrastructures can be viewed as providing some computing service using several user interfaces. Thin-client computing is also a way of easily maintaining computational services at a reduced total cost of ownership. The most common type of modern thin client is a low-end computer terminal that only provides a graphical user interface, which includes devices like smartphones, tablets and more.
In view of these changes to the user computing experience, what will be the impact to application servers and to the infrastructure setup for hosting these servers? The main concern will be the increasing traffic generated from client devices. If we look at the number of desktop computers versus the number of smart devices, we will see a huge gap between these two numbers, with many more smart devices accessing the application servers than desktop computers.
So, how do you think the existing network infrastructure is going to handle these changes in the user computing environment?
Modified on by Christian Karasiewicz
This blog post is contributed by Tamer Abuelsaad, a Sr. Software Engineer focused on data protection and identification.
How much do you know about the apps running on your mobile device? Different mobile operating systems, such as Android and iOS, enforce different disciplines. For example, Android apps can be signed with a self-signed certificate rather than with a trusted certificate authority. In many cases when it comes to signing or packaging apps, developers just satisfy the bare minimum requirements to get an app in an app store. So how do you find out what they’ve done? In this post I share how you can examine apps installed on your Android phone (and without even having to root it).
I wanted to learn more about the apps installed on my own Android phone, so I decided to look at the Android application programming interfaces (APIs).
Obtaining the list of packages
With Android’s PackageManager API, there is a method for getting installed packages (getInstalledPackages). This method enables you to get a listing of all the packages installed on the device. Depending on the flag passed to this method, it will return different information. However, for the purpose of this article I will pass the PackageManager.GET_SIGNATURES flag.
PackageManager pm = this.getPackageManager();
List<PackageInfo> infoList = pm.getInstalledPackages(PackageManager.GET_SIGNATURES);
Obtaining application information
A package has many attributes that we can harvest and examine. In addition, each package belongs to an application. The PackageInfo class allows you to obtain a rich set of app characteristics. From PackageInfo you can extract information from the application tag by accessing ApplicationInfo variable.
ApplicationInfo appInfo = pkgInfo.applicationInfo;
The ApplicationInfo attributes that seemed of interest to me are:
You might be interested in others.
Obtaining package information
The PackageInfo attributes that seemed of interest to me are:
Obtaining package signatures
Package signatures are the X.509 signatures found in the application packaging. This is a result of signing an app with a certificate. From package signatures I can determine if a self-signed certificate was used to sign the app and its attributes.
Signature signatures = packageInfo.signatures;
For each Signature object obtained, load the certificate so that its attributes can be parsed:
byte cert = signatures[i].toByteArray();
InputStream input = new ByteArrayInputStream(cert);
CertificateFactory cf = cf = CertificateFactory.getInstance("X509"); //certificates are of type X.509
X509Certificate c = (X509Certificate) cf.generateCertificate(input);
From the X509Certificate object I can access, through getter methods, all the attributes of the certificate, such as subject or issuer Distinguished Name (DN), validity period and so on. Here are the ones I found interesting:
For more on X.509 certificate attributes and their purpose, see this Wikipedia entry.
When I put this all together, I get generic and security information about the application. Analyzing this information can yield some interesting observations about each app you have on your mobile device. In a future post I will share observations about applying this analysis to apps on my phone.
What can you do with the knowledge you’ve extracted from each app? Connect with me on Twitter @tearoks and share your thoughts.
Modified on by Christian Karasiewicz
This blog post is contributed by Nathan Hazout, a developer for the web and for mobile who does customer oriented R&D for IBM Worklight.
Choosing to develop your mobile application using web technologies allows you to quickly deliver a multiplatform application without investing too much time and resources in learning to develop for each platform. However, you lose some of the built-in debugging features that each of the native integrated development environments (IDE) provide.
To work around this drawback, here are some tips that can help you find out why that cool button you added doesn’t do what it was supposed to do.
1. Preview as common resources
In your Worklight Console, click on “Preview as Common Resources.”
You will now be able to debug your application just like any other website. Depending on your browser, there are several tools available.
If you use Chrome, you have access to the Chrome DevTools, which allows you to do things such as
Inspect your HTML and CSS
Edit the Document Object Model (DOM)
Observe network requests
Emulate mobile resolution
There are many other browser inspector tools available such as Firefox’s Page Inspector, Firebug, Safari Web Inspector and more.
2. Mobile browser simulator
When previewing as common resources is not enough, IBM Worklight provides the mobile browser simulator.
You can access it from the Worklight Console by clicking on the “eye” icon.
The mobile browser simulator has added value over “Preview as Common Resources.” For example, it enables you to:
Emulate different devices and skins
Emulate some Cordova features such as access to sensors, geolocation, accelerometer, camera and so forth
You can still use your browser inspector while using the mobile browser simulator.
3. iOS Safari remote debugging
If you have access to a Mac with Safari (6 and higher) and Xcode, you can use Safari Web Inspector to remotely debug a hybrid Worklight application running on the iOS emulator or on a real device connected to your computer. Follow these steps:
Make sure your device (or simulator) has “private browsing” turned off.
Enable Web Inspector on your device: Settings > Safari > Advanced > Web Inspector.
On your Mac, in Safari, check the box in Preferences > Advanced > Show Develop menu in menu bar.
Start the mobile app.
On desktop Safari, go to “Develop” and find your device or emulator. Click on the file name.
Inspect the app just like you would inspect any other web page.
Note that you can only inspect applications that were transferred to a device using Xcode, and not third-party applications downloaded from the app store.
4. Android Chrome remote debugging
If you have a device (or emulator) running Android KitKat (4.4 or above) and are using Worklight 6.2 or above, there is a way to remote inspect your application, similarly to what we did above with iOS, but with a few extra steps.
In AndroidManifest.xml, make sure your targetSdkVersion is 19 or above.
In project.properties, make sure your target is 19 or above as well.
Start your application in the Android emulator or a connected device.
In Chrome, type the URL about:inspect.
You should see your application with an “Inspect” link
You can now use all the features of the Chrome web inspector to inspect your Android application!
Weinre is a free tool (as in “free beer” and as in Apache License) that allows you to connect a browser inspector to your mobile application remotely when the previous solutions are not doable.
A Weinre setup is made of three parts: the “target” (your device, application), the “client” (the web inspector running on your desktop browser) and the “server” (the host making transmitting data between the client and the target). Very often, all three parts will run on the same computer, but you could choose to run them separately.
You first need to install the server.
Run the server (using the command line). The default port chosen by Weinre may conflict with your existing server, so choose your own port number. Also, using “localhost” won’t work if you plan to debug a device.
Go to the URL shown in the terminal (for example, http://my.ip.address:8081). You should see the server home page with basic instructions on your screen.
Copy the “target script” inside your index.html.
Deploy your Worklight application and run it.
On your Weinre server home page, click on the Access Point link.
You should see your application in the list of targets. Click on it.
Choose one of the tabs and inspect away!
6. Good old logger
Sometimes, there is no way around the most used way of debugging your application: print logs.
Worklight features a logger API.
More ways out there
I am sure there are a lot more techniques out there that I haven’t talked about, and I invite you to share your own experience below. For example, do you have any tips to debug Android before KitKat? What about debugging Windows Phone and BlackBerry?
Modified on by Christian Karasiewicz
This blog post is contributed by Bruce Armstrong, an IBM Portfolio Manager in Software Group for Application Infrastructure Middleware working on all aspects of mobile and System z.
There is one driving force behind mobile access to the mainframe using the z/OS operating system—it makes good business sense. You likely have millions of dollars and years of time invested in your company’s mainframe. It may store your customers’ names, addresses and transaction history, and it likely stores critical information about your company such as prices, schedules and inventory. Leveraging this data in your mobile applications enriches the customer experience and can provide your company unique differentiation to your customers. This data can also enhance the productivity of your mobile employees by giving them key information while they are on the go.
Several options exist today for mobile-to-mainframe communication. In this blog post, I will focus on one of the newest options, called z/OS Connect.
z/OS Connect is not a separate product. It is a software component that is downloadable as part of IBM WebSphere Application Server 8.5 for z/OS (WAS 8.5) and will be shipping with IBM CICS Transaction Server for z/OS 5.2 (CICS 5.2), and the IBM IMS Enterprise Suite for z/OS 3.1.1. The inclusion of z/OS Connect with these other products provides you with implementation consistency regardless of your environment.
z/OS Connect provides a RESTful (that is, Representational State Transfer technology) interface to traditional z/OS environments, thus allowing integration with mobile applications.
So what makes z/OS Connect special and valuable to your enterprise?
Standards-based access to the mainframe
z/OS Connect hides the complexities of connecting and interacting with z/OS applications and data, thereby reducing development time and cost. It makes the mainframe appear just like any other server in the network to the mobile application developer.
Integration with z/OS services
The mainframe has existing management functions for accounting, security and workload management. For example, many company accounting processes are based on z/OS System Management Facility (SMF). z/OS Connect supports the creation of data in this SMF format. z/OS Connect also leverages mainframe security access control and participates in the mainframe workload management process to maximize performance and throughput of mobile processing.
RESTful interfaces by their nature provide a mechanism to discover what application services are available for use. z/OS Connect supports this discovery capability but can also limit what mainframe services are exposed to the mobile world. This provides the flexibility to offer mobile access to some and limit access to others.
Fast and easy setup
z/OS Connect is based on the WebSphere Application Server Liberty Profile, which is a lightweight application server environment that is easy to install and configure.
To see an overview of z/OS Connect, please check out this z/OS Connect YouTube video and find more details here.
Some notes on using z/OS Connect
It is worth noting that your company needs to consider access security to your mainframe before you implement z/OS Connect. There are many ways to control access to mainframe-based applications. You might first use a firewall to control access to your enterprise and then a first layer of security checking (commonly called a DMZ, which is a firewall configuration for securing local area networks) that minimizes risk to your enterprise. z/OS Connect security is not a replacement for these common security practices.
Also, message transformation can occur at various stages in an enterprise environment. z/OS Connect is one option for JSON data formats. It has the advantage of using the mainframe processing power (and since it is written in Java, it leverages the mainframe special processors for Java workloads).
CICS clients please note: z/OS Connect uses the same underlying technology as CICS TS V5.2 and the previous Mobile Feature Pack, so think of z/OS Connect as the next step to what you may have today but now available for WAS and IMS environments.
So z/OS Connect is a new way to integrate your mainframe applications and data into your mobile applications. It is easy to configure and brings together various environments into a manageable, modern interface suitable for mobile applications. Consider using z/OS Connect in your mainframe environment with CICS 5.2, IMS Enterprise Suite 3.1.1 or WAS 8.5 and get your company “mobilized.”
Do you have other questions about z/OS Connect? Leave a comment or reach out to me on Twitter @BarmstroN.
Modified on by Christian Karasiewicz
This blog post contributed by John Samuel who focuses on the Internet of Things and M2M with IBM.
Most of you are probably asking yourself why I’ve got a picture of a cow in this article. Well, you’ll have to wait and see.
A few weeks ago at the IBM Impact conference the IBM Internet of Things (IoT) Cloud was announced. You can access the QuickStart alpha here. Since then I’ve received lots of queries from customers and IBMers alike who want to know the answer to this question: “This replaces IBM MessageSight, right?”
The answer is of course “No, it doesn’t.”
But that question does lead to another harder one to answer: “When do you use the IBM Internet of Things Cloud and when do you use the IBM MessageSight appliance?”
The default answer of “It depends” springs to mind, which doesn’t help very much, now does it?
Okay, let me start at the beginning, and then perhaps we’ll have an answer. The IBM IoT Cloud is available to try at no charge, so feel free to give it a go. It's an alpha at present but you can hook up a device and see that data interactively displayed. Neat and useful—I think you’ll agree.
Over time more functionality will be delivered in the cloud service, including a historian. This historian will allow you to store the device’s data for retrieval and inquiry at a later date rather than just displaying the data in real time. This all sounds very similar to the IBM MessageSight appliance, and you may have seen from my previous blog posts that you can connect up to a million devices to a MessageSight appliance to enable the device data to the enterprise. So on the surface it does appear that they are the similar tools for the same issue. The actual difference might be cultural or at least a buy-verses-build approach to a solution.
Currently the IBM MessageSight appliance has to be purchased from IBM. Once it is delivered the appliance has to be housed in a location, connected to devices and integrated into existing enterprise infrastructure like data stores or analytics engines.
I’ll use a few fictional scenarios to explain.
Let’s say a car rental company purchased an appliance to enable its minute-by-minute car sharing app to be newly deployed onto customers’ smartphones. They’d have to connect the appliance to the in-house data repositories to process the car booking requests received by the appliance from the smartphones and even the cars themselves. It is highly likely that this company would have existing data centers, IT infrastructure and experienced IT staff who know how to perform these vital tasks. So investing in an appliance to enable the data connectivity that can scale to millions of devices in moments makes sense.
Or, let’s say a dairy farmer had the sensors on his cows connected during milking. It would be unlikely that he’d have access to existing infrastructure or skilled IT experience. This is when the simplicity of a cloud solution would be of benefit—hence the IBM Internet of Things Cloud, which is a pay-as-you-go service. This rental approach would give the farmer the service he needs to connect to his herd’s monitoring sensors but without the initial capital expenditure of IT overheads. As it is a cloud service, the farmer can pay for what he uses. So if his herd increases or decreases, the costs would rise and fall in line with this fluctuation. Now you know why there is a picture of a cow at the top of this article.
This is just one reason why a company might choose to have the appliance housed in its data center over opting for the cloud service.
The IBM Internet of Things Cloud QuickStart is currently in alpha stage, but if you’d like to hear about newly deployed features and functions just register to receive updates. Then, when the historian is added, Mr. Farmer will be able to check Daisy’s current sensor readings with her previous milking parlor records.
Could you make use of the IBM IoT Cloud? If so please feel free to comment below, or you can follow me on LinkedIn and Twitter.
Modified on by Christian Karasiewicz
This blog post is contributed by Patrick Fan, a client-facing IT Architect and AIS Mobility Competency Leader in IBM Hong Kong GBS.
In the first blog post of my series about better managing your mobile application projects, I mentioned that mobile performance is still an overlooked and improperly-defined mobile project requirement. But what if we did define our performance requirements? How can we actually meet these requirements? In other words, how can we build a high-performance mobile enterprise application?
I decided to write a blog post on this topic given my recent experience in a mobile banking project. To be more specific, I will be focusing on the Apache Cordova hybrid mobile app, which is a popular choice for mobile enterprise because it has good cross-platform support and development skills reuse.
When we talk about mobile performance, what we generally measure is the loading and execution time and the responsiveness and smoothness of user interactions.
In the following sections, I will talk about how we can improve mobile application performance in these two areas.
Improving application loading and execution time
Avoid excessive network access.
Unless your mobile application is operating purely offline, it is common for a mobile enterprise application to access server data or services. Because network accessing speed is relatively slow and unstable, this can lead to potential delays in response. If your application requires network access, it would be wise to minimize those network requests by caching static resources in your application or by preloading the required information and content in a batch that has a minimal set of requests when your application starts.
Minimize the number of requests and size of content sent to Cordova plug-ins.
Cordova is doing a great job of providing native access to the mobile web application. However, there are always overhead costs when invoking the logic and waiting—sometimes up to hundreds of milliseconds—for callback from the Cordova plug-ins. If your application has to call on numerous sequence functions from customized Cordova plug-ins, it is better to group these functions in a single call in order to avoid the overhead costs across the web and Cordova tiers. If you need to pass large content, such as base64 images or PDFs that are going to be reused for a number of customized Cordova plug-ins, you should consider storing the content in the native layer and returning the content key back to the web tier. By doing this, you would be able to retrieve the data by the key instead of passing the content a number of times across the web and Cordova tiers.
Leverage native code for heavy computation operation.
Improving responsiveness and smoothness of user interactions
Leverage hardware-accelerated CSS when appropriate and minimize content reflow.
Handle the "300-millisecond click delay" on mobile devices.
Keep graphics and style simple.
CSS3 provides different modules to help us easily achieve wonderful styles and effects. But improper or excessive use of these styles can actually kill the performance of your application. In modern user interface development, designers keep on adding transparency and shadows to elements, and users love this. However, these opaque styles and shadows are expensive due to the computation power required to render them, especially when there are many elements applied and those effects overlay each other. Some of the mobile devices and operating systems are supporting hardware acceleration on this, but there is still a limit to these devices’ hardware memory. Excessive use of hardware acceleration can cause memory swapping, which can cause performance hits. Try to keep the graphics and style of your application simple and test everything carefully on actual mobile devices.
Last but not least, it is critical to test and benchmark your application on your targeted devices. This should be done regularly even after the application has been rolled out. Performance is not a one-off activity; it should be considered a “business as usual” activity.
Can you think of other performance tips from your own projects? Please share your experience here or follow me on Twitter @PatrickCSFan.
Modified on by Christian Karasiewicz
This blog post is contributed by Serkan Ersanlı who has been working as an IT Architect in IBM GBS and handles Regional Mobile and Social Solutions Focal Point in the MEA Region.
As you may remember from my previous blog post, we took a look into hybrid and native development models in IBM Worklight and illustrated how SWOT analysis can help us in the mobile solution design process.
Today I will emphasize three main reasons to consider Worklight as a development platform. Although there are plenty of reasons to put Worklight into your mobile solutions, I will explain three that I think demonstrate the strongest benefits of Worklight as a development platform.
I hope the reasons listed below will answer the question, “Why should I consider IBM Worklight as a mobile development platform?”
1. Multiplatform support
Worklight supports multiple mobile platforms for development and has the ability to build once and deploy in all.
Worklight offers the strongest benefits when employing the hybrid development model, and it is designed to be able to create and build iOS, Android, Windows Phone and BlackBerry applications separately within a single Worklight project.
Consider a mobile application that has to run in all of the popular platforms. It is obvious that without Worklight we’d have to think about creating distinct project plans for each platform. Since all platforms have to be developed by specific programming languages (Java, Objective-C, C# and so on) and specific development platforms (Eclipse, Xcode, Microsoft .NET and so forth), the analysis, design, development and testing processes should be evaluated separately in the project lifecycle.
Multiplatform support of Worklight enables businesses to create cross-platform applications in a single project, and it is one of the strongest reasons to choose Worklight as your development platform.
2. Single area of expertise
Development of mobile applications regardless of mobile platforms means that you are able to create mobile projects with a development team consisting of the developers with the same expertise.
When mobile projects are developed natively and on their specific development platforms, there is always need for development teams with platform-specific expertise. For example, you will have to build a development team with XCode and Objective C skills to create a native iOS application. The case is similar for Android development and the other remaining mobile platforms. The main problem with development for multiple platforms is to build teams with different technical expertise. The other issue is that these resources are also rarely interchangable between teams.
Development by Worklight brings businesses the ease of locating resources with the same area of expertise into cross-platform mobile projects. In the worst case scenario, native coding may be required just for the device-specific cases that Apache Cordova does not support. You should be able to resolve this kind of issue with very few developers who have platform-specific development expertise.
3. Cost benefits
For the projects’ sake the most important parameter is of course the budget, and this is another area in which Worklight makes you feel comfortable.
Throughout the development phase, IBM Worklight can help you to maximize the sharing of the code base from one environment to the other, effectively reducing the costs of development, time to market and ongoing management efforts. Furthermore, multiple mobile platform support in Worklight and working with people with same area of expertise rather than platform-specific resources increases the cost benefits in the project budget.
By reducing development and maintenance costs in mobile projects, Worklight seems appealing for businesses that are looking for solutions to build a strong mobile enterprise.
For further information on the cost benefits of IBM Worklight, I strongly recommend that you download and read “The Total Economic Impact Of IBM’s Worklight Platform,” a study published by Forrester Research, Inc. A clear benefit can be seen if you compare the initial and annual costs of developing and maintaining a complex four-platform app in a native environment and on the Worklight platform.
I hope this blog post has given you a clear understanding of the main benefits and opportunities of IBM Worklight product.
Connect with me on Twitter@serkanersanli to talk more about mobile solutions.