Mobile Middleware Buyer s Guide

Transcription

1 white paper Mobile Middleware Buyer s Guide Paper Focus: Common enterprise use cases that benefit from using a Mobile Middleware architecture Architectural, performance and security tradeoffs Common security capabilities and recommendations for mobile enablement Checklist of concerns for prospective buyers Abstract If you re currently evaluating tooling and infrastructure middleware to rapidly expose apps to a wide range of mobile devices, this guide will assist you in the decision making process and help you make an informed choice. The first two sections describe the common business use cases where mobile middleware is deployed. The following sections of the guide contain tools you can use to identify the right fit for your enterprise based on business requirements and intended usage.

2 Mobile Middleware Buyer s Guide Executive Summary...3 The Use Case: Mobility in the Enterprise...4 Use Case 1: Employee Productivity...4 Use Case 2: External Access...5 Use Case 3: Monetizing APIs...5 A Case for Mobile Middleware...6 Integration...6 Mobile-friendly Security...7 Data Protection...8 Authentication and Identity...8 Performance...8 Developer Engagement...9 Discovery...9 Onboarding...9 Education and Documentation...9 Monitoring and Metering...9 Cross-Platform Development...10 Concluding Thoughts: Mobile Middleware...10 Mobile Middleware Checklist...11 Paper Sponsorship...12 Purpose This paper is aimed at business and IT professionals responsible for implementing a mobility program, whether it is BYOD (Bring Your Own Device) for their employees or extending a webbased engagement portal to mobile devices for customers, partners and developers. This guide aims to provide approaches that will simplify the creation of mobile apps while maintaining an appropriate level of security and user experience. Many of these approaches will also be relevant to the business looking to create new revenue streams by repackaging existing data assets and services as APIs for external developers. 2

3 Executive Summary Mobile devices are no longer simply used for voice and text communications. Nor are smartphone apps exclusively personal or entertainment-oriented. Tablets and smartphones have become enterprise productivity tools, used for all manner of business operations. As enterprises embrace the transition to mobile, they can enjoy improved productivity by exposing internal services to mobile devices and drive new revenue from exposing once internal APIs to external developer communities. Mobile middleware enables the enterprise to expose existing data and services via APIs, giving it reach far beyond the current status quo of entrenched web applications. However, in its current state the mobile web experience is lacking in performance, scalability, security and usability. Native and web-based HTML5 mobile applications are introducing more powerful experiences, but they ultimately depend on APIs for core data delivery. Mobile middleware is an emerging set of technologies that has different connotations in different contexts. Some vendors use the term to describe Mobile Backend as a Service (MBaaS), which is essentially a Platform as a Service (PaaS) tailored to the needs of mobile developers. Others define it as a collection of APIs that are readily consumable by mobile devices. We take a more expansive view, illustrated in Figure 1, considering the end-to-end solutions that support application development for mobile devices, including APIs, API management and software development. By our definition, mobile middleware is a new architectural cornerstone of the traditional enterprise software architecture, on par with traditional application servers and web server infrastructure. Service Provider or C2DM (Cloud to Device Messaging) Raw TCP over SSL Drive developer community API discovery, usage, and monitoring Enterprise Securely exposes a unified set of RESTful APIs,as well as SLA enforcement and response caching AAA API Key ID Token Mapping Federation Generates SAML assertions for web mobile SSO Sends push notification Alerts and over the air (OTA) updates iphone Android Blackberry Windows Smart Phones Android and ios Tablets Intel API Portal RESTful HTTP Communication XDK Mobile App Dev Network Firewall Load Balancer Delivers tuned content for web mobile apps Intel EAM Farm Mobile-Tuned Web Server Farm Tuned HTTP performance for millions of devices Lightweight HTTP/JSON Optimized App Server Informatica Data Transformation (Embedded in Intel EAM) Intel EAM (Client) Binary Asynchronous Messaging Component No SQL/ RDBMS Persistence Layer or MQ Fast changing data / activity streams Produces mobile-ready data formats Secure PaaS Securely brokers content from cloud providers Intel TXT Figure 1: Mobile Middleware Reference Architecture 3

