You are on page 1of 10

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
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.

You might also like