Mobilize Your SOAP Services...Comparing SOAP and REST SOAP and REST serve similar purposes in architectural terms. Both enable software applications to call on web services to retrieve

Mobilize Your SOAP ServicesDeliver RESTful APIs for Mobile Consumption Using Existing SOAP Services

© 2001 - 2015 Akana, All Rights Reserved | Contact Us | Privacy Policy

© 2001 - 2015 Akana, All Rights Reserved | Contact Us | Privacy Policy 2page

Mobilize Your SOAP ServicesDeliver RESTful APIs for Mobile Consumption Using Existing SOAP Services

Abstract: The rise of smartphones has led businesses to develop corporate mobile apps. In turn, app developers are seeking access to enterprise systems. This is a good thing. Businesses can find myriad new channels and alliances through connection with the sprawling mobile app ecosystem. However, provisioning access to mobile apps can be a challenge in terms of security and performance. RESTful APIs are the lingua franca of the new mobile app, but few enterprise systems are configured to support these interfaces. The good news for architects is that API Management solutions can easily deliver RESTful APIs from existing SOAP web services. This paper discusses a proven approach for extending SOAP services for mobile app consumption with RESTful interfaces. This SOAP-to-REST architecture relies on the workings of a complete API lifecycle management solution.

Contents

Introduction ..... 3

The Corporate App Wave ..... 3

The Big Disconnect ..... 4

The Disconnect in Historical Context ..... 4

Comparing SOAP and REST ..... 5

Does it Matter? ..... 7

Making the Connection ..... 7

Managing the SOAP-to-REST Architecture ..... 10

Conclusion ..... 13


IntroductionThe rise of smartphones has been matched by a surge in corporate mobile app development for both internal and external uses. This is good for businesses, which can harness mobile technology for myriad new channels and alliances. Developers of mobile apps seeking access to corporate backend systems, however, often face a disconnect. Mobile apps frequently use the Representational State Transfer (REST) protocol to interact with other systems, while corporate infrastructure commonly uses Simple Object Access Protocol (SOAP) and other XML-based models. RESTful APIs are the lingua franca of the new mobile app, but few enterprise systems are configured to support these interfaces. SOAP, though excellent for many aspects of the service-oriented architecture (SOA), is considered too complicated and bulky for use with mobile apps. As a result, provisioning back end system access to mobile apps can be a challenge. API Management solutions can easily deliver RESTful APIs from existing SOAP services. This paper discusses a proven approach to extending SOAP services for mobile app consumption with RESTful interfaces by transforming their content to REST.

The Corporate App WaveWe are in the midst of a huge surge in smartphone adoption, with smartphone shipments exceeding those of feature phones for the first time in Q1 of 2013.1 CCS Insight projects that 53% of the 1.86 billion shipped in 2013 will be smartphones.2 More than half of mobile phones used in Western Europe and North America are smartphones, a figure that is projected to top 80% by 2015.3

Smartphones and mobile computing growth is affecting the direction of corporate information technology (IT). While the most popular mobile apps are connected to social sites such as Facebook and Instagram, and communication tools like Skype4, corporations have begun investing

in apps that serve operational and strategic objectives. Corporate apps fill internal and external uses, according to Mobile Enterprise Magazine. Internally, the “Bring Your Own Device” (BYOD) trend, wherein corporations allow employees to use whatever mobile device they prefer for work, is stimulating the development of mobile apps for a workforce that is perpetually on the move. Businesses are developing internal mobile apps for business intelligence (BI)5, customer relationship management (CRM), dispatch, work orders, travel and expense, and so forth. The Forrester 2013 Mobile Workforce Adoptions Trends Report captures the spirit of mobility that is pervading the corporate work culture, noting that 37% of US and European workers work from three or more location. Fifty-three percent use more than three devices, while 82% use more than 7 apps for work6. Gartner predicts that 90% of organizations will support corporate (B2B as well as B2C) apps on numerous personal devices, including PCs, tablets and smartphones by 2014.7

Externally, the data show a corporate world feverishly working on connecting with mobile consumers and business partners. The Mobile Enterprise study discovered that 42% of businesses were developing business-to-business (B2B) apps for partners or enterprise customers in 20128. Social networking and location based services also ranked high in the survey, with more than 30% of businesses creating these types of apps.9 B2C apps also loom large. Indeed, consumer apps such as Skype that have a strong business use case are quite popular. Skype is the 5th most downloaded free iPhone app of all time.10