4 The Use Case: Mobility in the Enterprise While mobile apps originated as diversions for playing games or consuming information, they are increasingly being used to interact with corporate Big Data. These enterprise mobile apps require enterprise-grade security and performance. When considering a mobile middleware platform, the enterprise architect must first consider the following questions: How do I best reach my target audience, whether they are employees or customers? How do I make my application work across multiple devices with multiple form factors? Are there external API and application dependencies? And if so how do I provide business continuity for my applications? How do I optimize the performance of my mobile application? How do I securely expose the data and services needed for my mobile application? How will compliance and enterprise governance affect data exposed to mobile devices? How do I incorporate additional functionality provided by external APIs? How many devices do I expect? How will my infrastructure scale? The answers to these questions require alignment across business, data, infrastructure, application and security architecture roles. Finally, with the increasing role of mobility in the enterprise, the solution must be extensible and scalable, capable of adding new applications as additional capabilities are needed. Use Case 1: Employee Productivity Mobile devices bring the potential for ubiquitous access to corporate resources, providing employees with an alwayson connection to the enterprise. , calendar and contacts are no longer sufficient for many enterprises. Lineof-Business applications with secure access to corporate data will further improve worker productivity. Due to their nature, mobile devices afford interesting productivity enhancements that increase efficiency. For example, traditional enterprises can use the location aware capabilities of smart devices to optimize internal resources such as conference room booking and other location-sensitive resources. Utilities can leverage mobile devices to provide their field force with critical outage and capacity usage information direct to smartphones and tables. Finally, organizations with a large sales force can use tablets and smartphones to assist side-by-side selling, which wasn t previously possible with traditional web applications. While the first stage of mobile access was delivered using off-the-shelf software packages, the next wave will include much more custom code. As shown in Figure 2, according to a November 2011 Forrester study more than 50% of enterprises develop their own mobile applications in-house. These applications will require access to a mix of back-end services, from existing SOAP applications to newlydeveloped RESTful APIs, as well as cloudhosted services such as salesforce.com. Figure 2: Sourcing of Mobile Apps in North American Enterprises 2011 Forrester Study 4

5 An established enterprise may already have an ESB (Enterprise Service Bus) for internal services, or they may be using loosely-coupled, point-to-point connections between apps and services. Either way, the ESB likely was not designed with widescale, mobile security or external connectivity in mind. Use Case 2: External Access For some time, many enterprises have offered their customers a self-service web engagement portal. Whether it s used for commerce, basic account management or other purposes, this portal ultimately connects back to enterprise services. With mobile browsers taking an increasing share of page views, portals that deliver substandard user experience are being re-implemented as native or HTML5 mobile applications. While the scope of services to be accessed by internal users is typically much narrower than in the employee productivity case, the scale and security considerations are much greater. Also, digital natives expect integration with external identity providers, social networking and other external cloud services. External users are also much less forgiving about user experience issues. Performance, security and availability are paramount when offering an application to customers. Use Case 3: Monetizing APIs Enterprises are beginning to find new revenue streams by exposing their internal APIs to external developers. For newer businesses such as SendGrid, Twilio or Urban Airship the API is the product. Established enterprises have two options for entering this field: Open APIs to developers in an attempt to build community and expand the user base, or directly monetize APIs to exploit a core competency that was once only available to internal line-of-business customers. Netflix is arguably the most well-known industry example of the former model. By opening their APIs, they have supported many different device types, allowing ubiquitous access to their content. As a result they have gained subscribers and increased revenue while avoiding the additional development and support costs for those platforms. Evernote, Dropbox and Instapaper are further examples of companies that have increased adoption by encouraging other developers to integrate with their platforms. Many other companies have realized that their data is an asset. Best Buy has begun to expose some of its core business processes to developers, more directly monetizing them. CitySearch reinvented itself as CityGrid, opening up its content to competing offerings. While monetization data and APIs is not new or unique to the mobile space, the rapid adoption of new devices and form factors has expanded and accelerated the opportunity. Whether you are trying to expand your customer base or identify new revenue streams, providing APIs for external developers can provide positive results for the enterprise. In order to fully realize these benefits, APIs must be secured and instrumented. Service level (SLA) enforcement, rate limiting, metering and throttling become essential capabilities. These features also enable tiered service levels, allowing finite resources to be more strategically allocated. Figure 3: Global Growth of Mobile Devices as Share of Web Traffic 5

