Enterprise Mobility Patterns: Application Storage

Storage is one of the overlooked requirements of enterprise mobile solutions. From a technical standpoint, almost any mobile application you can think of requires some form of storage to persist transient data that is specific to its runtime behavior.

That type of mobile-first storage is very specific to the functionality of the mobile app and is not related to the manipulation of business data which is typically stored in corporate databases. The following list includes some of the classic examples of mobile-first storage:

  • Application-User Settings
  • Application Session Data
  • User Session Data
  • Cached Data

 

From an architecture standpoint, this type of mobile-first storage has some very unique characteristics:

  • Semi-structured: Any mobile-first storage technology must be able to store semi-structured data as this is the most common data payload in mobile applications.
  • Isolated per mobile application: A mobile-first storage should be able to provision isolated storage units for the different mobile applications. This will prevent collisions between the different mobile apps deployed in an enterprise.
  • Partitioned at the user level: Similarly to the previous point, the mobile-first storage units should be also partitioned at the user level.
  • Elastic: A mobile-first storage must scale up and down with the number of users and applications.
  • Provisioned on-demand: Different from traditional databases, mobile-first storage units must be provisioned real time based on a request triggered by the mobile application.

 

Factoring in all those characteristics, you can quickly see how challenging will be for a traditional IT department to implement this type of mobile-first storage without building a dedicated infrastructure just for it. In that sense, many enterprise mobile solutions including enterprise mobile backend as a service platforms, provide mobile-first storage APIs that address this specific scenario.

Conceptually, this type of platforms abstract the complexities of provisioning, partitioning and scaling storage units behind simple mobile-first APIs that expose the traditional query and save operations. The following figure illustrates that concept:

storage

In that model, the storage units required at the application or user level will be provisioned based on simple Save operations initiated by the mobile storage API. In that sense, a mobile developer is simply reading or writing data without dealing with the intricacies of the storage platform.

While the mobile-first storage pattern is very common in enterprise mobile solutions is rarely sufficient to address all the data exchange-storage requirements of a typical enterprise mobile application. Typically, mobile platforms combine this pattern with other enterprise mobile capabilities such as offline storage, geo-aware routing or integration with corporate systems which will be the subject of future posts.

Enterprise Mobility Patterns: Cross Platform Push Notifications

Push notifications have become one of the most commonly used features of modern mobile applications. Enterprise mobile applications also try to frequently take advantage of push notifications interfaces as a mechanism to distribute information between enterprise systems and mobile applications. Despite its popularity, delivering push notification across the different platforms remains a challenging exercise.

Part of the challenge  is based on the level of infrastructure required to abstract the communication between popular push notification services such as Google, Apple, Microsoft and BlackBerry. The level of brokering goes beyond the integration with the different services and includes other aspects such as connection pooling, retransmission algorithms, persisting messages etc. In the enterprise, this challenge is even more relevant due to the levels of security and compliance expected on different enterprise environment,

A simpler challenge but also interesting is to find the right level of abstraction that works effectively across all the different services. In KidoZen, we borrowed constructs from traditional publish-subscribe architectures and use a channel as the metaphor that describes the unit that apps can publish or receive data from via publish notification.

From the infrastructure standpoint, a traditional pattern is to implement a cloud base service exposes a publish-subscribe API and brokers the communication between the different push notification services. Using this model, the service will receive the subscription requests to a specific channel and will route that call to the appropriate push notification services. The following figure illustrates that:

pn1

Similarly, a mobile application can publish a message to a specific channel and the push notification gateway will distribute it to the appropriate push notification services. The following diagram illustrates this concept:

pn2

In this architecture model, the push notification gateway will be responsible for enforcing the correct security, tracking and retransmission policies required by that specific channel. While the push notification gateway pattern can be implemented as an on-premise service, the use of cloud computing techniques makes it exponentially simpler to scale, distribute and maintain the infrastructure required for this type of capability

 

KidoZen Webinar: Mobilizing your Enterprise Data: Patterns, Technologies and Techniques to Access Business Data from Enterprise Mobile Apps

Join us next week, we will be hosting our next stop on our series of webinars about enterprise mobile solutions. This webinar will be centered around mobilizing your enterprise data.  We will be digging into some of the architecture patterns around enterprise data and what different technologies and techniques are available for you.  That can allow you to incorporate better design principles into your overall enterprise mobile solutions.

Wednesday, April 16, 2014 1:00 PM – 2:00 PM EDT

Webinar Registration: https://www4.gotomeeting.com/register/638676263

Accessing enterprise data is, arguably, the biggest challenge of enterprise mobile solutions. From security, privacy to interoperability challenges, enabling the communication of mobile applications and enterprise data sources is far from being an easy endeavor.