This push for corporate apps is translating into significant investment. According to Forrester, firms will invest increasingly in mobile process reinvention and app development services, with spending projected to reach $7.6 billion and $5.6 billion for process reinvention and app development, respectively, by 2015.11 Another Forrester study predicts that smartphone/tablet front end apps budgets, which were 2% of global IT spend in 2011, will reach 15% by 2016.


The Big DisconnectCorporate apps need to connect with back end systems. For example, in the leading corporate app category of BI, the app has to be able to request data from enterprise data stores. This presents a problem in most cases. The mobile app is invariably designed to interact with other systems using the REST protocol and JavaScript Object Notation (JSON). The enterprise system, if it’s linked to the outside world at all, mostly likely uses one of several dominant modes of enterprise messaging, such as Message-oriented-Middleware (MOM), Java Messaging Service (JMS), or SOAP, a form of XML that has become popular in recent years in the development of Service-Oriented Architecture (SOA). REST and SOAP don’t interact naturally.

The Disconnect in Historical ContextThe SOAP-REST disconnect is a bit ironic. SOA was billed as a revolutionary advance in interoperability that would enable simple, easy data exchange and procedure calls between any software programs anywhere in the world regardless of operating system, software language or network. SOAP is thriving in the enterprise. However, mobile app developers prefer not to use it. For one thing, SOAP, though versatile, can be more difficult to program with than the lighter REST/JSON related formats. And, SOAP uses more processing power, so it’s not well aligned with simple mobile device processor chips or limited batteries.

For the purpose of solving the challenge of the SOAP-REST disconnect, it’s helpful to understand the history of the two protocols and the problems they were designed to solve. SOAP and related Web Services standards, such as Web Services Description Language (WSDL) were developed in the 1990s to provide a new, better way for distributed systems to share data and procedure calls. Virtually all major technology vendors adopted

SOAP and WSDL as open standards in what was a true revolution in interoperability. The vision was to enable enterprise architects to build a service-oriented architecture where software applications could be exposed as standards-based web services, accessible by any other application anywhere using SOAP.

REST is slightly newer than SOAP. The concept was introduced in 2000 by Roy Fielding, the noted computer scientist who has influenced the development of many World Wide Web standards. REST was, and remains, a core architectural principle for the web in general. That was the primary intent behind the development of REST. However, REST has recently gained traction as an alternative to WS* and SOAP-based web services for consumption within mobile devices, the “Internet of things,” and many open-web customer-facing use cases.

Comparing SOAP and REST SOAP and REST serve similar purposes in architectural terms. Both enable software applications to call on web services to retrieve data or make procedure calls. Comparing them is a bit like stacking a helicopter up against an airplane, though. They both fly through the air, but in different ways. SOAP and REST each have their advantages and drawbacks depending on use case.

SOAP is a protocol that uses Extensible Markup Language (XML) to transmit messages over a variety of transport protocols, including HTTP, TCP, IBM MQ (MOM), FTP, Java Message Service, and others. SOAP web services capabilities were built into most major software development tools, including Microsoft Visual Studio .NET and IBM Rational DeveloperWorks. Opinions vary on the overall success of SOA but the consensus is that SOAP is a high degree of application integration at relatively low related standards, known as WS*, have been adopted for


security, policy management, message routing, and so forth making SOAP enterprise-friendly. Figure 1 shows this enterprise-to-enterprise (E2E) approach to service-oriented architecture.

REST works on top of the HTTP transport. It takes advantage of HTTP’s native capabilities, such as GET, PUT, POST and DELETE. When a request is sent to a RESTful API, the response (the “representation” of the information “resource” being sought) returns in either the JSON, XML or HTML format. A RESTful API is defined by a web address, or Uniform Resource Identifier (URI), which typically follows a naming convention. For example, imagine that MySoles.com, an online shoe store, wanted to allow a mobile app to have access to its product catalogue database, it might create a RESTful API with a URI of http://api.mysoles.com/catalogue. The mobile app developer could pull the catalogue onto the app by writing an HTTP request of “GET” to this URI. To get a specific item from the catalogue, the developer would write GET to a version of the api that contained the product number, such as the following: http://api.mysoles.com/catalogue/[sku]. When the RESTful API received the HTTP request, it would return the product information in JSON or some other web standard format. Figure 2 captures this basic B2M architecture.