6 A Case for Mobile Middleware Receive While legacy application delivery featured monolithic application servers and ESBs, mobile application architectures depend on a hybrid model including both web servers and application servers. For convenience we will refer to this collection of servers as API servers, meaning servers delivering web services whether through SOAP, RPC or HTTP. Also, since ESBs were not designed to be Internet-facing, a different middleware layer is required for mobile application delivery. We will refer to middleware that mediates access to web-based APIs as a Service Gateway. Furthermore, even the most mature service-oriented architectures tend to be contained within a single enterprise and are designed for behind the firewall. Service discovery can be accomplished through a centralized enterprise catalog, and entitlements granted based on a corporate-issued identity. Mobile apps, on the other hand, frequently consume APIs from multiple providers. We will refer to a catalog of a provider s APIs as an API Portal. Regardless of which use case is the primary motivator for adopting a mobilization strategy, it s clear that legacy web and data services are not readily consumable by mobile devices. An enterprise, then, has two options: Remediate each service independently, or adopt a middleware layer that can bridge the gaps to mobile access. Development cost savings from the middleware approach will depend on the number of services to be addressed and the level of integration effort required. However, by abstracting away these integration functions, enterprises can be assured that security and compliance policies are being uniformly implemented, enforced and updated no easy task if custom code is to be added to a large number of applications. Further, the mobile middleware layer provides a scalability mechanism to handle thousands of connections from mobile devices. In the remainder of this paper we will examine how a service gateway supports these use cases, delivering the core functionality of a mobile middleware strategy. In particular, we will look at how a service gateway supports integration of disparate data sources, surfacing them as a set of RESTful web services suitable for consumption by mobile app developers. We will then consider the added security and performance challenges that arise when providing mobile access to enterprise data services. Finally we will consider the developers perspective on mobile app development, exploring tools for developer engagement and crossplatform app development. Integration Leading-edge web developers expect consistency in naming and functionality across APIs from a given provider. By convention this includes exposing all APIs under a consistent URI structure, rooted at api.<provider>.com. While an API portal would enable developers to locate nonstandard URI addresses and structures, consistency is important in nurturing a developer community. At a minimum, the service gateway acts as an application-layer switch, forwarding calls to the correct real endpoint within the enterprise. However, the DNS portion of the API URI is only a small part of providing a uniform API platform. In most established enterprises, development teams have adopted a wide range of conventions, developing APIs to an ever-evolving set of standards. In order to provide a Invoke API1 Assemble Response Reply Invoke API2 Figure 4: Service Composition with Two APIs better developer experience, a service gateway can rewrite the API requests and responses, establishing a consistent façade such as REST/JSON. Adding a level of sophistication beyond simply forwarding and rewriting API calls, some service gateways are able to act as lightweight logic servers. In this model, an internal data resource such as a file or database query can be presented as a web service using a RESTful façade that is consistent with other services in the catalog. An additional consideration for mobile applications is service composition. Mobile platforms have lower processing capabilities, higher bandwidth costs and higher latency than other types of clients. It can therefore be much more expensive for a mobile application to make multiple API calls. Service composition is an advanced service gateway capability in which the gateway performs a mash-up of two or more web services, transparently aggregating them into a single web service call. By supporting this aggregation, some logic functions can be performed within the gateway, avoiding the build-out of additional application servers. 6