This webinar examines the different technologies, architecture models and emerging trends that enable mobile applications to access data stored in enterprise systems. The session looks at two emerging trends in the industry: mobile data virtualization and mobile data management as the new foundation of mobile data access solutions. Finally, we will explore the capabilities implemented by the KidoZen in order to facilitate enterprise mobile apps to access data from corporate enterprise systems.

KidoZen Broadens Enterprise Mobile Platform-as-a-Service Offering with Mobile Database Services for Relational & NoSQL Database Connectivity

Yahoo-logobcom_small
digitaljournal-logo
KidoZen, Inc., the enterprise mobile-first platform-as-a-service Company, today announced the immediate availability of Mobile Database Services as part of its platform offering. Mobile developers can now quickly add native connectivity from their mobile applications to ten existing relational and NoSQL databases built in Oracle, MS SQL Server and MySQL, MariaDB, MongoDB, Redis, Neo4J, CouchDB, Hadoop or Elastic Search. Read More

Announcing KidoZen Mobile Database Services

Today, we are super excited to announce the latest addition to KidoZen’s enterprise mobile platform as a service: mobile database services. Integration with corporate databases are an essential component of a modern enterprise mobile infrastructure. However, those type of integrations typically require organizations to build quite a bit of infrastructure in order to securely expose their internal databases to mobile consumers. More importantly, that infrastructure looks very different depending whether we are integrating with relational, NOSQL, New SQL or Big Data databases.

KidoZen mobile database services provide a series of mobile-first APIs to integrate mobile applications with a group of the most relevant databases systems in the enterprise. This first release includes the following databases:

db services

The support for mobile database services has been included in all KidoZen mobile SDKs. With this addition to our KidoZen platform, mobile developers can now build sophisticated mobile applications across a dozen of different mobile platforms that seamlessly integrate with enterprise databases.

This is the first of a series of releases that expand KidoZen capabilities to integrate mobile application with enterprise data.

I hope you enjoy this initial set of capabilities. If there are specific databases you would like to see supported as part of the KidoZen platform, please send us an email to support@kidozen.com. Looking forward to hear your feedback!

March Conference Events: Chicago to London

The KidoZen Team has been busy hitting the road during March. We have had the pleasure of meeting with some great people and hearing what their organizations are doing with mobile solutions and where they are hitting roadblocks within their mobile strategies and implementations.  Thanks everyone, for participating in the many great discussions on all things mobile and of course KidoZen and the benefits of using an enterprise-first mobile platform.  Also, we are grateful for getting interactive feedback on where KidoZen is going in the next few months.
Thanks to everyone that took the time to chat with us at these great events.

CDM_MobilitySummit

CDM Media’s Enterprise Mobility Summit - Slide Share

managingBYOD

Managing BYOD & Mobility - Slide Share

Accessing Business Data in Enterprise Mobile Apps

Last week I had the opportunity to speak at the CDM Enterprise Mobility Summit in Chicago. The event brought together some of the top practitioners in the enterprise mobile space as well as executives from Fortune 1000 companies. This time, we decided to focus our session in the new area of mobile data virtualization and it’s rapid adoption in the enterprise mobile space.
You can see the slide deck below:

Mobile Testing: Page Object Pattern with Multilayer Design

You probably heard about the Pros and Cons of using Automation, one of the cons often mentioned is the high maintenance and low scalability of code, hence in this post we are going to give some best practices and design patterns to follow and mitigate this.

Often automation starts with a few scripts, you got some good results and you start adding more and more test cases, then you realize you have scripts with hundreds of lines of code, and as a consequence they are not easy to read, they have a lot of repeated code and they are hard to maintain and scale. Well if you want to automate your app on a big scale, you need to understand you are basically writing a program to test a program, therefore you need to follow the same coding principles that any developer follow.

Let’s define a scenario for example an App to manage expenses, with the following basic flows:

Flow (1)

You have many screens, with many actions and interactions between screens, so let’s talk about multilayer design, you can basically define 3 layers: UI access, functional flow and test cases layer.

UI access: Here you are going to isolate how you access to fields, buttons, etc. on the application running on the device by mapping all the objects, if you are doing it on UI Automation for iOS your code will have something like this:

...
//Login Screen
var userNameField = UIATarget.localTarget().frontMostApp().mainWindow().textFields()["Username"];
var passwordField = UIATarget.localTarget().frontMostApp().mainWindow().textFields()["Password"];
var loginButtonField = UIATarget.localTarget().frontMostApp().mainWindow().tabBar().buttons()["Login"];
var errorField = UIATarget.localTarget().frontMostApp().mainWindow().textFields()["Error:"];

