Tag Archives

20 Articles

Mobile

//build/ : Wrap a Mobile API around your Enterprise and take Data Offline with NoSQL on Windows Phones and Tablets

Posted by Rob Tiffany on
//build/ : Wrap a Mobile API around your Enterprise and take Data Offline with NoSQL on Windows Phones and Tablets

For those of you who couldn’t make it to San Francisco, here’s my session on Wrapping a Mobile API around your Enterprise and taking Data Offline with NoSQL on Windows Phones and Tablets from //build/.

Enterprise mobility is a top priority for Chief Information Officers who must empower employees and reach customers by moving data from backend systems out to apps on mobile devices. This data must flow over inefficient wireless data networks, be consumable by any mobile device, and scale to support millions of users while delivering exceptional performance. Since wireless coverage is inconsistent, apps must store this data offline so users can be productive in the absence of connectivity.

In this video you’ll learn how to build fast and scalable REST + JSON APIs using the ASP.NET Web API while employing techniques such as data sharding and in-memory caching. On the device, you’ll learn how your apps can work with offline data via in-memory NoSQL tables that use LINQ to support the same CRUD operations as relational databases. You’ll walk away from this session with the ability to deliver flexible server solutions that work on-premise or in Azure and device solutions that work with Windows Phones and Tablets.

Download the two Visual Studio projects and associated source code from GitHub:
https://github.com/robtiffany/build-2014-mobile-api

Sharing my knowledge and helping others never stops, so connect with me on my blog at https://robtiffany.com , follow me on Twitter at https://twitter.com/RobTiffany and on LinkedIn at https://www.linkedin.com/in/robtiffany

Architecture

Happy Mobile New Year

Posted by Rob Tiffany on
Happy Mobile New Year

It’s a new year and therefore it’s time to throw some rapid-fire mobile architecture concepts at you to help improve your mobile enterprise systems.

 

  • For starters, developers and IT Pros involved in mobility need to start thinking holistically about backend systems, data transports, and mobile endpoints.  Working in the mobile enterprise space doesn’t mean you just get to be a “device guy.”  Remember, your CIO wants to empower her employees by moving data from any backend system out to any device.
  • Here’s my obligatory statement on keeping things simple.  Large enterprise mobile systems will get complicated enough on their own without you contributing to the chaos.
  • Take the idea of Mobile SOA seriously and wrap your enterprise in a Web API.  Your various backend ERP, CRM, and custom systems use a variety of proprietary wire protocols to communicate.  You need to make all those backend systems “mobile friendly” by having them all speak a device-agnostic language.  You all know I’ve been a REST guy for more than a decade so it’s no surprise that I want you to map those proprietary APIs to RESTful APIs.  REST is lighter then SOAP and works with all mobile devices.  For your coarse-grained APIs that send larger payloads of information, make sure to serialize that data as JSON.  JSON is lighter than XML and works with all mobile devices.  The other litmus test here is around simplicity.  If a webpage with JavaScript can consume your REST/JSON API without needing an SDK to interpret your wire-protocol, then native apps will find your API simpler to work with than a system that requires an SDK.  Remember, you’re not just building this API for mobile devices.  You’re building it for developers.  If it’s not super-simple to work with, they may not use it.
  • Some backend systems that you’re building Web APIs for are designed for serious web-scale, but most are not.  If a particular backend package already has the performance and scalability to handle millions of devices, then have your middleware Web API servers sit directly in front of them and map REST API calls directly to their proprietary APIs.  For the the majority of backend systems that are wholly incapable  of handling an onslaught of millions of devices, you need to give them some help.  You’ll need to create a server facade in front of them via a database server that includes EAI adapter capabilities along with the ability to scale out via replication.  You’ll use an adapter designed specifically to interface with the backend system in question to prefetch data from the proprietary APIs and put that data in staging tables in the database.  You’ll then shard this database via replication to scale either complete databases, tables, or parts of tables to n number of “shared-nothing” database nodes on different servers.  In this scenario, your middleware Web API servers will make calls to the various database shards to return cached data to mobile devices in order to solve your scalability problem for backend systems that need help in this department.
  • Common sense tells us that if you make your backend systems faster, then the user experience on the mobile devices will improve because users won’t be waiting around for data to arrive to fill their screen.  The first and easiest thing I want you to do is switch all your spinning hard drives to solid state drives (SSDs).  Moving all your backend systems, database servers, middleware servers, and web servers to lightning-fast SSDs will instantly boost the performance of your entire system without writing or changing a line of code.  This is a no-brainer.  The next thing I want you to do is take better advantage of cheap RAM and in-memory operations.  I want every mapped API call between your middleware Web API servers and backend systems to be cached in-memory.  If you’re using a server facade in front of backend systems, ensure the EAI/ETL capabilities of the database support in-memory data movement operations.  Likewise, I want you to use database servers that support in-memory OLTP.  All the Web API calls between your mobile devices and the middleware servers also need to be cached in-memory as well.  Last but not least, the native and web apps on your mobile devices need to cache data offline in a local data store so that users can keep working without needing to constantly call your Web APIs.
  • Implement a lightweight Enterprise Mobility Management (EMM) system in your organization.  It needs to provide things like an enterprise app store, security policy enforcement, and things to make an employee’s life easier like the simple provisioning of Wi-Fi, VPN, and email profiles.  In order for mobile apps to access the Web API you’ve built, your EMM should also support a secure gateway to access internal corporate servers via single sign-on (SSO).
  • Finally, keep investigating HTML5.  It’s the world’s most important shared technology that isn’t owned by any one company.  It works with the browsers on every mobile device and makes things like app deployment and updating easier than equivalent processes with native apps.  It supports offline operations and even includes two options of local data storage.  Web pages no longer submit/post data to themselves or other pages but use JavaScript instead.  Mobile web apps can make AJAX calls to you Web API and easily work with the JSON data that’s returned.  Mobile browsers keep getting faster and use optimizations like hardware acceleration and JIT-compiling of JavaScript to blur the lines with native apps.

Happy New Year!
Rob

Sharing my knowledge and helping others never stops, so connect with me on my blog at https://robtiffany.com , follow me on Twitter at https://twitter.com/RobTiffany and on LinkedIn at https://www.linkedin.com/in/robtiffany

Sign Up for my Newsletter and get a FREE Chapter of “Mobile Strategies for Business!”

[mc4wp_form id=”5975″]

Architecture

ASP.NET Web API: The New Mobile Web Services

Posted by Rob Tiffany on
ASP.NET Web API: The New Mobile Web Services

Those of you who know me or have attended one of my presentations know that I’m a total RESTafarian when it comes to the software architectural style I prefer for web services.

I started using REST in the early 2000s to create a high-speed, human-readable, server API to trade financial instruments between brokerages and counterparties. When SOAP finally got traction in the .NET and Java world, I started using it because WSDL and widespread tooling made it easy for people to consume the web services I had to publish. XML was having its moment in the sun. That being said, I could never get past the clear drop in performance I saw vs. the lighter-weight RESTful way of doing things.

Fast forward to to the cross-browser standardization of Ajax in JavaScript, and RESTful web services started to surge since SOAP was way too heavy for client-side web page calls. Along the way, a compact way of describing objects and collections of objects called JSON began to steal XML’s thunder as a way to serialize data. While this new REST + JSON pattern of lightweight communication and data serialization got it’s start with the web and JavaScript, it soon found a home in the surging tidal wave of devices that have proliferated over the last decade.

The slow, unreliable wireless data networks that brought Smartphones to life demanded a new level of efficiency when it came to wire protocols. While proprietary, binary protocols ruled in the early days, they finally gave way to something that could work with any device. At Microsoft, we began to make it easier for developers to create REST web services via our Windows Communication Foundation (WCF) and special toolkits in .NET 3.5 and 4.0.  I started using it because of the obvious benefits to wireless-efficiency and also so I could stop having to “roll my own” REST web services using bits and pieces of other technologies.  WCF is a Swiss Army Knife and does lots of things which sometimes makes it overkill when you need to expose simple function calls or data to the Internet via REST.

I’m thrilled to say that our newest, simplest way to create RESTful web services is called the ASP.NET Web API.  Using the power of ASP.NET MVC 4, we’ve delivered a framework that makes it easy to build HTTP services that reach a wide range of clients, including web browsers and most every Smartphone.  I’m using it now to expose enterprise data out to the Internet where it can be easily consumed as collections of JSON objects.  Mobile web browsers can retrieve this data via Ajax calls and store it offline in Web Storage.  Smartphone apps can download and store the data in local databases or serialize it to flash storage as JSON.  I like it!

Take it for a spin.

-Rob

Sharing my knowledge and helping others never stops, so connect with me on my blog at https://robtiffany.com , follow me on Twitter at https://twitter.com/RobTiffany and on LinkedIn at https://www.linkedin.com/in/robtiffany

Sign Up for my Newsletter and get a FREE Chapter of “Mobile Strategies for Business!”

[mc4wp_form id=”5975″]