7 Browser Web Server Web Server Web Server Master Slave 1 Slave N Figure 5: Traditional 3-tier Web Architecture Presentation Logic (application) Persistence HTML5 & Native Apps Service Gateway Delivery & Governance Logic (application) Master Slave 1 Slave N Persistence Figure 6: 2-tier, App-Optimized Architecture Mobile-Friendly Security Mobile applications are typically intended for use outside of the corporate network. This requires the enterprise to expose APIs and web services to the Internet, where previously they were made inaccessible by the corporate firewall. While it is a good practice to protect even inward-facing services, the likelihood of a malicious attack is orders of magnitude higher for external-facing APIs. Even if these services were previously exposed through a web portal, additional security must be considered. Most modern web portals adopt some variation on the classic three-tier architecture, in which only the presentation tier is exposed to the Internet. On the other hand, many web services place business logic at the endpoint, exposing the server. Furthermore, the API server will have access to a database, so a compromised server can lead more directly to data loss. Figure 7: Multi-gateway Architecture for Internal Services A Service Gateway allows the enterprise to minimize the attack surface for the mobilization program. Rather than having to protect one or more servers for each external-facing API, the proxy model results in a single server or cluster responding to external traffic. The actual web services can then be further restricted only allowing connections to the gateway and to internal systems inside the DMZ or corporate intranet. A variation on this model, illustrated in Figure 7, uses a pair of gateways to securely expose internal APIs while eliminating the need for a duplicate instance of the API deployed to the DMZ. This involves deploying one gateway inside the DMZ and a second gateway inside a secure enclave. Inbound traffic Mobile Client Gateway 1 is permitted to access the first instance, while the second instance only accepts traffic from the first. It should be noted that this is only feasible with gateways that can be deployed on-premise due to the need to securely host one gateway inside the secure enclave. Use of a security gateway also makes it easier to implement and enforce consistent security policies for all APIs. Instead of adding custom code to each API or tuning each server individually, a consistent set of checks can be performed at the gateway layer. For example, an enterprise can define a package of checks that includes SQL injection scanning, overflow scanning, and cross-site scripting prevention. Gateway 2 API API API Server API Server Bastion Host DB Server Admin User INTERNET DMZ SECURE ENCLAVE CORP INTRANET 7

8 Figure 8: OAuth to Enterprise Identity Mapping Active Directory OAuth Dance over SSL TLS with Mutual Auth Native Mobile Applications or API Call Gateway Maps OAuth Credentials to User Names Enterprise Application Exposing REST API Data Protection Many retail operations are using mobile point of sale as a means to better serve their customers through a more efficient checkout process. Some companies, such as Nordstrom, are deploying tablets or smartphones equipped with credit card readers throughout their stores. Other companies, such as Apple, allow customers to checkout on their own mobile devices. In both models, payments are being accepted over a wireless network and must be protected differently than they were in the old point-of-sale model. In order to maintain compliance with the Payment Card Industry (PCI) guidance for handling of payment card information, credit card details should be tokenized. Other industries that deal with personal information, such as healthcare, also have a need to protect sensitive information, either through encryption or tokenization. A gateway proxy with encryption and tokenization support can improve security for these uses while reducing audit scope. The gateway maintains the secure mapping of actual card data to tokens, which means that the tokenization capability doesn t need to be implemented elsewhere. Authentication and Identity Identity management frequently slows mobile application enablement. While most enterprises have standardized on a centralized identity stores and may have experience with NTLM for web-based applications and X.509 or SAML web service security, none of these are viable for mobile devices. While it is possible to construct an authentication mechanism using basic HTTP auth and/or SSL to pass user and password information to the server, these aren t terribly secure. Worse, they potentially alienate both developers and users alike because they aren t standard or frictionless OAuth is the de facto standard for web and app authentication. Adopting this standard is intuitive for both users and developers. However, enterprise applications are not likely to support OAuth. Nor is it a viable replacement for Active Directory. A gateway can address this disconnect by bridging OAuth to an enterprise identity management system (e.g. Active Directory), mapping users to OAuth credentials. Performance Up to this point we have focused on the benefits of employing a web service gateway for mobile applications. However, there are potential risks and drawbacks to this architecture. Performance is the primary concern: Introducing an additional level of indirection and logic can result in both propagation and computation latency. Propagation latency is the easier of the performance challenges to anticipate and avoid. Service gateways are typically available in two models: SaaS or On- Premise (see Figure 9). With SaaS, the service gateway resides in the cloud, so all API requests will route from the client, through a cloud provider, and back to the API endpoint. This potentially adds a hundred milliseconds or more of latency to each API transaction. An on-premise deployment eliminates this propagation latency, as the gateway and API endpoint are within the same data center. Even cloud-hosted APIs aren t immune to this additional propagation latency: One would have to select the same cloud provider, region and availability zone as one s service gateway in order to minimize latency. This would mean ignoring other decision factors such as proximity to application users, cost and service level agreement. Increased computation latency and decreased throughput are also risks when deploying a service gateway. Each operation the gateway performs on an API call takes time and consumes resources. Implementing a complex workflow at the gateway layer can dramatically impact the response time, degrading performance. As gateway performance varies between products, it is important to look carefully at the optimizations offered by the vendor. Some examples include hardware acceleration for cryptographic instructions and efficient software for XML/JSON processing. 8

