Mobilize Your SOAP Services Deliver RESTful APIs for Mobile Consumpton Using Existng SOAP Services 2 page 2001 - 2013 SOA Software, Inc. All Rights Reserved | Contact Us | Privacy Policy Mobilize Your SOAP Services Deliver RESTful APIs for Mobile Consumpton Using Existng 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 fnd myriad new channels and alliances through connecton 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 confgured to support these interfaces. The good news for architects is that API Management solutons can easily deliver RESTful APIs from existng SOAP web services. This paper discusses a proven approach for extending SOAP services for mobile app consumpton with RESTful interfaces. This SOAP-to-REST architecture relies on the workings of a complete API lifecycle management soluton. Contents Introducton ..... 3 The Corporate App Wave ..... 3 The Big Disconnect ..... 4 The Disconnect in Historical Context ..... 4 Comparing SOAP and REST ..... 5 Does it Mater? ..... 7 Making the Connecton ..... 7 Managing the SOAP-to-REST Architecture ..... 10 Conclusion ..... 13 3 page 2001 - 2013 SOA Software, Inc. All Rights Reserved | Contact Us | Privacy Policy Introducton The 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, ofen face a disconnect. Mobile apps frequently use the Representatonal 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 confgured 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 solutons can easily deliver RESTful APIs from existng SOAP services. This paper discusses a proven approach to extending SOAP services for mobile app consumpton with RESTful interfaces by transforming their content to REST. The Corporate App Wave We are in the midst of a huge surge in smartphone adopton, with smartphone shipments exceeding those of feature phones for the frst tme 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 fgure that is projected to top 80% by 2015. 3
Smartphones and mobile computng growth is afectng the directon of corporate informaton technology (IT). While the most popular mobile apps are connected tosocial sites such as Facebook and Instagram, and communicaton tools like Skype 4 , corporatons have begun investng in apps that serve operatonal and strategic objectves. Corporate apps fll internal and external uses, according to Mobile Enterprise Magazine. Internally, the Bring Your Own Device (BYOD) trend, wherein corporatons allow employees to use whatever mobile device they prefer for work, is stmulatng 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 relatonship management (CRM), dispatch, work orders, travel and expense, and so forth. The Forrester 2013 Mobile Workforce Adoptons Trends Report captures the spirit of mobility that is pervading the corporate work culture, notng that 37% of US and European workers work from three or more locaton. 53% use more than three devices, while 82% use more than 7 apps for work 6 . Gartner predicts that 90% of organizatons 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 connectng 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 2012 8 . Social networking and locaton based services also ranked high in the survey, with more than 30% of businesses creatng 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 5 th
most downloaded free iPhone app of all tme. 10 This push for corporate apps is translatng into signifcant investment. According to Forrester, frms will invest increasingly in mobile process reinventon and app development services, with spending projected to reach $7.6 billion and $5.6 billion for process reinventon and app development, respectvely, 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. 4 page 2001 - 2013 SOA Software, Inc. All Rights Reserved | Contact Us | Privacy Policy The Big Disconnect Corporate 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 Notaton (JSON). The enterprise system, if its 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 dont interact naturally. The Disconnect in Historical Context The SOAP-REST disconnect is a bit ironic. SOA was billed as a revolutonary advance in interoperability that would enable simple, easy data exchange and procedure calls between any sofware programs anywhere in the world regardless of operatng system, sofware language or network. SOAP is thriving in the enterprise. However, mobile app developers prefer not to use it. For one thing, SOAP, though versatle, can be more difcult to program with than the lighter REST/JSON related formats. And, SOAP uses more processing power, so its not well aligned with simple mobile device processor chips or limited bateries. For the purpose of solving the challenge of the SOAP-REST disconnect, its 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 Descripton Language (WSDL) were developed in the 1990s to provide a new, beter 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 revoluton in interoperability. The vision was to enable enterprise architects to build a service-oriented architecture where sofware applicatons could be exposed as standards-based web services, accessible by any other applicaton anywhere using SOAP. REST is slightly newer than SOAP. The concept was introduced in 2000 by Roy Fielding, the noted computer scientst who has infuenced 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 tracton as an alternatve to WS* and SOAP-based web services for consumpton 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 sofware applicatons 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 fy through the air, but in diferent 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 capabilites were built into most major sofware development tools, including Microsof Visual Studio .NET and IBM Ratonal DeveloperWorks. Opinions vary on the overall success of SOA but the consensus is that SOAP a high degree of applicaton integraton at relatvely low Related standards, known as WS*, have been adopted 5 page 2001 - 2013 SOA Software, Inc. All Rights Reserved | Contact Us | Privacy Policy for security, policy management, message routng, 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 HTTPs natve capabilites, such as GET, PUT, POST and DELETE. When a request is sent to a RESTful API, the response (the representaton of the informaton resource being sought) returns in either the JSON, XML or HTML format. A RESTful API is defned by a web address, or Uniform Resource Identfer (URI), which typically follows a naming conventon. 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 htp://api.mysoles.com/ catalogue. The mobile app developer could pull the catalogue onto the app by writng an HTTP request of GET to this URI. To get a specifc item from the catalogue, the developer would write GET to a version of the api that contained the product number, such as the following: htp://api. mysoles.com/catalogue/[sku]. When the RESTful API received the HTTP request, it would return the product informaton 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 specifcally for the shoe catalogue. If the SOAP web service were located at htp:// 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 1 The enterprise SOA - an E2E construct with applicaton exposed as SOAP web services. Company A Company B ERP CRM BI Web Service ERP Web Service Web Service Web Service 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 applicaton. The web applicaton responds with a JSON message. Web Applicaton RESTful API B2M APP HTTP Request JSO N 6 page 2001 - 2013 SOA Software, Inc. All Rights Reserved | Contact Us | Privacy Policy 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 informaton. Fundamentally, REST involves a lot less coding to accomplish the goal of accessing an informaton resource or requestng a procedure. These qualites make REST a great deal simpler to work with than SOAP, though they present their own limitatons. John Mueller, writng for the SmartBear Blog, does an excellent job of contrastng the relatve 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, platorm and transport. (In contrast, REST requires HTTP) Works well in distributed environments, such as the enterprise. (REST assumes point-to-point) Well-standardized afer more than a decade of serious enterprise use Pre-build extensibility with WS* standards Built-in error handling Automaton when used with certain languages REST, in comparison, is easier to work with and more fexible: No expensive tools needed in order for interacton with web services Shorter learning curve More efcient (XML, used in SOAP messages, is longer than RESTs message formats) Faster, with less processing required Does it Mater? Given RESTs distnct 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 fguring out how best to expose enterprise systems to mobile apps, though, does it really mater? Mobile app developers use REST. Enterprise applicatons 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 Connecton There is every reason to be optmistc 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 applicaton integraton powerhouse in the enterprise. Let REST be the dominant mode of interacton in the mobile app world. The most viable approach to connectng mobile apps with enterprise back end systems is to transform the existng 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 applicatons on the lef side of the fgure 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 SOA Sofware 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 SOA Sofware API Gateway and comparable products provide several additonal, necessary functons for an efectve 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 7 page 2001 - 2013 SOA Software, Inc. All Rights Reserved | Contact Us | Privacy Policy Once the SOAP to REST transformaton is possible, a business can implement more sophistcated 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 manufacturers back end systems. This is a generic use case, but it could be visualized as a tre manufacturer allowing tre store customers to use a mobile app to place orders for tres. The app can also be used to change orders, confrm payments, cancel orders, and so forth. The mobile app communicates with the manufacturers 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 emblematc of how businesses can harness the potental of the smartphone revoluton. 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 SOA Sofware API Gateway can provide this kind of mediaton. When this kind of mediaton is occurring, the entre enterprise architecture can interact with the outside, RESTful world without having to rethink internal messaging. Security mediaton is another factor that must be addressed in the REST-SOAP connecton. B2B functonality, especially those involving fnancial transactons 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 documentaton must be clear on exactly what the POST message means. The sender of the POST message needs to authentcated and authorized if there is a transacton pending. Otherwise, a number of unacceptable security risks arise. SOA Sofwares API Gateway is unique in that it can make all of this functonality possible on a single management infrastructure that takes care of RESTful APIs, SOAP services, as well as MOM and JMS transformaton requirements. Figure 3 Reference architecture for enterprise-to-mobile (E2M), where HTTP requests sent by mobile apps to RESTful APIs are transformed into SOAP for consumpton by existng enterprise web services and conversion into MOM and other message formats SOAP responses are then transformed into JSON. ERP CRM BI Web Service Web Service Web Service MOM JMS APP HTTP Request JSON T r a n s f o r m T r a n s f o r m T r a n s f o r m RESTful API RESTful API RESTful API Figure 4 SOAP web services in the enterprise can be invoked by corporate apps from third partes 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 RESTful API Customers Orders Invoices Transactions Revenue Cash Journal General Ledger ERP Orders DISTRIBUTOR App Order Changes DISTRIBUTOR App Order Cancellations DISTRIBUTOR App Payment Confirmations DISTRIBUTOR App PO Copy to Client DISTRIBUTOR App Refund Confirmation DISTRIBUTOR App PO Info Payment Info Order Info Change Info 8 page 2001 - 2013 SOA Software, Inc. All Rights Reserved | Contact Us | Privacy Policy SOA Sofware takes on the challenge of API management. The SOA Sofware API Management Soluton approaches APIs from a complete lifecycle perspectve, ensuring that APIs are serving their intended purposes at every stage of life from planning through development, deployment and retrement. Figure 5 shows how this API lifecycle progress is managed by the SOA Sofware soluton. Planning Controls designed in at planning stage. Compliance policies dened. Stakeholder input. Plan Development Build Operatons Dev/Test/Producton barriers dened and enforced. API launched to producton with policy binding. Monitoring and reportng 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 APIs Lifecycle. Unfortunately, some API management solutons are relatvely 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 soluton might make it possible to monitor inbound trafc and conduct authentcaton for access to an API. However, that soluton does not necessarily know if the API in queston has been replaced or retred. Figure 5 Management of the API Lifecycle for connectng existng SOAP web services with mobile app developers Overall, SOAP-to-REST transformaton ofers a number of advantages for businesses that want to extend their existng SOA into the mobile app space: Speed SOAP-to-REST is not a push buton 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 its needed now. Not a year from now. Pragmatsm Building RESTful APIs on top of existng SOAP infra- structure allows a business to move into mobile while stll using existng SOAP developer tools as well as SOA security and gover- nance platorms. Cost Transforming SOAP into REST is cost efectve. The invest- ment has already been made in the SOAP service. Theres no rea- son to rip it out. Similarly, investments in tooling and management platorms for SOAP can persist as the company implements SOAP- to-REST transformaton. Managing the SOAP-to-REST Architecture Efectve SOAP-to-REST transformaton doesnt 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, frustraton and inefcient use of IT support resources. From a business perspectve, unmanaged APIs pose a risk of sub-optmal executon, with the app community experiencing confusion and losing interest in developing apps that can take advantage of APIs to realize business objectves. 9 page 2001 - 2013 SOA Software, Inc. All Rights Reserved | Contact Us | Privacy Policy (Endnotes) 1 Dusan Belic, IntoMobile - Mobile phone sales to reach 1.86 billion this year; Smartphone sales to account for more than a half citng CCS Insight data. 2 ibid 3 ibid 4 htp://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/12 6 Forrester Research - 2013 Mobile Workforce Adoptons Trends Report 7 htp://www.gartner.com/newsroom/id/2529315 8 Tony Rizzo - Mobile Enterprise Magazine The Top Ten Mobile Apps in the Enterprise -1/1/12 9 Ibid 10 htp://blogs.wsj.com/digits/2013/05/03/meet-apples-top-25-most-downloaded- free-apps/ 11 Forrester Research Mobile App Internet Recasts The Sofware and Services Landsacpe March, 2011 12 John Mueller Understanding SOAP and REST Basics SmartBear Blog, 2013 Conclusion Extending SOAP services for mobile consumpton is about making sure that RESTful APIs serve business needs are built right and controlled but not excessively restricted. Making this happen involves selectng the right API management soluton. That soluton needs to work across and connect each stage of the complete API Lifecycle. If it cant, the efort 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 soluton, including people and enttes that are external to the organizaton that is publishing the API. API Lifecycle Management, as embraced by the complete organizaton, is inextricably linked to ataining the strategic outcomes promised by mobile apps while ensuring that best return on the original investment in SOAP services. Disclaimer: Te 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 . SOA Sofware may make changes to this document at any time without notice . All comparisons, functionalities and measures as related to similar products and services ofered by other vendors are based on SOA Sofwares internal assessment and/or publicly available information of SOA Sofware and other vendor product features, unless otherwise specifcally stated . Reliance by you on these assessments / comparative assessments are to be made solely on your own discretion and at your own risk . Te content of this document may be out of date, and SOA Sofware makes no commitment to update this content . Tis document may refer to products, programs or services that are not available in your country . Consult your local SOA Sofware 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 - 2013 SOA Software, Inc. All Rights Reserved | Contact Us | Privacy Policy About SOA Sofware SOA Sofware 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 solutons that encompass API lifecycle, security, management and developer engagement. The worlds largest companies including Bank of America, Pfzer, and Verizon use SOA Sofware solutons to transform their business . For more informaton, please visit htp://www.soa.com . SOA Sofware, API Gateway, Community Manager, Lifecycle Manager, Policy Manager, Portolio Manager, Repository Manager, Service Manager, and SOLA are trademarks of SOA Sofware, Inc . All other product and company names herein may be trademarks and/or registered trademarks of their registered owners.