If MySoles.com made its catalogue database available as a SOAP web service, the app developer would need to download the WSDL for the web service and learn how to code a SOAP request specifically for the shoe catalogue. If the SOAP web service were located at http://ws.mysoles.com, the SOAP request would look something like this:<soap:Envelope

xmlns:soap=”http://www.w3.org/2001/12/soap-envelope”

soap:encodingStyle=”http://www.w3.org/2001/12/soap-

encoding”>

<soap:Body xmlns:m=”http://ws.mysoles.com”>

<m:GetSKU>

<m:SKU>Jimmy Choo</m:SKU>

</m: GetSKU>

</soap:Body>

</soap:Envelope>

Figure 1The enterprise SOA - an E2E construct with application exposed as SOAP web services.

Company A Company B

ERP

CRM

BI

WebService

ERP

WebService

WebService

WebService

MOM

JMS

Figure 2 The basic REST architecture in business-to-mobile (B2M) mode. The mobile app sends an HTTP request to the RESTful API that fronts the web application. The web application responds with a JSON message.

WebApplication

RESTful API

B2M

APP

HTTP Request

JSON


In order to write this request, the developer has to know the name of the variable (SKU) and how to format the request so it will return the right information. Fundamentally, REST involves a lot less coding to accomplish the goal of accessing an information resource or requesting a procedure. These qualities make REST a great deal simpler to work with than SOAP, though they present their own limitations.

John Mueller, writing for the SmartBear blog, does an excellent job of contrasting the relative advantages of the two protocols. According to Mueller, SOAP is the “heavyweight choice” for web service access, with several advantages over REST in an enterprise context, including:12

• Independence of language, platform and transport. (In contrast, REST requires HTTP)

• Works well in distributed environments, such as the enterprise. (REST assumes point-to-point)

• Well-standardized after more than a decade of serious enterprise use

• Pre-build extensibility with WS* standards

• Built-in error handling

• Automation when used with certain languages

REST is easier to work with and more flexible:

• No expensive tools needed in order for interaction with web services

• Shorter learning curve

• More efficient (XML, used in SOAP messages, is longer than REST’s message formats)

• Faster, with less processing required

Does it Matter?Given REST’s distinct suitability for the web, it should not be surprising that app developers, whose focus has been mostly on consumer use cases, would prefer REST over SOAP. Conversely, SOAP, with its maturity and extensibility, is a natural in the enterprise. When it comes to figuring out how best to expose enterprise systems to mobile apps, though, does it really matter? Mobile app developers use REST. Enterprise applications

are generally not exposed using RESTful APIs. If they are available as web services, they are most likely based on the SOAP protocol. Mobile app developers are not going to start developing for SOAP web services. Enterprises are not going to rush to replace massive earlier investments in SOAP even with the advent of mobile apps. Neither side is switching. What can be done about this?

Making the ConnectionThere is every reason to be optimistic that the gap can be spanned between SOAP-based web services in the enterprise and the surging wave of corporate apps. The secret is to let everything be. Let SOAP be the application integration powerhouse in the enterprise. Let REST be the dominant mode of interaction in the mobile app world.

The most viable approach to connecting mobile apps with enterprise back end systems is to transform the existing SOAP web service into a RESTful API. This way, the SOAP service can stay in place, doing what it does, but the mobile app can easily access the data and procedures it needs.

Figure 3 shows this enterprise-to-mobile (E2M) approach to transforming SOAP web services as RESTful APIs. In this case, developers at the business depicted by the enterprise applications on the left side of the figure would create RESTful APIs for each web service they wanted to make available to mobile apps. The app calls on the RESTful API using an HTTP request, as is the norm for REST. Using special tooling, such as the Akana API Gateway, the RESTful API transforms the HTTP request into a SOAP message that can be parsed by the SOAP web service. The response is then transformed from SOAP to JSON and routed back to the mobile app.

The Akana API Gateway and comparable products provide several additional, necessary functions for an effective E2M architecture. One is that SOAP web services called by RESTful APIs should be mediated and transformed to other formats, such as MOM and JMS. In the scenario