9 Internet (latency) Service Gateway Master Slave 1 HTML5 & Native Apps Delivery & Governance ENTERPRISE PRIVATE CLOUD Logic (application) Slave N Persistence Figure 9: Latency considerations for on-premise Browser Internet (latency) Web Server Web Server Web Server Internet (latency) Master Slave 1 Slave N Figure 10: SaaS gateway offerings PUBLIC CLOUD Presentation Logic (application) ENTERPRISE PRIVATE CLOUD Persistence Developer Engagement Once the organization has securely exposed a set of APIs for mobile app development, the next step is to ensure that developers can use them effectively. This starts with discovery, but also includes onboarding, education, monitoring and metering. An API portal typically handles these functions. Discovery The core role of an API portal is to serve as a service catalog of APIs. The portal contains a list of available APIs, along with information such as SLA, subscription information and other relevant details for prospective developers. When evaluating portals, consider the developer experience: whether it is easy to locate APIs and understand any constraints on use. Also look for a solution that can provide cookbook examples to help kickstart the development process for your environment, fostering best development practices. Finally, since this is the entry point for the developer, consider whether the solution can be skinned to conform with your corporate identity and branding standards. It is worth noting that a portal can be as valuable to internal developers and internal-facing APIs as it is for external-facing applications. In large organizations, organizational barriers and lack of communication can often result in duplicate development efforts. A centralized repository of APIs and a corresponding set of mobile client app examples can help internal developers more efficiently identify reuse opportunities, reducing wasted effort. Onboarding Once a developer has decided to use an API, the next step is to request access. Access to the portal should be able to be restricted to the enterprise if no external developers are planned. On the other hand, if APIs are to be exposed externally then the portal should be able to authenticate developers and secure their agreement to terms of service before granting an access token or key. Education and Documentation App developers seek documentation from a number of different sources: Blogs, discussion forums and wikis augment and often supersede official information sources. These sources vary widely across development communities. When evaluating API portals, it is advisable to seek flexibility and extensibility, ideally with the ability to link to external documentation sources to augment any native capability. Collaborative portals i.e. portals allowing documentation to be crowd-sourced can also foster a sense of community across a developer base. Community contributions can also improve the quality of documentation by incorporating realworld usage scenarios and sample code. However, having great documentation available is not the same thing as having it accessible. In order to ensure that developers can locate the information they need when they need it, a portal should also incorporate search functionality. Finally, developers often like to experiment with actual examples or code snippets. An API portal with the ability to execute calls directly from the documentation will allow the developer to more readily digest examples without switching back and forth between the portal and the development environment. Monitoring and Metering Whether exposing APIs to employees or to external developers, performance and usage indicators are essential. In either case, API usage is an indicator of popularity for apps and for the APIs themselves. This data is also useful for capacity planning. These become more critical when charging for access in that developers typically pay for what they use. Both the API provider and the app developer should therefore have clear visibility of usage over time. Even for free APIs, usage information will help identify what is or isn t popular, suggesting areas for future investment. Other metrics, such as documentation access and API error rates can provide an opportunity to proactively respond to issues. 9

10 Cross-Platform Development The final component of the mobile middleware stack deals with app development. There have traditionally been two approaches for enabling mobile access: web browsers and native apps. Web browsers, as previously discussed, deliver poor user experience in many cases. Native apps, however, tend not to be portable due to lack of consistent language, feature and SDK support from the underlying platforms. Intel API Manager Portal (on-prem or SaaS) ios* Amazon* Android* Windows* 8 Nook* Intel XDK on software.intel.com/html5 Developer Apps Facebook* Appup* Chrome* WebApp HTML5 has emerged as a viable source to create apps targeting multiple mobile devices, and take advantage of native features such as the accelerometer and location awareness. This approach has the benefit of leveraging the vast community support of HTML5 and the availability of numerous libraries and frameworks with business friendly licenses. Once built and packaged, HTML5 based apps can be distributed and accessed on mobile devices during runtime just as you would native mobile apps. Mobile app developers go through a development cycle involving architecture/ design -> program -> test -> debug -> package -> on-device test -> push updates. A significant portion of the development cycle - other than on-device testing - is done on the desktop. Challenges faced by HTML5 mobile app developers include the following: Ability to emulate multiple devices and screens during the development cycle to create apps that are responsive Ability to emulate features that are native to the mobile device, such as location on the desktop development platform Figure 11: Client Development Workflow Creating packaging targets for multiple deployments such as ios, Android, Windows or Tizen Achieving optimal performance on native devices Developers may also have needs for automation tools to assist in migrating apps from an existing native format such as objective-c to HTML5. Concluding Thoughts: Mobile Middleware The rapid growth of mobile devices presents enterprises with new opportunities to empower their employees, engage their customers and tap new revenue sources. APIs are the catalyst that can enable these changes. Securely exposing APIs beyond the corporate firewall can introduce new risks, and can result in poor user experience if not done carefully. It can also be challenging to keep up with mobile device vendors as they innovate with new form factors and platform capabilities. Mobile middleware can ease this transition, providing security, metrics, developer support and cross-platform compatibility. This is a relatively new field, with few comprehensive, enterprisegrade offerings. Our intent with this Buyer s Guide has been to offer a set of recommendations that will aid the enterprise evaluating solutions for API management as they begin to expose new and legacy services to mobile devices. 10

11 Mobile Middleware Checklist The table below may be helpful when reviewing internal and service provider tokenization options and when comparing vendor solutions. Table 1: Mobile Middleware Checklist Task or Feature Preparation Are you deploying apps aimed at employees, customers or both? Provider Response Have you documented the initial set of internal APIs to be exposed? Are your existing APIs using SOAP or REST, XML or JSON? APIs & Integration Does the solution offer the ability to mediate the necessary formats, such as SOAP to REST and/or XML to JSON? Does the solution support filtering an API call to limit the data being exposed through the firewall? Does the solution allow an API to be presented that is actually composed of a mash-up of multiple API calls on the back end? Does the middleware support JSONP for HTML5 based mobile applications? Do you support making data available internal systems such as Microsoft SharePoint, Oracle e-business Suite and SAP direct to mobile devices? Do you support secure integration with analytics systems, such as HBase and Hadoop, for exposing analytics information to mobile devices? Do you support making data available to mobile devices from traditional database systems? Do you support throttling of API calls based on identities, location and service level? Do you support mediation of protocols to surface legacy services such as SOAP, JMS, FTP, Raw TCP and Custom protocols as RESTful APIs? Do you support high-performance, full-duplex protocols such as WebSockets? Do you support multiple deployment options for an API developer portal, SaaS and On-Premise? Do you support translation of legacy data format to JSON, such as Word, Excel, PDF, HL7, EDI, Flat files and proprietary binary formats? Security Do you support tokenization of credit card data (PAN data)? Do you support McAfee Data Loss Prevention (or similar)? Do you support integration with a FIPS hardware security module? Do you support high performance SSL termination and acceleration? Do you support content attack protection for HTTP, XML and JSON based threats on inbound API calls? Do you support message level security and format preserving encryption (FPE)? Do you support anti-virus and anti-malware checks on inbound data? Do you support adaptive Denial of Service protection? Do you support API Key-based authentication? Do you support OAuth 2.0? Can you support multiple form factors? Hardware appliance for DMZ security and virtual appliances for cloud deployments? Do you support mapping from API keys to traditional enterprise identity management credentials such as LDAP, Active Directory and Kerberos Tokens? Other Issues Is security expertise a core strength of the solution provider (or the enterprise if solution is internal)? Is the provider financially sound? Have you updated your risk assessment (PCI Requirement ) to reflect tokenization and potential risk if tokenization vendor or application is compromised? Have you updated security awareness training (PCI Requirement 12.6) to reflect tokenization? Will the vendor acknowledge in writing their responsibility for protecting your PAN data (PCI Requirement 12.8)? Have you updated your incident response plan (PCI Requirement 12.9) to reflect tokenization (e.g. tokenization failure; vendor failure; physical or logical breach)? 11

12 Paper Sponsorship Intel and Mashery co-sponsored the production of this Buyer s Guide in order to illustrate the many facets of an enterprise mobile application development program. Intel and Mashery have introduced the Intel Expressway API Manager, powered by Mashery, an enterprise-grade platform for securely exposing enterprise APIs to mobile devices. The Intel HTML5 Development Environment addresses development cycle challenges with the Intel XDK - Cross platform development kit enabling write it once, deploy to many apps. Intel HTML5 App Porter Tool - BETA (for Windows 8*) is a stand-alone application that helps mobile developers translate portions of their application from ios to HTML5. About Intel Expressway Service Gateway Intel Expressway Service Gateway is a software appliance designed to securely expose or consume application services/apis on-premise or in the cloud. The product implements the mobile middleware design pattern that bridges the gap between legacy apps and the sea of heterogeneous mobile platforms, operating systems and programming languages used today. The traditional 3-tier web architecture is collapsed into a single application proxy that handles all API and service security, including OAuth, secure integration and mediation to external cloud services, high performance data translation, especially for JSON content. About Mashery Mashery is the world s leading provider of API technology and services. Mashery has helped more than 175 top brands including USA TODAY, Comcast, Hoover s, Klout, Associated Press, RDIO and Travelocity take advantage of APIs to build new revenue channels, speed time-to-market and spur innovation. Mashery s unique, holistic approach to API management encompasses working with clients to craft profitable platform strategies, ensuring fast, reliable API access and facilitating relationships with our network of 200,000 developers. About Intel Expressway API Manager (powered by Mashery) For API Management, Intel has packaged the market leading Mashery API sharing portal with Intel Expressway Service Gateway to deliver Intel Expressway API Manager. The seamless integration of an on-premise gateway for API enablement coupled with a hosted API management service provides the ideal, best-of-breed architecture for enterprises looking to maximize security, performance and developer adoption for their API assets. More Information Intel API Resource Site: cloudsecurity.intel.com Mashery: mashery.com Intel XDK: Americas: asipcustomercare@intel.com INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. UNLESS OTHERWISE AGREED IN WRITING BY INTEL, THE INTEL PRODUCTS ARE NOT DESIGNED NOR INTENDED FOR ANY APPLICATION IN WHICH THE FAILURE OF THE INTEL PRODUCT COULD CREATE A SITUATION WHERE PERSONAL INJURY OR DEATH MAY OCCUR. Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked reserved or undefined. Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice.do not finalize a design with this information. The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order. Copies of documents which have an order number and are referenced in this document, or other Intel literature, may be obtained by calling , or by visiting Intel s Web site at Copyright 2013 Intel Corporation. All rights reserved. Intel, the Intel logo, and Xeon are trademarks of Intel Corporation in the U.S. and other countries. *Other names and brands may be claimed as the property of others. Printed in USA Please Recycle MMW-White-Paper