//Create Expense Screen
var createExpenseButton = UIATarget.localTarget().frontMostApp().mainWindow().tabBar().buttons()["Create Expense"];
var expenseNameField = UIATarget.localTarget().frontMostApp().mainWindow().textFields()["Expense Name"];
var expenseDetailField = UIATarget.localTarget().frontMostApp().mainWindow().textFields()["Expense Detail"];
var confirmExpenseButton = UIATarget.localTarget().frontMostApp().mainWindow().tabBar().buttons()["Confirm"];
...

Remember each control on the app will probably be used many many times on your tests, so why should I do this? because if and ID is changed your tests will start failing, but if you define a separate layer for UI access you only need to change the ID once.

Functional Flow: this layer will contain all the functional flows you need to perform actions on the screens e.g. to log in, you can create a function for each action and within the method, you’ll have all the interactions with the controls you mapped on the UI access layer, your code will be like this:


function userLogin(userName, userPassword){
	...
	userNameField.setValue(userName);
	passwordField.setValue(userPassword);
	loginButtonField.tap();
	...
	}

function wrongPasswordError(errorMessage){
	...
	assertEquals(errorMessage, errorField.value());
	...
	}

function createExpense(expenseName, detail){
	...
	createExpenseButton.tap();
	expenseNameField.setValue(expenseName);
	expenseDetailField.setValue(detail);
	confirmExpenseButton.tap();
	...
	}

You will have many functions with use many times the UI objects, but if one object changes and tests start failing you don’t have to worry, you only need to fix the mapping on the UI access layer once.

Test cases layer: You already have access to UI controls and functional flows, now you can use the flows to create test cases, since you have one function for each action, your test cases will be a chain of functions with their parameters, you’ll have something like this:

'A user login with correct credentials then create Expense'
...
userLogin("someUser","somePassword");
createExpense("expenseName", "someDetail");
...

'User login with wrong credentials, check error message'
...
userLogin("someUser","wrongPassword");
wrongPasswordError("wrong password!");
...

'User try login with wrong credentials,then retry, then create Expense'
...
userLogin("someUser","wrongPassword");
userLogin("someUser","somePassword");
createExpense("expenseName", "someDetail");
...

Now you can easily create test cases, you will use each flow many times, as you can see in the example, but you don’t have to worry if a flow is modified, for example: now the users have to enter an extra security code on the log in screen, they added a new textbox for that reason. Is not a big deal, you only have to add a line to map the new field and also add an extra step on userLogin function to set value on the new field. Now all the test cases that uses the login flow are working good again.

Together with multilayer design you can also implement Page object pattern, they are very related and one benefits the other. Page object pattern was thought for web sites automation on selenium but we can easily adapt to mobile apps, web sites has pages and mobile apps don’t, but they have screens .If you check the diagram with the application flows, you’ll easily figured out there are many screens that interacts each other, each screen has their own controls and their our functional flows, so why don’t put them together? Page object pattern propose to represent each screen as an object that encapsulates the functionality.

All we need to do is some re-factor on the code we have, let’s think in each screen as a class, then map only the objects that belong to the screen and also the functions that represents the functionality flows. Now we have a re-factored clean code that allow us to maintain it easily, and provide a good scalability to create many many test cases without loosing control.

JavaScript: The Most Popular (Programming) Language

 

In the last couple of years, JavaScript became the most popular programming language on GitHub.

But wait, what? Did you said JavaScript?

JavaScript have grown a very bad reputation mostly because of the bad browser implementations and because of the horrible DOM interface that came with them.

The whole story begin to change with one single man. Douglas Crockford.

He began to evangelize it with a couple of internal videos for Yahoo (like “JavaScript the programming language”, “An Inconvenient API – The Theory of the DOM”, and a couple more. I SERIOUSLY recommend everyone to watch these videos). And after that he wrote his master piece: “JavaScript: The Good Parts”.

JavaScript is the widest deployed programming language nowadays. It’s in every browser, smartphone, tablet. It’s responsible for what we called web 2.0 with its ajax stuff. It’s really amazing that the whole thing can be narrowed to the XmlHttpRequest object.

Mozilla began to pay attention to their JavaScript Virtual Machine implementation. Apple improve Safari as well.

Google Chrome’s V8: The VM breakthrough

Google developed V8, an open sourced C++ implementation of the ECMA Script 262 5th edition and everything changed. It really speed things up in JavaScript execution.

V8 was fast, really fast. And so it was Chrome. It became the fastest browser regarding JavaScript execution. But V8 was much more than just the Chrome’s JavaScript VM. V8 could be embedded in a whole new different kind of projects. In JSConf 2009 Ryan Dahl presented Node.js. He received an standing ovation, it was revolution.