Once the SOAP to REST transformation is possible, a business can implement more sophisticated corporate mobile programs. Figure 4 shows a use case where a manufacturer exposes its SOAP web services through set of RESTful API. With this setup, the distributors can develop mobile apps that enable their customers to tap directly into the manufacturer’s back end systems. This is a generic use case, but it could be visualized as a tire manufacturer allowing tire store customers to use a mobile app to place orders for tires. The app can also be used to change orders, confirm payments, cancel orders, and so forth. The mobile app communicates with the manufacturer’s systems using the RESTful API, but the actual order processing and so forth is handled by SOAP web services that communicate with the ERP and general ledger systems.

The kind of enterprise-to-mobile/enterprise (E2ME) approach shown in Figure 4 is emblematic of how businesses can harness the potential of the smartphone revolution. All of the power inherent in the enterprise SOA can now be made available to mobile apps using a protocol that app developers prefer. The manufacturer can tap into the power of apps without having to reinvent its SOA.

shown in Figure 3, messaging between the ERP and CRM systems is done using MOM. The Akana API Gateway can provide this kind of mediation. When this kind of mediation is occurring, the entire enterprise architecture can interact with the outside, RESTful world without having to rethink internal messaging.

Security mediation is another factor that must be addressed in the REST-SOAP connection. B2B functionality, especially those involving financial transactions are subject to a degree of security that is not typically addressed by REST. For example, if a RESTful API gets a “POST” message, does that mean that an order is being placed by the message sender? Who is the message sender, anyway? The API documentation must be clear on exactly what the POST message means. The sender of the POST message needs to authenticated and authorized if there is a transaction pending. Otherwise, a number of unacceptable security risks arise. Akana’s API Gateway is unique in that it can make all of this functionality possible on a single management infrastructure that takes care of RESTful APIs, SOAP services, as well as MOM and JMS transformation requirements.

Figure 3Reference architecture for enterprise-to-mobile (E2M), where HTTP requests sent by mobile apps to RESTful APIs are transformed into SOAP for consumption by existing enterprise web services and conversion into MOM and other message formats SOAP responses are then transformed into JSON.

ERP

CRM

BI

WebService

WebService

WebService

MOM

JMS

APP

HTTP Request

JSONTran

sfor

m

Tran

sfor

m

Tran

sfor

m

RESTful API

RESTful API

RESTful API

Figure 4 SOAP web services in the enterprise can be invoked by corporate apps from third parties using RESTful APIs. In this case, a company makes its ordering systems available to apps developed by distributors, who in turn provision the app to end users. This is an Enterprise-to-Mobile/Enterprise (E2ME) approach.

Customers

RESTfulAPI

CustomersOrders

Invoices

TransactionsRevenue

Cash Journal

GeneralLedger

ERP

Orders

DISTRIBUTOR

App

OrderChanges

DISTRIBUTOR

App

OrderCancellations

DISTRIBUTOR

App

PaymentConfirmations

DISTRIBUTOR

App

PO Copyto Client

DISTRIBUTOR

App

RefundConfirmation

DISTRIBUTOR

App

PO Info

Payment Info

Order Info

Change Info


Akana takes on the challenge of API management. The Akana API Management Solution approaches APIs from a complete lifecycle perspective, ensuring that APIs are serving their intended purposes at every stage of life from planning through development, deployment and retirement. Figure 5 shows how this API lifecycle progress is managed by the Akana solution.

Planning

• Controls designed in at planning stage.

• Compliance policies defined.

• Stakeholder input.

Plan

Development

Build

Operations

• Dev/Test/Production barriers defined and enforced.

• API launched to production with policy binding.

• Monitoring and reporting on access/audit logging of usage.

Run

Community

• API shared only with authorized developers.

Share

• Develop for controls and security policies.

• Understand dependencies.

• Stakeholder awareness of development progress.

All pieces of the API management process should connect to one another across the API’s Lifecycle. Unfortunately, some API management solutions are relatively piecemeal in their approach, with loose components that can be deployed at various points in the Lifecycle without coherent awareness of the overall process. For example, a solution might make it possible to monitor inbound traffic and conduct authentication for access to an API. However, that solution does not necessarily “know” if the API in question has been replaced or retired.

Figure 5

Management of the API Lifecycle for connecting existing SOAP web services with mobile app developers

Overall, SOAP-to-REST transformation offers a number of advantages for businesses that want to extend their existing SOA into the mobile app space:

• Speed – SOAP-to-REST is not a push button process, but it can be done a great deal more quickly than going back to the IDE and writ-ing wholly new RESTful APIs for enterprise systems. Business that want to exploit mobile need to do it soon, not in a year. It can be done now. And it’s needed now. Not a year from now.

• Pragmatism – Building RESTful APIs on top of existing SOAP infra-structure allows a business to move into mobile while still using existing SOAP developer tools as well as SOA security and gover-nance platforms.

• Cost – Transforming SOAP into REST is cost effective. The invest-ment has already been made in the SOAP service. There’s no rea-son to rip it out. Similarly, investments in tooling and management platforms for SOAP can persist as the company implements SOAP-to-REST transformation.

Managing the SOAP-to-REST ArchitectureEffective SOAP-to-REST transformation doesn’t just happen. APIs that expose enterprise systems need to be managed across the full API life cycle. If API access is unrestricted, it is nearly impossible to regulate load on the APIs and secure them against all kinds of threats. In a large, complex corporate API ecosystem, unmanaged APIs are sure to result in service outages, frustration and inefficient use of IT support resources. From a business perspective, unmanaged APIs pose a risk of suboptimal execution, with the app community experiencing confusion and losing interest in developing apps that can take advantage of APIs to realize business objectives.


(Endnotes)

1 Dusan Belic, IntoMobile - Mobile phone sales to reach 1.86 billion this year; Smartphone sales to account for more than a half citing CCS Insight data.

2 ibid3 ibid4 http://blogs.wsj.com/digits/2013/05/03/meet-apples-top-25-most-downloaded-

free-apps/5 Tony Rizzo - Mobile Enterprise Magazine The Top Ten Mobile Apps in the Enterprise -1/1/126 Forrester Research - 2013 Mobile Workforce Adoptions Trends Report7 http://www.gartner.com/newsroom/id/25293158 Tony Rizzo - Mobile Enterprise Magazine The Top Ten Mobile Apps in the Enterprise -1/1/129 Ibid10 http://blogs.wsj.com/digits/2013/05/03/meet-apples-top-25-most-downloaded- free-apps/11 Forrester Research “Mobile App Internet Recasts The Software and Services

Landsacpe” March, 201112 John Mueller – Understanding SOAP and REST Basics – SmartBear Blog, 2013

Conclusion Extending SOAP services for mobile consumption is about making sure that RESTful APIs serve business needs are built right and controlled but not excessively restricted. Making this happen involves selecting the right API management solution. That solution needs to work across and connect each stage of the complete API Lifecycle. If it can’t, the effort to connect with the growing mobile app ecosystem will falter. Stakeholders connected to the API have to be able to communicate with one another through the solution, including people and entities that are external to the organization that is publishing the API. API Lifecycle Management, as embraced by the complete organization, is inextricably linked to attaining the strategic outcomes promised by mobile apps while ensuring that best return on the original investment in SOAP services.

Disclaimer: The information provided in this document is provided “AS IS” WITHOUT ANY WARRANTIES OF ANY KIND INCLUDING WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT OF INTELLECTUAL PROPERTY . Akana may make changes to this document at any time without notice . All comparisons, functionalities and measures as related to similar products and services offered by other vendors are based on Akana’s internal assessment and/or publicly available information of Akana and other vendor product features, unless otherwise specifically stated . Reliance by you on these assessments / comparative assessments are to be made solely on your own discretion and at your own risk . The content of this document may be out of date, and Akana makes no commitment to update this content . This document may refer to products, programs or services that are not available in your country . Consult your local Akana business contact for information regarding the products, programs and services that may be available to you . Applicable law may not allow the exclusion of implied warranties, so the above exclusion may not apply to you .

© 2001 - 2015 Akana, All Rights Reserved | Contact Us | Privacy Policy

About Akana Akana is a leading provider of API Security and Management products that help businesses plan, build, run and share APIs, through comprehensive cloud and on-premise solutions that encompass API lifecycle, security, management and developer engagement. The world’s largest companies including Bank of America, Pfizer, and Verizon use Akana solutions to transform their business. For more information, please visit http://www.akana.com

Akana, API Gateway, Community Manager, Lifecycle Manager, Policy Manager, Portfolio Manager, Repository Manager, Service Manager, and SOLA are trademarks of Akana, Inc . All other product and company names herein may be trademarks and/or registered trademarks of their registered owners.

Documents

Mobilize Your SOAP Services...Comparing SOAP and REST SOAP and REST serve similar purposes in architectural terms. Both enable software applications to call on web services to retrieve