Node.js reborn javascript in the server + non blocking I/O.

But let’s get back a litte.

 

The Misunderstood Language

 

As Douglas said in his book, JS has it’s share of good things and bad things. In this blog post we are making a brief summary of the things we loved about it.

  • Functions are first class citizens: You can create them, assigned them, passed them around. Once you get the taste of it you’ll love it.
  • Closures: Function objects can enclosed outer variables. This is a very powerful and yet dangerous thing. It’s still great that you can use functions this way.
  • Object Literals: How many times your preferred programming language let you create an object like this: {}? That’s all it takes to create one in JS. Or maybe you would like to add a name to it: {“name”: “SuperObject”}
  • JSON everywhere: You can create, read and pass it around with ease. Forget about old XML files. JSON native support in JavaScript it’s great.

These ones belongs to Node.js:

  • Only one language: Thanks to node.js you can build your server components and you browser client stack with just one language.
  • Module System: The “module.exports / require()” functionality it’s really simple and powerful. It let you modularize your code in a pretty simple fashion
  • NPM: Ok, this is not node.js, but it’s also great. A giant ecosystem of packages with everything you will ever need.
  • Non blocking I/O: This is the leitmotiv of the technology. Use the CPU time to do useful staff instead of waiting for I/O to be available and minimize memory footprint in the meantime.

 

Of course it has it’s fair share of bad (and someones awful) parts, but the good ones are pretty amazing.

We, at KidoZen have chosen javascript and node.js as two of our main technologies and the journey, so far, has been awesome.

 

Enterprise Mobile Patterns: App Authentication

This is the first of a series of blog posts that explore some of the most common patterns in enterprise mobile solutions. We’ve observed variation of these patterns in hundreds of solutions with KidoZen customers and we thought it might be a good idea to document some of them so that mobile developers can leverage those principles when building enterprise mobile solutions.

To keeps things entertained, we’ve decided to start with one of the most common and yet very difficult patterns to implement in enterprise mobile applications: mobile-app authentication. In this scenario, a mobile application needs to authenticate with corporate credentials to a corporate directory such as Microsoft Active Directory and subsequent tasks of the apps should be performed on behalf of the authenticated user.

From a development standpoint, authenticating mobile apps to corporate networks involves interoperating mobile applications with identity management protocols such as SAML, WS-Trust or OAuth which are the cornerstone of enterprise identity systems. Creating that level of interoperability is fundamentally challenging as most mobile application suites don’t implement those protocols natively.

From an enterprise standpoint, there are a handful of well-established practices when comes to enable mobile app authentications to a corporate network. Some of those practices include building custom authentication APIs, using app containers or leveraging enterprise mobile backend as a service (mBaaS) platforms like KidoZen.

The Custom API Approach

Arguably the most popular approach in the enterprise, this model includes a custom service API that brokers a corporate directory such as Microsoft AD in order to integrate with mobile applications. The following diagram illustrates that approach.

Auth-1

While the proposed model is fundamentally simple, it has some major drawbacks. For starters, the custom auth API approach requires an additional level of infrastructure that needs to be implemented by enterprises. Additionally, custom built authentication APIs rarely implement the complete set of identity management protocols required at the enterprise level. In that sense, many enterprise end up compromising security in order to achieve the required interoperability with mobile applications.

The App Container Approach

A model that has become popular as part of the mobile device management (MDM) systems, is to wrap mobile enterprise mobile apps into a container which is also responsible for authenticating to the corporate network. The following figure illustrates that approach.

Auth-2

The model illustrated above completely abstracts the authentication capabilities from the mobile application itself which makes the experience extremely simple from a development standpoint. However, the level of abstraction prevents individual authentication needs from specific applications as the experience is controlled at the container level. Similarly, the applications need to be designed to operate in a container mode which makes portability extremely difficult.

The Enterprise mBaaS Approach

This model has been mostly pioneered by enterprise mBaaS platforms like KidoZen. In this approach, the enterprise mBaaS will provide an identity federation layer that also provides the authentication APIs for the mobile applications. Using this model, mobile apps will leverage the authentication API of the enterprise mBaaS layer which will, in turn, federate the identity with the corporate environment. The following diagram illustrates this approach.

Auth-3

The proposed model presents a simple options for developers while leveraging the robustness of enterprise-ready identity management protocols. That pattern can also be easily adopted in public, private or hybrid cloud scenarios which makes it really appealing for enterprises.

These are just some of the most common patterns in order to enable authentication to corporate networks from enterprise mobile applications. We would love to hear your thoughts.

[x]

Contact Us

You can call us at 877-513-3113, email us at
info@tellagostudios.com or complete the following form: