Front cover
IBM z Systems Integration
Guide for the
Mobile and API Economy
Richard Gamblin
Rob Jones
Nigel Williams
Redpaper
International Technical Support Organization
IBM z Systems Integration Guide for the Mobile and API
Economy
December 2015
REDP-5319-00
Note: Before using this information and the product it supports, read the information in “Notices” on
page vii.
First Edition (December 2015)
This edition applies to the current version of products at the time of publication.
This document was created or updated on December 29, 2015.
© Copyright International Business Machines Corporation 2015. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule
Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
IBM Redbooks promotions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Now you can become a published author, too! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Stay connected to IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Chapter 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 The evolution of integration with core systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Business imperatives of today . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Two-speed IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Mainframe connectivity landscape of today . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5 Mobile connectivity challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2
3
3
4
4
Chapter 2. Architecture options for service and API enablement . . . . . . . . . . . . . . . . . 7
2.1 APIs and API management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 From services to APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 API management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.3 Benefits of APIs and API management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 REST and JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3 Advantages of REST and JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 SOAP web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1 Advantages of SOAP web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.1 MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.2 Advantages of messaging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Chapter 3. Mobile integration architecture considerations. . . . . . . . . . . . . . . . . . . . . .
3.1 Mobile integration architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 System of record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Service access layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Enterprise service bus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5 Application server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6 Mobile platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7 Security gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8 API gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9 Mobile app. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
18
18
19
19
20
20
21
22
23
Chapter 4. IBM z Systems mobile integration solutions . . . . . . . . . . . . . . . . . . . . . . . .
4.1 z/OS Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 IBM WebSphere Liberty z/OS Connect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2 IBM z/OS Connect Enterprise Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 IBM API Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
26
27
28
30
© Copyright IBM Corp. 2015. All rights reserved.
iii
4.2.1 When to use IBM API Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 IBM StrongLoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 When to use IBM StrongLoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 IBM DataPower Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1 When to use an IBM DataPower Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5 IBM Integration Bus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.1 When to use IBM Integration Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6 IBM MobileFirst Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.1 When to use IBM MobileFirst Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7 CICS mobile integration options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7.1 CICS web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7.2 z/OS Connect for CICS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7.3 CICS JSON web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7.4 JSON web services with CICS Transaction Gateway. . . . . . . . . . . . . . . . . . . . . .
4.7.5 Java applications in a Liberty JVM server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.8 IMS mobile integration options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.8.1 IMS Enterprise Suite SOAP Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.8.2 IMS Mobile Feature Pack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.9 DB2 z/OS mobile integration options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.9.1 When to use the DB2 Adapter for z/OS Connect . . . . . . . . . . . . . . . . . . . . . . . . .
4.10 IBM MessageSight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.10.1 When to use IBM MessageSight. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
31
32
33
34
34
35
35
36
37
37
38
39
39
40
41
41
42
43
44
44
45
Chapter 5. Real-world scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1 Web service enablement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.2 Key decision factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.3 Solution architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.4 What’s next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Web service reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.2 Key decision factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3 Solution architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.4 What’s next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 REST service enablement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2 Key decision factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.3 Solution architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.4 What’s next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Mobile Enterprise Application Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.2 Key decision factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.3 Solution architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.4 What’s next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5 API Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5.2 Key decision factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5.3 Solution architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5.4 What’s next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
48
48
48
50
50
51
51
51
53
54
54
54
55
56
57
57
57
57
58
60
60
60
61
62
63
Chapter 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.1 Common integration architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.2 Mobile integration solutions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
iv
IBM z Systems Integration Guide for the Mobile and API Economy
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
69
69
69
70
v
vi
IBM z Systems Integration Guide for the Mobile and API Economy
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not
infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not grant you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.
Any references in this information to non-IBM websites are provided for convenience only and do not in any
manner serve as an endorsement of those websites. The materials at those websites are not part of the
materials for this IBM product and use of those websites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring
any obligation to you.
Any performance data contained herein was determined in a controlled environment. Therefore, the results
obtained in other operating environments may vary significantly. Some measurements may have been made
on development-level systems and there is no guarantee that these measurements will be the same on
generally available systems. Furthermore, some measurements may have been estimated through
extrapolation. Actual results may vary. Users of this document should verify the applicable data for their
specific environment.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,
cannot guarantee or imply reliability, serviceability, or function of these programs.
© Copyright IBM Corp. 2015. All rights reserved.
vii
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines
Corporation in the United States, other countries, or both. These and other IBM trademarked terms are
marked on their first occurrence in this information with the appropriate symbol (® or ™), indicating US
registered or common law trademarks owned by IBM at the time this information was published. Such
trademarks may also be registered or common law trademarks in other countries. A current list of IBM
trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Cast Iron®
CICS®
CICS Explorer®
DataPower®
DB2®
IBM®
IBM MobileFirst™
IBM z Systems™
IMS™
RACF®
Redbooks®
Redpaper™
Redbooks (logo)
WebSphere®
z Systems™
z/OS®
®
The following terms are trademarks of other companies:
Connect:Direct, and N logo are trademarks or registered trademarks of IBM International Group B.V., an IBM
Company.
LoopBack, StrongLoop, and the StrongLoop logo are trademarks of StrongLoop, Inc., an IBM Company
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other
countries, or both.
Java, and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its
affiliates.
Other company, product, or service names may be trademarks or service marks of others.
viii
IBM z Systems Integration Guide for the Mobile and API Economy
IBM REDBOOKS PROMOTIONS
IBM Redbooks promotions
Find and read thousands of
IBM Redbooks publications
Search, bookmark, save and organize favorites
Get up-to-the-minute Redbooks news and announcements
Link to the latest Redbooks blogs and videos
Download
Now
Android
iOS
Get the latest version of the Redbooks Mobile App
Promote your business
in an IBM Redbooks
publication
®
Place a Sponsorship Promotion in an IBM
Redbooks publication, featuring your business
or solution with a link to your web site.
®
Qualified IBM Business Partners may place a full page
promotion in the most popular Redbooks publications.
Imagine the power of being seen by users who download
millions of Redbooks publications each year!
ibm.com/Redbooks
About Redbooks
Business Partner Programs
THIS PAGE INTENTIONALLY LEFT BLANK
Preface
Today, organizations engage with customers, business partners, and employees who
increasingly use mobile technology as their primary general-purpose computing platform.
They have an opportunity to fully embrace this new mobile technology for many types of
transactions, including everything from exchanging information to exchanging goods and
services, from employee self-service to customer service. This mobile engagement allows
organizations to build new insight into the behavior of their customers to better anticipate
customer needs and gain a competitive advantage by offering new services.
By extending existing enterprise applications onto a mobile platform you can capitalize on
existing investments without the need to develop completely new solutions to support mobile
services. Because nearly 70% of all enterprise transactions touch a mainframe, IBM® z
Systems™ mainframes have an important role in enabling existing and new mainframes to be
easily consumed by mobile applications, for example, through REST APIs. These same APIs
can be consumed through other channels and applications, both on-premises and in the
cloud.
Many technologies and solutions can be used to enable mobile integration with the
mainframe, including web APIs, services, connectors, messaging and so on. The primary
goal of this IBM Redpaper™ publication is to help IT architects choose between the many
mobile integration architectures and solutions and make the right choice based on the
specific requirements of the project.
This paper first outlines some of the business imperatives and challenges. It then reviews
the main architecture options and the key considerations for planning mobile integration
with the mainframe; it provides guidance for when to use specific solutions. Finally, it
documents several mobile integration scenarios to illustrate how these technologies are
used in real-world scenarios to build robust solutions.
Authors
This paper was produced by a team of specialists from around the world working at the
International Technical Support Organization (ITSO), Poughkeepsie Center.
Richard Gamblin is an IBM Technical Staff Member, IBM
Redbooks® Mobile Thought Leader and Global Leader for
Mobile for the zChampions Team. As the European Technical
Leader for Digital Transformation, Richard works with clients to
develop new solutions and capabilities with IBM Middleware,
Mobile, and z Systems technologies. He has worked in a
number of Technical Sales roles during his time in IBM, ranging
from an Integration and Connectivity Specialist to an IBM
WebSphere® Architect. Prior to joining IBM, Richard was a
researcher at the University of Leeds, from where he obtained
a doctorate in the field of Bioinformatics.
© Copyright IBM Corp. 2015. All rights reserved.
xi
Rob Jones works at the IBM Hursley Software Laboratory, in
the UK, with the IBM CICS® Strategy and Technical Planning
team, with responsibility for the CICS Mobile enablement,
including IBM z/OS® Connect. He has worked on the
development of CICS Transaction Gateway products since
2002, specializing in the IBM z/OS platform and most recently
has led work on z/OS Connect. He also produced the first
CICS TG plug-in for IBM CICS Explorer® tool.
Nigel Williams is an IT Specialist working at the IBM Client
Center in Montpellier, France. Nigel specializes in CICS
integration, API enablement, and mainframe security topics. He
helps clients to design and test mainframe integration
solutions. He is the author of many papers and Redbooks
publications. Previously Nigel worked as a Developer and
Tester at the IBM Hursley Software Lab.
Thanks to the following people for their contributions to this project:
Marcela Adan, Martin Keen
IBM ITSO
Aymeric Affouard, Stefano Delle Chiaie, Stephane Faure,
Yann Kindelberger, Eric Phan, Frank Van Der Wal
IBM Montpellier Client Center
Carl Farkas
IBM France
Michael Casile
IBM Competitive Project Office
Bruce Armstrong, Asit Dan, Tom Shepherd
IBM z Systems, US
Matthew Leming
IBM MQ Development
Maryela Weihrauch, Jane Man
IBM DB2 for z/OS Development
xii
IBM z Systems Integration Guide for the Mobile and API Economy
Now you can become a published author, too!
Here’s an opportunity to spotlight your skills, grow your career, and become a published
author—all at the same time! Join an ITSO residency project and help write a book in your
area of expertise, while honing your experience using leading-edge technologies. Your efforts
will help to increase product acceptance and customer satisfaction, as you expand your
network of technical contacts and relationships. Residencies run from two to six weeks in
length, and you can participate either in person or as a remote resident working from your
home base.
Find out more about the residency program, browse the residency index, and apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our papers to be as helpful as possible. Send us your comments about this paper or
other IBM Redbooks publications in one of the following ways:
򐂰 Use the online Contact us review Redbooks form found at:
ibm.com/redbooks
򐂰 Send your comments in an email to:
redbooks@us.ibm.com
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
Stay connected to IBM Redbooks
򐂰 Find us on Facebook:
http://www.facebook.com/IBMRedbooks
򐂰 Follow us on Twitter:
http://twitter.com/ibmredbooks
򐂰 Look for us on LinkedIn:
http://www.linkedin.com/groups?home=&gid=2130806
򐂰 Explore new Redbooks publications, residencies, and workshops with the IBM Redbooks
weekly newsletter:
https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenForm
򐂰 Stay current on recent Redbooks publications with RSS Feeds:
http://www.redbooks.ibm.com/rss.html
Preface
xiii
xiv
IBM z Systems Integration Guide for the Mobile and API Economy
1
Chapter 1.
Introduction
Over the past few years, the adoption of mobile technologies by organizations has become
widespread, providing new levels of engagement with consumers and great working flexibility
and convenience to empower employees. Given the rapid pace of change of smartphone
and tablet apps, and devices, initial efforts have been focused almost entirely on the user
experience.
Now, organizations are looking to optimize and refine how their business applications and
core data can be made available through to mobile channels. Requirements have evolved
from store- or branch-finders to delivering fully featured business services to those mobile
devices. Given that nearly 70% of all enterprise transactions touch a mainframe1, integration
with z Systems mainframes is a critical part of developing an efficient mobile service.
Access to z Systems applications and data has long been available through multiple paths,
with more being introduced to specifically satisfy mobile workloads. The real challenge is that
enterprise architect teams have so many different options that it can be difficult to understand
the factors involved in assessing and selecting one over another. This paper sets out the
options and consideration factors necessary to make sound architectural decisions to
integrate mobile services with z Systems applications and data.
This chapter describes the following topics:
򐂰 The evolution of integration with core systems
򐂰 Business imperatives of today
򐂰 Two-speed IT
򐂰 Mainframe connectivity landscape of today
򐂰 Mobile connectivity challenges
1
Source: http://mobileenterprise.edgl.com/tech-spotlight/What-s-Powering-Huge-Mobility95644
© Copyright IBM Corp. 2015. All rights reserved.
1
1.1 The evolution of integration with core systems
In the beginning, users accessed mainframe applications through a connected 3270 terminal.
Although this interface remains commonly used today, access to mainframe applications has
changed significantly over the past 50 years (Figure 1-1).
Mobile
/Cloud
SOA
Web/Desktop
Client/Server
2015s
Green screen
2005s
1995s
1985s
1975s
Figure 1-1 The evolution toward self-service
At each stage in the evolution, distinctive changes have occurred to the types of users who
access the systems, and also to the user interface (UI). Table 1-1 shows how the UI has
changed over time.
Table 1-1 Characteristics of the evolutionary stages of access to mainframe systems
2
Stage
Main characteristics
Green screen
Limited user community with a limited and very controlled UI.
Client/server
The user community remains limited, however the UI is increasingly richer.
Web
Wider user community (anyone with browser), UI controlled by web page
(first z Systems web pages were similar in layout to green screens).
SOA/Web 2.0
Much wider user community, with service-oriented architectures (SOAs)
reusing existing services and exposing them through decoupled integration
methods. The UI is controlled by a service requester application or, in the
case of Web 2.0, by the user.
Mobile/Cloud
User community is anyone with a mobile device, rich flexible integrated UI,
often reusing services developed for SOA.
IBM z Systems Integration Guide for the Mobile and API Economy
As different kinds of users access these systems, new terms have emerged to distinguish
between the roles of systems:
򐂰 Systems of record
Systems of record (SOR) are the core systems upon which organizations rely to
house their mission-critical data and applications. A particular emphasis is placed
on transactional integrity and data consistency and these systems are typified by
IBM z Systems mainframes. Often these systems are accessed through a system
of engagement.
򐂰 Systems of engagement
Systems of engagement (SOE) are the systems through which people interact to access
the applications and data in the system of record. Examples of SOEs are email
applications, web sites and, more recently, are typified by mobile applications.
1.2 Business imperatives of today
Organizations are undergoing significant change to respond to market challenges. Some of
these are in response to regulatory requirements and others are simply in response to the
emerging requirements of consumers of their products or services. Over the last five to ten
years, a significant shift has occurred in the marketplace regarding how consumers and
employees expect to interact with businesses and government institutions. Two recent
Institute of Business Value studies2 have identified this shift away from an Enterprise-centric
market to an Individual-centric marketplace. The confluence of mobile technologies, along
with insight drawn from expanding pools of data, has led to this need for digital reinvention of
enterprise IT to meet the demands of the Individual-centric economy.
A key part of this approach is to ensure that IT systems are optimized and aligned to support
this unprecedented speed of change. Consider that green-screen applications developed
over the course of 40 years, that client/server did the same over 25 years, or that the Internet
matured in 15 years. Contrast that with the mobile and digital age, in which consumer
expectation has rocketed in a mere 5 years. Organizations need to respond more rapidly than
ever to meet this demand and one approach has been to create a multi-speed enterprise IT.
1.3 Two-speed IT
On average, the lifecycle for a mobile app is somewhere in the range of 3 - 6 weeks, after
which it is typically updated in some way. A major core banking application, however, might
see application updates every 3 - 6 months, which is a very different timescale. The fact is
that these core systems are eminently able to handle updates on a much short lifecycle,
even in days and weeks; however, this is typically not done because the core application
forms the foundation upon which the entire organization’s applications, presentation layers,
and integration components are based. Instead, we see the emergence of a bimodal, or
two-speed IT, which combines the merits of a fast-paced digital landscape for a mobile app,
and the stability and resilience of a more moderately paced enterprise landscape.
2
Digital transformation: Creating new business models where digital meets physical. 2011
http://www.ibm.com/services/us/gbs/thoughtleadership/ibv-digital-transformation.html
Digital reinvention: Preparing for a very different tomorrow. 2013
http://www.ibm.com/services/us/gbs/thoughtleadership/digitalreinvention/
Chapter 1. Introduction
3
The critical part of this two-speed IT model is its ability for the digital and enterprise systems
to work harmoniously together. For instance, suppose a company has identified a new
service that can offer a competitive advantage in the existing market. If that service is
prematurely introduced in the company’s mobile app but, critically, before it is available in the
enterprise application, it might effectively wipe out the advantage as competitors put in place
their own alternatives in that interim period. Similarly, if the capability is available in the
enterprise system but yet to be reflected in the mobile app, the return on that investment
cannot be realized. In short, the two systems (the digital and enterprise) must work in
tandem, and it is the role of the integration layer to provide that seamless interlock.
1.4 Mainframe connectivity landscape of today
A wide variety of options are available for connecting and integrating mainframe systems
across the enterprise, all of which are in use in production today. Such direct connectivity
options include these examples:
򐂰
򐂰
򐂰
򐂰
Message-based connectivity, such as IBM MQ
File-based connectivity, such as Sterling Connect:Direct®
Standards-based connectivity, such as web services
Custom connectivity options, such as IBM CICS Transaction Gateway or IBM IMS™
Connect
In addition, several commonly used integration options are available for routing, aggregating,
and disseminating information to and from mainframe systems:
򐂰 Enterprise service bus technologies, such as IBM Integration Bus
򐂰 Appliance-based technologies, such as IBM DataPower® Gateway
Although these connectivity and integration options have been used for many years to
support client/server, web, and SOA integration architectures, mobile services are placing
new demands on connectivity infrastructures. In many cases, existing integration solutions
can be extended to support mobile use cases, however there some unique aspects of mobile
architectures exist and that affect decisions of the integration technology.
1.5 Mobile connectivity challenges
By extending existing enterprise applications onto a mobile platform, a business can
capitalize on its existing investment without the need to develop an entirely new solution to
support mobile services.
The requirement to provide users with continuity of transactions across multiple channels
means that organizations that have well-established, multi-channel architectures are better
placed to enable mobile access to their transaction processing systems. A channel
integration approach based on a set of common reusable services offers the best framework
for mobile integration. Consider, however, that although reusing what you already have is a
good approach, mobile and cloud-based applications normally require a different style of
service that is based on lightweight RESTful interfaces (see 2.2.1, “REST” on page 11),
which are not normally available in today’s mainframe applications (see Figure 1-2 on
page 5).
4
IBM z Systems Integration Guide for the Mobile and API Economy
Figure 1-2 Mobile integration requirements
Mobile services bring additional requirements for integration into the enterprise. One of these
is the sheer volume of requests that is attributable to this new computing era. Historically,
users of other channels are typically restricted in some way: whether through access from an
office-only environment or, for early Internet users, access from the home. The advent of
always-on, always-connected mobile access users can access these systems at their
convenience, 24 hours per day, anywhere in the world. As a result, organizations have seen a
significant increase in the volume of traffic reaching their core systems.
Another integration requirement driven by mobile services is the support for push
notifications. For mobile consumers and organizations alike, the convenience and
personalization of publishing event-driven notifications to the device is hugely attractive.
Historically, interactions with core systems have always followed an inbound
request/response pattern. This model of push notifications places new requirements on
the integration layer to propagate business events on the system of record through to the
mobile user.
The chapters ahead examine the architectural approaches and technologies available, which
address these mobile integration challenges.
Chapter 1. Introduction
5
6
IBM z Systems Integration Guide for the Mobile and API Economy
2
Chapter 2.
Architecture options for service
and API enablement
This chapter introduces the main integration architectures that can be used for mobile
integration with z Systems applications.
This chapter describes the following topics:
򐂰 APIs and API management
򐂰 REST and JSON
򐂰 SOAP web services
򐂰 Messaging
© Copyright IBM Corp. 2015. All rights reserved.
7
2.1 APIs and API management
Computer programmers are familiar with the concept of an application programming interface
(API). Historically, an API refers to the published details for a defined set of capabilities that
an application programmer can build upon. The details of such an API might typically be
published in a technical manual, and distributed as a binary runtime library with an associated
license.
The types of APIs discussed in this paper follow the same core principles, but operate in a
connected world, where APIs can be easily discovered by any developer with the appropriate
access, and are self-describing to the point where application development tools can
generate code to use the API, accelerating adoption and promoting best practices.
Although these APIs still represent common services for application programmers, the
scope in which they are able to operate is dramatically different. APIs today might be
consumed and used across the breadth of global organizations, between companies, or
by private individuals; and they might be combined with other APIs from entirely unrelated
providers to form innovative value propositions. With an API, developers can exploit functions
of existing computer programs in other applications.
Over the years, APIs have evolved based on advances in technology (such as network speed,
security, and dynamic integration), and also maturation in business that allows for thinking of
business functions as discreet, consumable entities. Competition is now possible for business
functions based on business value as opposed to technology foundations.
API architecture has also evolved over the years, in particular with the advent of
service-oriented architecture (SOA). SOA provides for an architectural model to manage
consumer and provider relationships in a dynamic environment. This model paved the way for
producing and exposing APIs with better business enablement capabilities including request
access, entitlement, identification, authorization, management, monitoring, and analytics, as
shown in Figure 2-1.
Mobile
Transactions
Public
Cloud
Internet of
Things
APIs
SOA
Gateway
Integration
Private
Cloud
Web
Social
Partners
Analytics
Data
Services
Figure 2-1 Systems of engagement consuming APIs, and systems of record providing services
Mobile application developers today are able to compose high value applications by
combining existing exposed business services or APIs, often made available by a variety
of API providers, and discovered independently by application developers.
Each service or API provider is unlikely to have envisioned all of the ways in which an API
might be exploited, but if a mutual benefit exists, the API has a fair chance of success.
Cost-effective APIs that provide rapid value to application developers, and which also build
a reputation for reliability, can soon become the definitive method of providing a specific
8
IBM z Systems Integration Guide for the Mobile and API Economy
capability within the mobile application development community (for example, location
services using Google Maps APIs).
APIs are needed for many reasons, including these reasons:
򐂰
򐂰
򐂰
򐂰
Expose services for more flexibility.
Want easier access to customers and partners.
Need to reach more channels and devices.
Make your place in the market.
Today, progressive companies are exposing APIs to allow others to consume their business
functions, for a profit. Where Windows and Linux have been traditional development platforms
of the past, Google, Facebook, Twitter, and other companies are becoming the development
platforms of the future. All of these companies built a functional platform of business
capabilities and extended their business models by exposing APIs so that developers can
exploit their functionality. Google Maps is a great example. Many developers write mashups
on top of Google Maps for various reasons, for example retail store locator, traffic reports,
road conditions, and so forth.
One important business reason to enable APIs in your business is to monetize your business
capabilities. For example, if you are a credit reporting agency and you produce an API that
establishes credit scores and facts regarding a consumer’s credit history, then many banks,
loan companies, insurance companies, and solicitation companies are more than happy to
use (consume) your API for money. It provides them with the ability to perform the API
functions, yet avoid having to develop and maintain their own API functions. In addition, they
can easily disconnect yours if a better one comes along. This is the differentiator for APIs in
an API economy: the ability to quickly subscribe to or unsubscribe to business functionality. It
makes business more agile by driving a healthy competition for business function.
The term API economy refers to the opportunities associated with productizing the exposure
of your business functions as APIs. Consider that your API is a consumable product, and you
need to market and position your product correctly for maximum profit. So, API economy
deals with the additional channel opportunities associated with the proper exposure of your
consumable business functions.
For potential API consumers, business resources that reside on IBM z Systems, with
products such as CICS, IMS, IBM DB2®, and IBM WebSphere Application Server, represent
a rich source of capability if only their existence could be independently discovered by
application programmers, and integration options were aligned with other API providers.
Potential consumers of enterprise APIs might be either internal (inter-department,
cross-function, employee), partner (affiliated, authorized business partners), or public
(free or by registration). In all cases, access to enterprise APIs face a common set of
challenges in terms of consumability, security, auditing, measurement, billing, and lifecycle.
API management aims to provide a unified approach for addressing these challenges
2.1.1 From services to APIs
APIs are the externalized aspect of services and as such should not be viewed as an
alternative to SOA, but rather a part of a well-architected service-oriented enterprise.
However, APIs are a specific genre of services with a lifecycle that is focused on “external”
consumption. This externalization of enterprise services drives a focus on simplicity, security,
and compatibility with standards-based external systems.
Enterprise-scale businesses most likely already have many defined web services (see 2.3,
“SOAP web services” on page 12). These mission-critical transactional services and
Chapter 2. Architecture options for service and API enablement
9
business processes are likely to provide a rich source of content for new APIs. A collection of
individual services providing operations upon a common resource might now be represented
as a collective unit (an API). Such an API can be discovered, documented, invoked and
maintained as a single entity.
Developing for both internal enterprise services and external APIs enables the exploitation
of distinct content pools, where completeness of content and operations upon a specific
business resource might vary according to consumer. For example, an internal consumer
in an HR department might have full access to an employee record, whereas an external
employee directory might redact sensitive personal information from an employee record,
such as home address or salary, while ultimately accessing the same system of record asset.
An API is composed of operations that are offered in one of two styles:
򐂰 A REST API is structured according to the principles of Representational State Transfer,
and typically uses the JSON data format (for more detail, see 2.2, “REST and JSON” on
page 11).
򐂰 A SOAP API is a web service that is exposed as an API.
Although a collection of independent services can be brought together under the auspices of
an “API” facade, such an API might not be naturally “RESTful” if it does not intuitively reflect
the create, retrieve, update, and delete operations through the set of HTTP methods.
2.1.2 API management
API management brings a multitude of operational capabilities and insight to bear on APIs
and services, including discovery through an API marketplace, access controls, lifecycle
operations, rate control (or throttling), metering, auditing, and analytics.
The combination of RESTful APIs and API management herald a significant evolution beyond
the initial service enablement patterns of SOA, and the possibility to use JSON-encoded data
promises to make z Systems business assets easily consumable for the rapidly expanding
mobile and cloud-based application development community.
A key success metric for API-enablement for z Systems assets is discovery and ease of
consumption. An API enablement technology must make z Systems APIs discoverable and
easily consumable on the terms of the consumer. Today, a Swagger1 document can provide a
consumable unit for API consumers, providing everything they need to understand what the
API provides and how to use it.
Discovery of a self-describing API through a marketplace with the social capabilities such as
number of existing users, ratings, and lifecycle updates allows great APIs to drive rapid
adoption, while direct feedback can drive the evolution and requirements gathering process,
or quickly identify unpopular modifications, all in one place.
2.1.3 Benefits of APIs and API management
The major benefits of implementing an API management solution are as follows:
򐂰 Extend internal enterprise services to an ecosystem of innovators and new markets.
򐂰 Control access to enterprise services.
򐂰 Provide insight into who is accessing enterprise services.
1
10
Swagger is an open specification for describing, producing, consuming, and visualizing RESTful web APIs:
http://swagger.io/specification
IBM z Systems Integration Guide for the Mobile and API Economy
2.2 REST and JSON
Mobile application developers today typically expect APIs to “talk” HTTP, to naturally use
HTTP methods to represent the desired operation, to exchange data represented in JSON,
and to return resource references as fully formed URIs, ready to flow on a subsequent
request. All of these technologies are taken to be universally available for applications
designed for modern mobile devices such as smartphones and tablets.
2.2.1 REST
Representational State Transfer (REST) is a defined set of architectural principles by which
you can design web services that focus on service resources. The REST architectural pattern
takes advantage of the technologies and protocols of the World Wide Web to describe how
data objects can be defined and modified.
In contrast to a request-response model such as SOAP, which focuses on procedures made
available by the system, REST is modeled around the resources in the system.
In simple terms, REST prescribes a basic mapping from HTTP methods POST, GET, PUT,
and DELETE, to logical operations create, retrieve, update, delete. Each resource is globally
identifiable through its Uniform Resource Identifier (URI), and the HTTP methods are used as
shown in the following list:
POST
Create a new resource representation.
GET
Retrieve a resource representation.
PUT
Update a resource representation.
DELETE
Delete a resource representation.
2.2.2 JSON
JSON is an open standard format for data interchange. Although originally used in the
JavaScript scripting language, JSON is now language-independent, with many parsers
available in many languages. Example 2-1 shows a JSON message.
Example 2-1 JavaScript using a JSON-encoded array of name data
var employeesArray = [
{ "firstName":"John" , "lastName":"Doe" },
{ "firstName":"Anna" , "lastName":"Smith" },
{ "firstName":"Peter" , "lastName":"Jones" },
]
JSON supports two structures: objects and arrays. Objects are an unordered collection of
name-value pairs, where arrays are ordered sequences of values. JSON also supports simple
types including strings, numbers, Boolean expressions, and null values. This support
enables JSON to describe any resource. JSON can be seen as readable by both humans
and machines. JSON is an easy language for humans to read, and for machines to parse.
Chapter 2. Architecture options for service and API enablement
11
2.2.3 Advantages of REST and JSON
REST and JSON have these advantages:
򐂰 They are prescriptive in terms of implementation patterns and security options, leading to
a uniform approach that is intuitive for consumers and providers alike.
򐂰 The barrier of entry for mobile application programmers is set low; JavaScript application
programmers can handle HTTP connections and JSON data without requiring additional
specialist libraries (for example, for parsing)
򐂰 REST interfaces for z Systems assets are familiar to mobile application programmers, and
can be consumed in the same way as industry-standard APIs.
򐂰 They are independent of platform, operating system, and programming language.
򐂰 They are flexible and extensible.
򐂰 JSON can often represent data more concisely than XML. Every element in the tree has a
name, and the element must be enclosed in a matching pair of tags. JSON expresses
trees in a nested array format similar to JavaScript. This way can enable the same data to
be expressed in a relatively smaller data package than with XML, which can be a factor for
mobile applications.
2.3 SOAP web services
SOAP web services are an implementation of a service-oriented architecture (SOA). A
service is an application component that has a well-defined published interface that allows
other application components to invoke operations on the service without any knowledge of
how the service is implemented.
The technologies that can be used to implement a web services solution have received
wide acceptance as the strategic way of building distributed IT solutions that integrate
heterogeneous applications over the Internet and intranets.
The web service specifications are completely independent of programming language,
operating system, and hardware in order to promote loose coupling between the service
requester (or consumer) and service provider. The technology is based on open standards
such as these:
򐂰 Extensible Markup Language (XML)
򐂰 SOAP, which is a standard protocol for exchanging XML messages
򐂰 Web Services Description Language (WSDL), which defines an XML grammar for
describing web services
Using open standards provides broad interoperability among different vendor solutions.
These principles mean that companies can implement web services without having any
knowledge of the service requesters, and service requesters do not need to know the
implementation specifics of service provider applications. This use of open standards
facilitates just-in-time integration and allows businesses to establish new partnerships
easily and dynamically.
Figure 2-2 on page 13 shows how a SOAP message consists of an envelope that contains
zero or more headers and a body.
12
IBM z Systems Integration Guide for the Mobile and API Economy
Figure 2-2 SOAP messages
Application designers determine the contents of the headers. The SOAP specification does
not define what headers should be used. For example, application designers might define a
header that contains authentication credentials or information for transaction management.
The body is where the main end-to-end information (the payload) conveyed in a SOAP
message must be carried. This information might be parameters for calling a service for a
service request, or the result of calling the service for a service response (for instance, see
Example 2-2).
Example 2-2 SOAP body
<employees>
<employee>
<firstName>John</firstName>
<lastName>Doe</lastName>
</employee>
<employee>
<firstName>Anna</firstName>
<lastName>Smith</lastName>
</employee>
<employee>
<firstName>Peter</firstName>
<lastName>Jones</lastName>
</employee>
</employees>
2.3.1 Advantages of SOAP web services
SOAP web services have the following major advantages:
򐂰 Provide a standard for exchanging data in XML format, for example, the parameters used
in a program call (for the inbound message) and the data resulting from the call (for the
outbound message).
򐂰 Are independent of protocol, platform, operating system, and programming language.
򐂰 Are flexible and extensible.
򐂰 Enable the use of web services standards such as WS-Security.
SOAP supports the remote procedure call (RPC) style of web service, in addition to the
document message style. Although HTTP is transport-protocol-independent, it is the most
widely used protocol today for transporting SOAP messages.
A web service is fully defined in a WSDL file. Most major environments that host applications
have development tools that use the WSDL file to generate easy-to-use proxies or adapters to
send and receive SOAP messages on behalf of applications.
Chapter 2. Architecture options for service and API enablement
13
2.4 Messaging
Instead of exchanging information directly from one application to another, in a messaging
architecture, messages are placed in queues that store them until they are retrieved by an
application. A queue manager maintains the queue and is responsible for the integrity and
persistence of the message. It can also deliver messages across a network to other queue
managers. The full benefits of a messaging architecture are realized when you are integrating
disparate software components and you are not in control of the availability and connectivity
between these components.
Enabling all applications and data sources to communicate in this way requires a messaging
backbone. The messaging backbone can be thought of as a pervasive communications
infrastructure. It provides reliable and secure data communication between applications on all
computing platforms and in all execution environments. And, it provides an inherently loosely
coupled way of integrating applications.
In addition to providing connectivity, the messaging backbone should also be able to
provide guaranteed qualities-of-transport service (for example, reliable message delivery).
A messaging backbone exists in many of today’s application integration architectures, and
these are likely to be reused in mobile projects.
2.4.1 MQTT
MQTT is an extremely lightweight machine-to-machine publish/subscribe messaging
transport. It is useful for connections with remote locations where a small code footprint
is required or network bandwidth is at a premium. For example, it is used in sensors
communicating to a message broker through a satellite link, or in a range of home automation
and small device scenarios. It is also ideal for certain types of mobile application because of
its small size, low power usage, minimized data packets, and efficient distribution of
information to one or many receivers.
In terms of mobile devices, several specific differences exist between the MQTT and HTTP
protocols. MQTT is a more efficient transport for data payloads, transferring them as
minimally sized byte arrays, meaning that smaller data packets are needed to communicate
the same useful information. This way is ideal for bandwidth-sensitive devices such as
smartphones and tablets. The mechanism by which the data is moved also differs between
MQTT and HTTP. MQTT follows a reliable-delivery publish/subscribe messaging pattern,
rather than the try-and-retry request/response mechanism of HTTP. Again, this way is ideal
for mobile applications because it supports the publication to multiple recipients over
unreliable networks.
2.4.2 Advantages of messaging
The use of messaging offers these major advantages:
򐂰 It provides an asynchronous communication mechanism, enabling two or more
applications to communicate without both having to be available at the same time.
򐂰 It enables buffering of workloads between applications, such that one application does not
overload another with requests.
򐂰 It supports the single-to-many propagation of requests, using practices such as
publish/subscribe.
򐂰 The MQTT protocol can be used when network bandwidth is limited, connections are
fragile, and mobile devices have limited memory or processing capabilities.
14
IBM z Systems Integration Guide for the Mobile and API Economy
Industry standards exist for messaging, such as JMS, which enable Java applications to be
developed that can be fulfilled by any messaging provider that adheres to the standard.
Chapter 2. Architecture options for service and API enablement
15
16
IBM z Systems Integration Guide for the Mobile and API Economy
3
Chapter 3.
Mobile integration architecture
considerations
Integration between mobile apps and mainframe enterprise applications can be seen from
different perspectives including application integration, data integration, and security
integration. But the goal of all of these approaches is to decouple systems in order to reduce
the complexity and work effort involved in communicating with an enterprise application or
data source, distant from the mobile application itself.
In this chapter, we review the key considerations when planning a mobile solution that reuses
mainframe applications and data.
This chapter describes the following topics:
򐂰 Mobile integration architecture overview
򐂰 System of record
򐂰 Service access layer
򐂰 Enterprise service bus
򐂰 Application server
򐂰 Mobile platform
򐂰 Security gateway
򐂰 API gateway
򐂰 Mobile app
© Copyright IBM Corp. 2015. All rights reserved.
17
3.1 Mobile integration architecture overview
A mobile integration architecture must offer flexibility for the mobile user interface components
to perform key business tasks (including the invocation of business processes and services)
through the use of a service interface or API.
Figure 3-1 shows the major components of a mobile integration architecture (not all solutions
require all of the components shown in the figure).
System of Engagement
System of Record
Mobile Platform
CICS
Security/API
Gateway
Enterprise
Service Bus
Other apps
Service Access Layer
Mobile apps
IMS
DB2
Other
Application Server
Figure 3-1 Mobile integration architecture
These components of the mobile integration architecture are described next, starting with the
systems of record and finishing with the mobile app.
3.2 System of record
When mobile users access their bank accounts and other enterprise data, an important
aspect is that they have access to the same data that can be accessed through other
channels. A balance inquiry should give the same result, independent of whether the request
is made from a mobile app or from the Internet banking application. The integrity and validity
of the account data is maintained by the system of record (SOR).
The way in which the mobile app accesses the SOR will depend on the type of SOR
used (CICS, IMS, DB2, and others), the software version currency of the SOR, and what
application interfaces are already exposed by the SOR (see 3.3, “Service access layer” on
page 19).
18
IBM z Systems Integration Guide for the Mobile and API Economy
3.3 Service access layer
Services are used to encapsulate the functional units of an application by providing an
interface that is well-defined and implementation-independent. The service access layer may
be implemented in a separate server instance or may be a layer within the SOR.
Consider these questions when you decide how mobile applications should access the SOR:
򐂰 Does a service interface already exist?
You might already have web services running in the SOR exposed through SOAP
interfaces that can be used by the mobile client code. In this case, a component of the
enterprise mobile solution is required to convert between the protocol used by the mobile
app (normally JSON over HTTP) and the SOR interface (SOAP over HTTP).
However, exposing a REST interface directly might be more convenient and streamlined.
This way is why the traditional mainframe SOR products now provide options for
accessing applications using JSON over HTTP.
If the SOR is not service-enabled, a component of the enterprise mobile solution
is required to convert the mobile request into the data format and transport protocol
supported by the SOR application.
򐂰 What service granularity is exposed by the SOR application?
An important characteristic of the existing service interface is the service granularity
(course-grained or fine-grained). It is possible, even likely, that the granularity of the
existing interface will need to be adapted. For example, performing aggregation of
fine-grained services to expose a courser grained service might be necessary. In this
case, a service aggregation component of the enterprise mobile application can be
deployed in one of the layers of the mobile integration architecture.
򐂰 How will services be discovered?
The lifecycle of a typical mobile app is much shorter than the traditional mainframe
application lifecycle. To facilitate fast and agile development of mobile apps, and also other
system of engagement (SOE) applications, you need a way to allow developers to
determine quickly what services are available. Ideally, a developer should be able to
discover the catalog of available services, and retrieve the necessary information (for
example the JSON schema) to be able to call each service.
3.4 Enterprise service bus
An enterprise service bus (ESB) connects service requesters and service providers, which
are basic parts of a service-oriented architecture (SOA). Each invocation into an ESB from a
service requester (for example, a client-side mobile application) results in one or many
invocations out to a service provider (for example a mainframe SOR).
Mobile service invocation messages should be lightweight, consisting mostly of limited
numbers of primitive data types and operations. The ESB handles the necessary routing,
mediation of service interface differences, data transformations, protocol transformations,
caching, and orchestrations, retry logic, exception handling, and so on.
Chapter 3. Mobile integration architecture considerations
19
Consider these questions when you decide what role an ESB should play in a mobile
integration architecture:
򐂰 Is an ESB used in the existing application integration architecture?
Probably the most compelling reason for using an ESB in a mobile solution is if the ESB is
already being used today to enable integration with other non-mobile service requesters.
The ESB often has a pivotal governance role in applying policies such as authentication,
audit, logging, service versioning, and so on. In this case, mobile app requests will likely
be subject to the same governance policies.
Most ESBs have been enhanced in recent years to support specific mobile request
protocols and data formats.
򐂰 How many types of service requesters and service providers need to be supported by the
application integration architecture?
The value of an ESB is partly determined by the range of different service requesters and
providers that need to be integrated. When a significant and growing number of different
endpoints exists, the ESB plays a crucial role in avoiding a spider web of point-to-point
connections. An ESB also helps you more easily introduce new systems into the
application integration architecture in the event of business mergers and acquisitions.
򐂰 Does the mobile solution need to support asynchronous requests?
For asynchronous requests, the response of a service provider must be correlated to the
original request from the service requester; the requester must be able to determine which
request a response answers. An ESB is able to provide correlation for asynchronous
invocations through a messaging engine.
3.5 Application server
The application server provides facilities to create both web applications and a server
environment to run them. Different servers may be used including Java Enterprise Edition
(Java EE) servers running Java web applications or Node.js servers running server-side
JavaScript applications.
Because smartphones and tablets have mobile browsers, web applications may be shared
between desktop web browsers and mobile browsers. The problem here is that most websites
that are designed for desktop browsers are not easy to use on small mobile devices with
touch screens. Therefore, building a special mobile web app is often the best practice.
3.6 Mobile platform
“Roll-your-own” mobile solutions (for example, mobile web apps that reuse web applications)
can be a tactical response to a short-term requirement; however, a strategic approach
requires a specific SOE to cope with the particularities of the mobile engagement including
the faster app development and deployment lifecycles, push notifications, and mobile security
challenges, and the need for collecting mobile analytics data.
A mobile enterprise application platform (MEAP) addresses the challenges of developing
mobile software by managing the diversity of devices and user groups at the time of
deployment and throughout the mobile solution’s lifecycle.
20
IBM z Systems Integration Guide for the Mobile and API Economy
A MEAP solution is generally composed of two parts: mobile apps and a mobile server.
Mobile apps connect to the mobile server, which handles communications, system
integration, and security requirements. Most MEAPs also include a mobile development
toolset that allows companies to create and maintain mobile applications.
Consider these questions when you decide what role a mobile server should play in a mobile
integration architecture:
򐂰 Should the mobile server perform protocol and message transformation?
A mobile server can convert between the protocol used by the mobile app (normally JSON
over HTTP) and the SOR. However, in an integration architecture that includes an ESB,
this role will likely be performed by the ESB.
򐂰 What are the mobile security requirements?
A mobile server can perform user authentication and authorization (as any other server
can) but often has unique mobile security capabilities such as device and application
authentication, device blocking, and encryption of data stored on the device.
򐂰 Does the mobile solution require push notifications?
Whereas mobile devices are most often used to pull information from SOR systems, a
push style of user interaction can often improve the user experience, especially when used
in conjunction with location-based services. The mobile server often has an important role
in enabling push notifications because the mobile server has awareness of what devices
are connected, the type of device and the user/device mapping.
3.7 Security gateway
The most effective mechanism to ensure that proper access management policies are
enforced is through the use of a centralized security gateway. The gateway serves as an entry
point for requests from mobile apps and other application traffic into the enterprise. It delivers
a configurable set of modular capabilities to protect and enhance online mobile interactions.
The security gateway acts as the policy enforcement point (PEP) for all authentication and
authorization decisions related to mobile traffic. This architecture allows enterprises to
decouple the enforcement of security policy from the underlying application and also provides
functional offload of security capabilities to allow the SOR applications and resources to more
efficiently scale to meet the high volume demands that inevitably occur with mobile traffic.
For the most sensitive applications, a security gateway can be deployed as a physical
appliance with tamper-proof protection.
Consider these questions when you decide what role a security gateway should play in a
mobile integration architecture:
򐂰 Is a security gateway used in the existing application integration architecture?
The security challenges of mobile solutions overlap with those of other integration
solutions, for example, protection against denial of service and other threats, rate
limitation, and centralized security policy control. If these types of security policies are
already implemented in a security gateway, extending the gateway functionality to control
mobile access makes sense.
Chapter 3. Mobile integration architecture considerations
21
򐂰 What are the specific security requirements of the mobile solution?
Different applications have different security requirements that are influenced by many
factors, including these factors:
– Type of user (employee, client, and others). For business-to-employee (B2E) apps, for
example, deploying a mobile device management (MDM) solution is often necessary.
– Type of device (company owned, bring your own device (BYOD), and others.)
– Type of app (web, native, hybrid)
– Type of SOR services reused by the mobile app
– Authentication, authorization and audit requirements
– Confidentiality and data integrity requirements
– Company and industry standards that need to be respected
A security gateway can play an important role in any mobile security solution, but it will
probably not be the only security policy enforcement point. An end-to-end view is required in
which access control is enabled in each component of the architecture. For example, some
solutions require that the mobile user’s identity flows securely with the request message,
passing through layers of the application architecture until it arrives in the mainframe SOR.
3.8 API gateway
An API management solution simplifies mobile integration by enabling the following various
roles to perform various tasks:
򐂰 API developers to create, secure, control, deploy, analyze, and manage SOAP and REST
APIs
򐂰 API business owners to advertise, market, socialize, and sell APIs as products
򐂰 Application developers to easily find, understand, and consume APIs
򐂰 IT operations staff to manage and upgrade the API environment to use existing IT
investments
The API gateway is a runtime component of the solution that provides access to APIs and
essential services, such as security, governance, and monitoring. For example, metering of
API invocations enables rate-limiting to be applied and API use to be charged.
The API gateway can also provide the underlying technology to support message-format
translation, and version- and change-management. It can be deployed in the same physical
or virtual server as the security gateway.
Consider these questions when you decide what role an API gateway should play in a mobile
integration architecture:
򐂰 Do you need to make your business services more consumable?
Making APIs consumable means much more than providing only key technical information
of how to invoke the APIs, that is, the interface description. APIs should be simple to find
from an easily browseable and searchable catalog.
򐂰 Do you want to reach new markets and customers?
By exposing core business functions as APIs to business partners, a business can deliver
more comprehensive services and reach more customers.
22
IBM z Systems Integration Guide for the Mobile and API Economy
򐂰 Do you need more control over who uses your business services?
The API gateway can check the entitlement for the invoking application, control workload,
and generate audit data on each invocation. The collected audit data can then be
analyzed and presented as a report for gaining insight into API invocation. For example,
which APIs are invoked, how often, and by which applications.
򐂰 Do you need to charge consumers for accessing your business services?
The audit data collected by the API gateway can be used for charging.
3.9 Mobile app
The type of mobile application and its specific requirements can influence the type of mobile
integration architecture used. Consider these questions:
򐂰 What type of mobile application is being used?
Three types of mobile apps are available:
– Mobile web apps are the same as those used in a desktop browser, but are adapted to
fit on the smaller screen of a mobile device. They are typically written using HTML5,
CSS, and JavaScript, and are portable across multiple devices and operating systems.
Web applications cannot access the hardware on the mobile device (such as the
camera and GPS chip).
Web apps typically reuse web applications running in the application server, which then
invoke an SOR application through the service access layer or through an ESB.
– Native apps are written in an operating-system-specific language, and have full access
to the mobile device hardware, features, and functions.
Native apps typically invoke REST APIs exposed through the API gateway.
– Hybrid apps combine both the web and native models; applications are written using
HTML5, CSS, and JavaScript but wrapped in a container that allows the application to
access the device hardware.
With open source technologies like Apache Cordova, you can build applications using
HTML5 but also wrap the application in a native shell. Cordova provides a JavaScript
bridge into many of the native features on a device such as the camera, accelerometer,
and so forth.
MEAPs are normally based on open standards like Cordova, but they also provide
additional capabilities that help with system integration and security. Hybrid apps
therefore normally access the MEAP, which then invokes the SOR application through
the service access layer or through an ESB.
Note: Web apps and native apps may also access a MEAP server in order to benefit
from MEAP services, including security and analytics.
򐂰 Does the mobile application use push notifications?
Mobile applications can take advantage of a push style of user interaction that can
significantly improve the user experience. Push notifications deliver messages, usually
pointers to information that is relevant when a specific event occurs. When using the Apple
iOS notification framework (APNS) or the Google Android notification framework (C2DM),
the notification is bound to a specific app (as opposed to SMS, which is device-based).
The notification framework delivers a message and the device shows a dialog that causes
the user to open the app.
Chapter 3. Mobile integration architecture considerations
23
In many cases, the event that needs to initiate a push notification occurs in the SOR, for
example, an account balance falling below a certain level. To take advantage of push
notifications, therefore, the SOR application must be enabled for the detection and
emission of events to a MEAP. The MEAP then provides a unified push notification API
that supports different mobile device types.
򐂰 Does the mobile app need to regularly refresh data stored on the device?
If a mobile app needs to refresh its local data periodically, it can use a batch-scheduled
interaction pattern. An example is an app for field or support representatives, where the
app is scheduled to download the daily task list in addition to an updated product catalog,
which can then be used offline.
This pattern can also ensure delivery of information by using messaging protocols like
MQTT. Such an app will normally access data (perhaps by subscription) in a message
queue enabled by the ESB.
24
IBM z Systems Integration Guide for the Mobile and API Economy
4
Chapter 4.
IBM z Systems mobile
integration solutions
This chapter introduces the main solutions and products that can be used for mobile
integration with z Systems applications. The chapter has an overview of each solution and
then provides guidance for when to use the solution.
This chapter describes the following topics:
򐂰 z/OS Connect
򐂰 IBM API Management
򐂰 IBM StrongLoop
򐂰 IBM DataPower Gateway
򐂰 IBM Integration Bus
򐂰 IBM MobileFirst Server
򐂰 CICS mobile integration options
򐂰 IMS mobile integration options
򐂰 DB2 z/OS mobile integration options
򐂰 IBM MessageSight
© Copyright IBM Corp. 2015. All rights reserved.
25
4.1 z/OS Connect
z/OS Connect provides a single common gateway for REST HTTP calls to reach business
assets and data on z/OS operating systems. Where these assets run is specified in the z/OS
Connect configuration, relieving client applications in the cloud, mobile, and web worlds of the
need to understand the details about how to reach them and how to convert payloads to and
from the formats that the applications require. Services can be enabled without writing code
and tooling is provided for creating the data transformation artifacts.
Figure 4-1 shows an overview of z/OS Connect.
CICS
REST
JSON
z/OS
Connect
IMS
DB2
Other
Figure 4-1 z/OS Connect
With z/OS Connect, mobile and cloud application developers, whether they work inside or
outside the enterprise, can incorporate z/OS data and transactions into their applications
without needing to understand z/OS subsystems. The z/OS resources appear as any other
RESTful API.
Note: z/OS Connect is an example of a service access layer as shown in Figure 3-1 on
page 18.
z/OS Connect capability is delivered in two ways:
򐂰 IBM WebSphere Liberty z/OS Connect
The z/OS Connect function contained in WebSphere Liberty Profile is referred to as
z/OS Connect V1. It provides basic REST function, enabling one subsystem service
call per REST request, typically using a POST REST operation.
򐂰 IBM z/OS Connect Enterprise Edition
IBM z/OS Connect Enterprise Edition (EE) V2.0 (referred to in this paper as z/OS Connect
EE V2.0) extends the entitled capabilities of z/OS Connect V1 to support all REST verbs,
such as GET, POST, DELETE, and PUT. It supports JSON message mapping in addition
to data translation and provides new eclipse-based tooling to define RESTful APIs.
26
IBM z Systems Integration Guide for the Mobile and API Economy
4.1.1 IBM WebSphere Liberty z/OS Connect
z/OS Connect V1 is a Liberty feature that provides a fast, secure, and reliable way of
connecting to z/OS assets. It provides a way to identify and access assets by using standard
REST HTTP calls.
Figure 4-2 shows an overview of z/OS Connect V1.
1
Liberty Profile for z/OS
7
5
REST
JSON
CICS
Data Transform
3
z/OS
Connect
Servlet
Service Providers
4
IMS
DB2
Interceptors
6
2
server.xml
Figure 4-2 z/OS Connect V1
The following components are involved in processing a request in z/OS Connect V1:
1. z/OS Connect V1 function is contained in WebSphere Liberty Profile. It is available with
WebSphere Application Server for z/OS, CICS TS (see 4.7.2, “z/OS Connect for CICS” on
page 38), and IMS (see 4.8.2, “IMS Mobile Feature Pack” on page 42).
2. Services are configured in the Liberty server.xml file.
3. A servlet receives the request (normally an HTTP POST request) and invokes a service
provider.
4. A service provider is software that provides the connectivity to the SOR. z/OS Connect
has a Service Provider Interface (SPI) that supports the creation of service providers that
are used to process requests arriving to the z/OS Connect servlet. Service providers can
be written and delivered by any component to plug into an OSGi framework.
A WebSphere optimized local adapters (WOLA) service provider is included with z/OS
Connect, and is used to connect to CICS. IMS connectivity is enabled using IMS Connect.
5. z/OS Connect V1 provides the ability to transform JSON to the layout required by the
SOR. It supports the conversion of the JSON request to a byte array, which can be
mapped by a COBOL/PLI/C structure. A utility is provided that reads a COBOL copybook
or PLI, or C structure file, and generates a data mapping (binding file) and a JSON
schema. A similar utility is also provided for converting a JSON schema to a data
mapping.
6. Interceptors are callout points where software can be invoked to do operations such as
System Authorization Facility (SAF) authorization and SMF activity recording.
The interceptor framework is particularly powerful for controlling which users can access
which services.
7. The z/OS subsystems currently supported by z/OS Connect V1 are CICS, IMS, and DB2.
As a feature in the Liberty profile server on z/OS, z/OS Connect V1 benefits from unique z/OS
capabilities like SAF security integration, z/OS Workload Manager (WLM) and audit logging to
SMF. SAF integration means that z/OS Connect V1 supports z/OS Identity Propagation that
Chapter 4. IBM z Systems mobile integration solutions
27
can be used to map a distributed user id to IBM RACF® user ID, and then pass the mapped
RACF user ID onto CICS. WLM integration means different URIs can have varying levels of
priority and performance criteria.
When to use z/OS Connect V1
Consider using z/OS Connect V1 for mobile integration when you want to:
򐂰 Provide a uniform and consistent REST/JSON access to the mainframe.
򐂰 Simplify the service development process by making the mainframe application owner
responsible for data transformation, rather than the non-mainframe integration team.
򐂰 Manage service access control using SAF or map distributed identities to RACF identities.
򐂰 Audit service access (for example, arrival time, completion time, user ID, and others)
to SMF.
򐂰 Use the lightweight, cost-efficient WebSphere Liberty environment for transforming and
routing mobile requests.
For more information about z/OS Connect, see the IBM Techdoc Liberty Profile z/OS Connect
Quick Start Guide and Exploration of z/OS Connect Functions:
http://www.ibm.com/support/docview.wss?uid=tss1wp102439&aid=7
4.1.2 IBM z/OS Connect Enterprise Edition
The z/OS Connect Enterprise Edition (EE) V2.0 (announced in 2015) is a product that
extends the support available with z/OS Connect V1. In particular, it enables z/OS based
programs and data to participate fully in the new API economy.
Figure 4-3 shows how z/OS Connect EE V2.0 enables the build, deploy, discovery and
consumption of an API created from z/OS based CICS and IMS programs.
Figure 4-3 z/OS Connect Enterprise Edition V2.0
Statement of Direction: IBM intends to support additional z/OS subsystems with z/OS
Connect EE including DB2 and IBM MQ.
28
IBM z Systems Integration Guide for the Mobile and API Economy
z/OS Connect EE V2.0 consists of two major components:
򐂰 Workstation-based interface
The z/OS Connect EE V2.0 workstation tooling is designed to work with IBM Explorer
for z/OS Aqua, and associated offerings. The Eclipse-based tooling is used for the
composition of z/OS RESTful APIs. The API composition tasks include these:
– Definition of the RESTful API and the JSON message formats that are required by the
API (for both request and response)
– Definitions to invoke a specific service on z/OS
These definitions are encapsulated in an API package file, together with a matching
Swagger 2.0 document.
The user interface is designed to be intuitive for a z/OS developer who is familiar with
RESTful API concepts. Behind each API definition, the JSON request-response schema
associated with a specific HTTP method (GET, POST, PUT, and DELETE) can be mapped
to an associated z/OS Connect service. In combination with values from the HTTP
headers, JSON fields can be passed through, moved, omitted, or set to a default value,
and taken together to form an API mapping model.
The API mapping model provides a powerful degree of separation between the mobile
or cloud application view of the API, and the underlying z/OS subsystem assets
򐂰 z/OS Connect EE V2.0 runtime
z/OS Connect EE V2.0 enhances the z/OS Connect V1 runtime environment through
its support for API package files which originate from the workstation tooling. A utility
is provided to deploy an API package file to a specific instance of z/OS Connect EE.
This utility can assist the automated deployment of APIs.
API consumers can discover z/OS Connect EE APIs and the associated Swagger 2.0
descriptions. In this way, an API management solution can dynamically build a catalog of
z/OS based API services.
The z/OS Connect EE V2.0 runtime continues to support the interceptor framework for
SAF authorization and SMF activity recording. Request-level logging of JSON payloads is
also supported.
When to use z/OS Connect EE V2.0
In addition to the benefits of z/OS Connect V1 (see “When to use z/OS Connect V1” on
page 28), consider using z/OS Connect EE V2.0 for mobile integration when you want to:
򐂰 Provide intuitive, workstation-based tooling that enables a developer, with or without z/OS
skills, to create RESTful APIs from traditional z/OS based assets.
򐂰 Support the discovery of defined APIs using the Swagger 2.0 standard to share API
descriptions.
For more information about z/OS Connect EE V2.0, see the following web page:
http://www.ibm.com/software/products/en/zos-connect-enterprise-edition
Chapter 4. IBM z Systems mobile integration solutions
29
4.2 IBM API Management
The IBM API Management solution provides a complete set of REST and SOAP API
capabilities to help an enterprise extend the “reach” of business services beyond the
enterprise and to encourage innovation within the enterprise. The solution enables the
four most significant entities in the API economy:
򐂰
򐂰
򐂰
򐂰
API product managers
API providers
IT operations
Application developers
With the API Manager user interface that is provided with IBM API Management, you can
surface z Systems assets as lightweight APIs that conform to REST principals. Also, you can
accomplish this through simple configuration changes that involve zero coding.
The API Manager provides multiple connectors such as the SOAP-to-REST and HTTP
connectors. You can use these connectors to help create APIs from existing mainframe web
services. If you already have an existing RESTful API (using z/OS Connect for example) that
you want to expose and control, you can easily define that in the API Manager as a proxy
service.
IBM API Management supports iterative development of APIs with the ability to create
versions and to revert to prior versions. You can add a REST API either by composing the
API and its operations from “scratch” by importing a Swagger file, or by discovering a REST
definition from a registry. You can make changes dynamically to an existing running API
implementation, and the implementation can then be pushed and activated on the runtime
with little to no disruption to the consumers.
Figure 4-4 is an overview of the IBM API Management solution used for discovering
mainframe services, and creating and consuming APIs.
API Management
API
Developer
1. Discover
services
2. Create APIs
Development Time
Run Time
Cloud /
Bluemix
apps
Mobile apps
3. Consume
APIs
API
API
Web apps
API
Figure 4-4 IBM API Management and z Systems
30
IBM z Systems Integration Guide for the Mobile and API Economy
z/OS Connect
REST
REST
Service
REST
Service
Service
CICS
IMS
DB2
SOAP
SOAP
Service
SOAP
Service
Service
Other
An API management layer provides essential services, such as security, governance, and
monitoring for APIs defined and developed by your team. For example, API management that
provides metering of API invocations enables rate-limiting to be applied, API use to be
charged, and security provided for business data.
IBM API Management uses the IBM DataPower Gateway appliance as its gateway.
DataPower is an industry-leading security gateway that also provides access control,
integration, and optimized delivery of APIs (see 4.4, “IBM DataPower Gateway” on page 33).
4.2.1 When to use IBM API Management
Consider using the IBM API Management solution for mobile integration with z Systems
when you want to:
򐂰 Extend the value of your mainframe assets by socializing SOAP or REST APIs to
developers, and providing controlled access to third parties.
򐂰 Streamline the development of new REST APIs through service discovery.
򐂰 Secure, govern, and monitor access to mainframe services.
For more information about IBM API Management, see the following web page:
http://www.ibm.com/software/products/en/api-management
4.3 IBM StrongLoop
The IBM StrongLoop® solution provides a comprehensive set of tools to rapidly create,
prototype, and industrialize new APIs. One of the fastest growing and most popular
technologies for creating APIs is Node.js, an open source JavaScript runtime engine that is
particularly well suited to API creation, owing to its ease of use and high performance. IBM
StrongLoop embeds Node.js as its underlying runtime environment, providing enterprise
support for Node.js.
To accelerate the creation of new APIs, StrongLoop builds on the popular Node.js LoopBack®
framework, enabling developers to quickly compose scalable APIs based on existing data
models, application services, and Swagger 2.0-defined APIs. StrongLoop offers the choice of
creating APIs with StrongLoop Arc, a graphical tool that enables users to visualize their APIs.
Alternatively, StrongLoop provides slc, a command-line interface that offers a wider and more
powerful suite of API creation capabilities.
IBM StrongLoop offers a comprehensive adapter framework that allows new APIs to be
created, based on a set of aggregated underlying services. StrongLoop Connectors are able
to retrieve information from a multitude of databases (Relational and NoSQL), REST and web
services providers, and also file- and messaging-based services.
Chapter 4. IBM z Systems mobile integration solutions
31
Figure 4-5 shows an example of how an API, created with StrongLoop, might aggregate a set
of services from underlying systems.
Figure 4-5 IBM StrongLoop for API creation and aggregation of multiple endpoints
After APIs are created with StrongLoop, they can be deployed and managed in the Enterprise
Node.js environment. StrongLoop offers the following capabilities to create, deploy, manage,
and secure its APIs:
򐂰 API creation, visually with Arc or through the command-line interface with slc
򐂰 Deployment and delivery of APIs to the Enterprise Node.js runtime environment
򐂰 Process management to scale and cluster instances of deployed APIs
򐂰 Performance metrics for monitoring the health of the runtime environment
򐂰 Profiling to identify bottlenecks, CPU hotspots, and aid root cause analysis
򐂰 An API services gateway, providing secured, throttled, and managed access between
providers and consumers, and also API analytics.
4.3.1 When to use IBM StrongLoop
Consider using the IBM StrongLoop for mobile integration with z Systems when you want to:
򐂰 Extend the value of your mainframe assets by rapidly creating new APIs based on an
enterprise-grade Node.js and LoopBack framework.
򐂰 Augment and enrich existing mainframe services with other endpoints to aggregate
multiple services into a single API.
򐂰 Manage, monitor, and secure access to Node.js based APIs that surface mainframe
application logic and business data.
32
IBM z Systems Integration Guide for the Mobile and API Economy
Important: The combination of IBM StrongLoop with IBM API Management and z/OS
Connect provides a comprehensive solution for rapidly establishing an API framework,
enriched with access to valuable mainframe assets. The speed with which innovative new
APIs can be prototyped and created with StrongLoop, coupled with the comprehensive
lifecycle governance of API Management, and backed by core business APIs surfaced
through z/OS Connect EE V2.0, is a powerful combination for simplifying the reuse of
mainframe assets by mobile, web and cloud-based clients.
For more information about IBM StrongLoop, see the following web page:
http://www.ibm.com/middleware/application-platform/en-us/strongloop.html
4.4 IBM DataPower Gateway
DataPower Gateway appliances help quickly secure, integrate, control, and optimize access
to a range of workloads through a single, extensible, DMZ-ready gateway. These appliances
act as security and integration gateways for a full range of mobile, cloud, API, web, SOA, and
business-to-business (B2B) workloads.
Figure 4-6 shows the principal roles of a DataPower Gateway.
Figure 4-6 IBM DataPower Gateway
As shown in the figure, DataPower can play different roles in a mobile integration architecture:
1. As a mobile security gateway, DataPower can securely expose corporate data,
applications, and services to mobile apps, while optimizing delivery of the workload. It can
provide the following security capabilities:
–
–
–
–
–
–
–
–
Enforcement point for centralized security policies
Authentication, Authorization, SAML, OAuth 2.0, Audit
Threat protection for XML and JSON
Message validation and filtering
Centralized management and monitoring point
Traffic control / Rate limiting
Security integration with z/OS Connect
Security integration with MobileFirst Server (for example, DataPower can be used for
single sign-on)
Chapter 4. IBM z Systems mobile integration solutions
33
2. DataPower can also act as a gateway for API access and traffic management. It processes
and manages security protocols and stores relevant user and appliance authentication
data. The gateway server also provides assembly functions that enable APIs to integrate
with various endpoints, such as databases or HTTP-based endpoints.
3. DataPower can be used for data transformation, for example, JSON to SOAP or JSON to
MQ transformations.
If you have an existing DataPower appliance, you can use it as your gateway for an API
management solution. You might want to use physical DataPower appliances for your
production gateway servers. The physical gateway servers provide improved performance
throughput when compared with virtual gateway servers.
4.4.1 When to use an IBM DataPower Gateway
Consider using the DataPower Gateway for mobile integration with z Systems when you
want to:
򐂰 Protect Internet facing mobile applications against security attacks.
򐂰 Implement authentication and authorization standards that are not supported natively on
z Systems, or by specific mainframe subsystems.
򐂰 Implement IBM API Management as part of the solution.
For more information about the IBM DataPower Gateway, see the following web page:
http://www.ibm.com/software/products/en/datapower-gateway
4.5 IBM Integration Bus
The IBM Integration Bus (abbreviated as IIB in the figures) provides a strategic enterprise
service bus functionality. It provides a complete runtime for interpreting, transforming, and
routing a wide range of message formats. It fully supports message transports such as JMS,
HTTP, native WebSphere MQ, and others. It includes libraries for all major message formats
such as JSON, XML, SOAP, fixed length, variable length, tagged, SWIFT, EDI, and so on. In
addition to a base set of more than 50 built-in visual nodes, various transformation languages
are also supported, such as Java, extended SQL, XSLT, and WTX.
Over the years, the Integration Bus has become a corporate standard for reliable,
high-performance message handling running on all major platforms.
Figure 4-7 shows several principal integration scenarios enabled by IBM Integration Bus.
SOAP
MQTT
IBM Integration Bus
REST
FTP
Other
Integration Bus
ERP/EIS
Files
Web 2.0
Devices
Web Services
MQ,
JMS
Applications
Databases
Figure 4-7 IBM Integration Bus
34
IBM z Systems Integration Guide for the Mobile and API Economy
Mobile
Mainframe
CICS/IMS
IBM Integration Bus provides secure, scalable access to critical data and back-end systems
from mobile applications. Mobile apps can initiate message flows in IBM Integration Bus that
can be used for aggregation of end-points, business rules based behavior, complex message
mapping, transactionality across multiple resources, content-based routing, and much more.
IBM Integration Bus provides several specific z Systems mobile integration capabilities:
򐂰 IBM Integration Bus provides a JSON parser and serializer that interprets a JSON bit
stream using the JSON grammar, and generates a corresponding JSON domain logical
message tree.
򐂰 IBM Integration Bus can connect to applications and devices that send and receive
messages by using the MQ Telemetry Transport (MQTT) messaging protocol (see 2.4.1,
“MQTT” on page 14).
򐂰 IBM Integration Bus provides multiple connectivity options for CICS, IMS and DB2.
4.5.1 When to use IBM Integration Bus
Consider using IBM Integration Bus for mobile integration with z Systems when you want to:
򐂰 Reuse an existing application integration architecture based on IBM Integration Bus.
򐂰 Implement mobile solutions with complex and/or diverse application integration
requirements.
򐂰 Implement mobile connectivity based on MQTT.
For more information about IBM Integration Bus, see the following web page:
http://www.ibm.com/software/products/en/ibm-integration-bus
4.6 IBM MobileFirst Server
IBM MobileFirst™ Server is one component of the IBM MobileFirst Platform Foundation. It
provides a runtime for adapters, analytics, push notifications and application hosting services.
Server-side APIs are provided to integrate between the mobile application and back-end
systems.
JavaScript and Java APIs can be called to perform functions such as authentication,
accessing web services, accessing a database, and subscribing to push notifications. By
developing server-side application code, the mobile application can directly access SORs or
cloud-based services, or it can access services through an ESB.
Figure 4-8 on page 36 shows some of the integration adapters supported by the IBM
MobileFirst Server.
Chapter 4. IBM z Systems mobile integration solutions
35
WebSphere
HTTP
JMS
CICS
z/OS Connect
MobileFirst
server
IMS
DB2
Other
IIB
Packaged
applications
MQ
Other
SQL
Mobile apps
Other
Adapters
DB2
Figure 4-8 IBM MobileFirst Server adapter framework
Adapters connect to SOR applications, deliver data to and from mobile applications, and
perform any necessary server-side logic on this data. Figure 4-8 shows an HTTP adapter
connecting to z/OS Connect. Another possibility is to connect directly to CICS or IMS using
one of the natively supported HTTP protocols, for example, CICS web services.
You can hot deploy adapters, meaning deploy, undeploy, and redeploy them at run time. This
capability lends flexibility to the IBM MobileFirst Server-side development process. Some of
the benefits of using IBM MobileFirst adapters are as follows:
򐂰 Ability to fully control the URL’s structure, the content types, the request and response
headers, content, and encoding.
򐂰 Easy and fast development and testing by using IBM MobileFirst Studio and a
command-line interface (CLI).
򐂰 Easy and fast deployment to a running IBM MobileFirst Server.
򐂰 Ready-to-use security integration with IBM MobileFirst security that uses simple
annotations in the source code.
A built-in security framework provides connectivity and integration into existing enterprise
security systems, and sends connection credentials to the back end. This framework
enables the mobile application to use existing security systems, with credentials residing
on the server, not the device.
4.6.1 When to use IBM MobileFirst Server
Consider using the MobileFirst Server adapter framework for mobile integration with
z Systems when you want to:
򐂰 Enable mobile developers to develop server side integration code in JavaScript or Java.
򐂰 Have access to a range of “out-of-the-box” adapters including support for HTTP, SAP,
SQL, JMS and IBM Cast Iron® connectivity.
򐂰 Extend SOR integration to third-party mobile or web apps through open standards (for
example, REST and OAuth).
36
IBM z Systems Integration Guide for the Mobile and API Economy
򐂰 Enable user, device and application security using an XML-based configuration framework
򐂰 Use the IBM MobileFirst push notification framework.
For more information about the IBM MobileFirst Server, see the following web page:
http://www.ibm.com/software/products/en/mobilefirstplatform
4.7 CICS mobile integration options
CICS is used extensively for high-volume transaction processing. Because new mobile
solutions are rarely deployed on a single IT system, reuse of CICS programs from mobile
apps is a common requirement.
This section introduces the CICS family provided integration solutions that are most likely to
be used in mobile projects:
򐂰 CICS web services
򐂰 z/OS Connect for CICS
򐂰 CICS JSON web services
򐂰 JSON web services with CICS Transaction Gateway
򐂰 CICS Java applications in a Liberty JVM server
4.7.1 CICS web services
Application programs running in CICS can participate in a heterogeneous web services
environment as service requesters, service providers, or both.
Figure 4-9 shows an outline of the web services support in CICS.
Client
Service requester
application
CICS TS
SOAP/
HTTP
CICS web
service pipeline
Service provider
application
Service requester
application
CICS web
service pipeline
Endpoint
Service provider
application
Figure 4-9 CICS web services
The runtime support for CICS web services includes a pipeline that defines a set of message
handlers that act on a service request and response. A message handler is a program in
which you can perform your own processing of web service requests and responses, for
example, security processing.
CICS support for web services conforms to open standards, including SOAP, WSDL, and
a number of web services standards like WS-Security. CICS also supports sending and
receiving SOAP messages using IBM MQ. CICS web services is a mature solution that has
been widely adopted.
Chapter 4. IBM z Systems mobile integration solutions
37
When to use CICS web services
Consider using CICS web services for mobile integration when you want to:
򐂰 Reuse an existing CICS web services infrastructure.
򐂰 Manage conversion of JSON messages to SOAP messages in an intermediary gateway
(rather than on the mainframe), for example, in an enterprise service bus (ESB).
򐂰 Implement a security model using WS-Security.
4.7.2 z/OS Connect for CICS
The CICS embedded version of z/OS Connect is an alternative deployment model to running
z/OS Connect inside WebSphere Liberty for z/OS.
Figure 4-10 shows an overview of z/OS Connect for CICS.
CICS TS
Liberty JVM server
Data Transform
RESTful
JSON
z/OS
Connect
Servlet
CICS Provider
CICS
program
Interceptors
server.xml
Figure 4-10 z/OS Connect for CICS
z/OS Connect for CICS is optimized for local access to CICS and uses standard CICS
services. The z/OS Connect service provider makes use of the Java CICS (JCICS) interface
for access to CICS programs. These programs might then access DB2 or VSAM data, or
other external subsystems.
When to use z/OS Connect for CICS
Consider using z/OS Connect for CICS for mobile integration when you want to:
򐂰 Provide REST/JSON access to CICS programs.
򐂰 Simplify the service development process by making the CICS application team
responsible for data transformation.
򐂰 Use the z/OS Connect interceptor framework for security access and audit control.
򐂰 Provide a CICS REST service discovery capability.
Statement of Direction: IBM intends for a future release of CICS TS to provide support for
z/OS Connect EE to enable it to execute embedded within CICS.
38
IBM z Systems Integration Guide for the Mobile and API Economy
4.7.3 CICS JSON web services
CICS also supports the processing of JSON requests using a Java pipeline. The JSON
transformation is performed within an Axis2 JVM server.
Figure 4-11 shows an overview of the CICS JSON web services support.
CICS TS
Axis2 JVM server
Data Transform
Java
pipeline
RESTful
JSON
Application handler
CICS
program
Message handlers
Figure 4-11 CICS JSON web services
This support is similar to the z/OS Connect capability, and it shares the same data
transformation tools and deployment artifacts. However, several key differentiators exist:
򐂰 CICS support for JSON web services can be used for REST service provider and
requester applications (that is, both inbound and outbound requests are supported).
򐂰 z/OS Connect is better integrated with IBM API Management.
Important: The strategic solution for REST/JSON support in CICS is z/OS Connect.
When to use CICS JSON web services
Consider using CICS JSON web services for mobile integration when you want to:
򐂰 Enable a CICS JSON service requester application.
For more information about CICS JSON web services, see Implementing IBM CICS JSON
Web Services for Mobile Applications, SG24-8161:
http://www.redbooks.ibm.com/abstracts/sg248161.html?Open
Note: In earlier versions of CICS (prior to CICS TS V5.2), CICS JSON support was
provided with the CICS TS Feature Pack for Mobile Extensions.
4.7.4 JSON web services with CICS Transaction Gateway
CICS JSON web services can also be enabled by using the CICS Transaction Gateway
(CICS TG). The JSON transformation is performed within the CICS TG daemon, and a
channel or COMMAREA payload is then passed to the CICS program.
Figure 4-12 on page 40 shows an overview of the CICS TG support for JSON web services.
Chapter 4. IBM z Systems mobile integration solutions
39
CICS TS
CICS TG
CICS
program
Data Transform
RESTful
JSON
Figure 4-12 JSON web services with CICS TG
The CICS TG daemon may run on z/OS or one of a wide range of supported distributed
platforms.
When to use CICS JSON web services with CICS TG
Consider using CICS JSON web services with CICS TG for mobile integration when you
want to:
򐂰 Support REST services with older versions of CICS.
򐂰 Reuse an existing CICS TG infrastructure, for example, a set of cloned CICS TG daemons
that enable high availability.
For more information about CICS TG, see the following web page:
http://www.ibm.com/software/products/en/cics-ctg
4.7.5 Java applications in a Liberty JVM server
The Liberty profile is a lightweight web container for Java application development. The CICS
Liberty JVM server supports a subset of the features that are available in the Liberty profile;
you can run OSGi applications, EJBs, Java servlets, and JSP pages.
To develop a RESTful service, your program can use the Java API for RESTful Web Services
(JAX-RS). To develop a SOAP-based service, your program can use the Java API for XML
Web Services (JAX-WS). The Java program can link to existing CICS programs written in one
of the non-Java languages.
Figure 4-13 shows an overview of this scenario.
CICS TS
Liberty JVM server
RESTful
JSON
Java program
SOAP
JAX-RS
JAX-WS
Bespoke Data
Transform
Figure 4-13 Java application in Liberty JVM server
40
IBM z Systems Integration Guide for the Mobile and API Economy
CICS
program
The custom Java application can make use of JZOS classes for data transformation and can
connect to CICS programs outside of the JVM using the Java CICS (JCICS) interface.
The JZOS Batch Toolkit for z/OS supplies a set of handy tools for Java on z/OS. Within these
tools, JZOS supplies a RecordClassGenerator utility for COBOL language structures. This
utility takes a sequential file as input and generates the serialization/deserialization Java bean
class.
When to use Java applications in a Liberty JVM server
Consider using custom Java applications in a Liberty JVM server for mobile integration when
you want to:
򐂰 Develop new Java-based business services in CICS.
򐂰 Have complete control over the application interface (REST or SOAP).
򐂰 Develop custom data transformations.
򐂰 Develop Java integration logic that reuses existing CICS programs.
For more information about running Java applications in a Liberty JVM server, see IBM CICS
and the JVM server: Developing and Deploying Java Applications, SG24-8038:
http://www.redbooks.ibm.com/abstracts/sg248038.html?Open
4.8 IMS mobile integration options
IMS provides a high-performance application and data server environment for core business
transaction execution and data base access.
This section introduces the IMS family integration solutions that are most likely to be used in
mobile projects:
򐂰 IMS Enterprise Suite SOAP Gateway
򐂰 IMS Mobile Feature Pack
4.8.1 IMS Enterprise Suite SOAP Gateway
Application programs running in IMS can participate in a heterogeneous web services
environment as service requesters or service providers using the IMS SOAP Gateway.
Figure 4-14 shows an overview of the SOAP Gateway.
Client
Service requester
application
Endpoint
Service provider
application
SOAP/
HTTP
IMS TM
IMS SOAP
Gateway
SOAP/
HTTP
IMS Connect
XML
Transform
Service provider
application
Service requester
application
Figure 4-14 IMS SOAP Gateway
The SOAP Gateway acts as the gateway between external web services and IMS
applications. It serves as a web service server where IMS applications are enabled as web
Chapter 4. IBM z Systems mobile integration solutions
41
services. The SOAP Gateway communicates with IMS through IMS Connect, the TCP/IP
gateway for IMS. Messages between IMS Connect and the SOAP Gateway are transmitted in
XML format. IMS Connect converts the XML data into bytes and passes the request to the
IMS application.
Web service consumer applications are also supported. The SOAP Gateway enables IMS
applications to make synchronous or asynchronous callout requests to external web services.
The SOAP Gateway may run on z/OS, Linux on z or a Windows platform. It conforms to open
standards, including SOAP, WSDL and WS-Security.
When to use IMS Enterprise Suite SOAP Gateway
Consider using the IMS Enterprise Suite SOAP Gateway for mobile integration when you
want to:
򐂰 Reuse an existing IMS web services infrastructure.
򐂰 Manage conversion of JSON messages to SOAP messages in an intermediary gateway
(rather than on the mainframe), for example, in an ESB.
򐂰 Implement a security model using WS-Security.
For more information about IMS SOAP Gateway, see the following web page.
http://www.ibm.com/software/products/en/imsentesuitsoapgate
4.8.2 IMS Mobile Feature Pack
The IMS Mobile Feature Pack leverages the z/OS Connect feature so that you can discover,
model, enable, and publish REST services based on IMS assets. These services can be
consumed by mobile and cloud applications, which can access IMS assets on z/OS in a
secure and managed way.
Figure 4-15 shows an overview of how the IMS Mobile Feature Pack is deployed.
Liberty Profile for z/OS
Data Transform
RESTful
JSON
z/OS
Connect
Servlet
IMS Provider
IMS TM
IMS
Connect
IMS
program
Interceptors
server.xml
Figure 4-15 IMS Mobile Feature Pack
When a request comes in, z/OS Connect handles the user access control and then forwards
the request to the IMS mobile service provider. The request message is converted from
JSON to the native representation of the input message (for example, byte array or arrays for
segments in COBOL and PL/I applications) by the data transformation module. The request
then goes through the IMS Connect adapter module to interact with IMS Connect to access
IMS programs running in IMS Transaction Manager (IMS TM). These programs might the
access IMS DB, DB2, or other external subsystems.
42
IBM z Systems Integration Guide for the Mobile and API Economy
Tooling support for the IMS Mobile Feature Pack for modeling, creating, testing, and
managing services is provided by the IMS Explorer for Development in the IMS Enterprise
Suite.
When to use the IMS Mobile Feature Pack
Consider using the IMS Mobile Feature Pack for mobile integration when you want to:
򐂰 Provide REST/JSON access to IMS programs.
򐂰 Simplify the service development process by using a tool-driven process and making the
IMS application team responsible for data transformation.
򐂰 Use the z/OS Connect interceptor framework for security access and audit control.
򐂰 Provide an IMS REST service discovery capability.
For more information about the IMS Mobile Feature Pack, see the following web page:
http://www.ibm.com/software/data/ims/mobile.html
Statement of Direction: IBM intends that a future release of IBM IMS Enterprise Suite will
provide support for z/OS Connect Enterprise Edition.
4.9 DB2 z/OS mobile integration options
The DB2 Accessories Suite for z/OS (V3.3) enables the DB2 Adapter for z/OS Connect and
allows existing DB2 assets such as SQL and Stored Procedures to be exposed as REST
services.
Figure 4-16 shows an overview of the DB2 Adapter for z/OS Connect.
Liberty Profile for z/OS
Data Transform
RESTful
JSON
z/OS
Connect
Servlet
SQL
DB2 Provider
Interceptors
Stored
procedure
call
DB2 for
z/OS
server.xml
Figure 4-16 DB2 Adapter for z/OS Connect
The DB2 Adapter for z/OS Connect provides a fast, dynamic, scalable, and secure solution
for you to interact with protected DB2 assets through REST services in JSON data format.
It leverages the IBM Data Studio for tooling support. Data Studio can create, deploy, or
remove DB2 Adapter for z/OS services.
The DB2 Adapter for z/OS Connect is capable of performing data conversion from JSON
payload to the input of SQL or stored procedures and generates JSON payload from SQL
and stored procedures results as output.
Chapter 4. IBM z Systems mobile integration solutions
43
4.9.1 When to use the DB2 Adapter for z/OS Connect
Consider using the DB2 Adapter for z/OS Connect for mobile integration when you want to:
򐂰 Simplify the deployment of mobile or cloud-based applications that require access to their
mission-critical DB2 for z/OS assets.
򐂰 Use the z/OS Connect interceptor framework for security access and audit control.
򐂰 Provide a DB2 REST service discovery capability.
Statement of Direction: IBM intends to support z/OS Connect EE V2.0 with DB2, and to
provide DB2 RESTful API support that is fully integrated into the DB2 for z/OS Distributed
Data Facility.
4.10 IBM MessageSight
IBM MessageSight is an edge-of-network appliance that is designed to handle the massive
volumes of connections associated with Internet of Things (IoT) and mobile environments. It
provides a secure, DMZ-ready channel for lightweight, rapid, bidirectional messaging, based
on the MQTT protocol.
IBM MessageSight offers the following functions:
򐂰 Designed to operate in a DMZ, its appliance form factor means that it has restricted
access with no user level operating system.
򐂰 Provides mechanisms for assured message delivery.
򐂰 Supports native mobile application development with developer-friendly APIs.
򐂰 Extends and connects to Java Message Service (JMS) providers, such as IBM MQ and
WebSphere Application Server.
򐂰 Provides extremely high throughput, typically over one million concurrent connections, for
persistent and non-persistent messages.
Figure 4-17 shows an example mobile integration scenario enabled by IBM MessageSight.
MQTT
MQTT
MessageSight
JSON/
JMS
Publish/Subscribe
endpoint
IIB
Generate
Topic
CICS
XML/MQ
MQ
IMS
MQTT
Mobile apps
Figure 4-17 IBM MessageSight Appliance
In Figure 4-17, an SOR application running in CICS or IMS initiates an event by putting an
XML message on a queue. The message is read by IBM Integration Bus (IIB), transformed to
JSON and a topic is generated. The topic is read by IBM MessageSight and then consumed
by each of the subscribed mobile apps by using the MQTT protocol.
44
IBM z Systems Integration Guide for the Mobile and API Economy
4.10.1 When to use IBM MessageSight
Consider using MessageSight for mobile or Internet of Things connectivity when you want to:
򐂰 Concentrate millions of MQTT requests.
򐂰 Enable bidirectional messaging connectivity to mobile devices.
򐂰 Fan out messages to multiple devices using a publish/subscribe pattern.
For more information about IBM MessageSight, see the following web page:
http://www.ibm.com/software/products/en/messagesight
Chapter 4. IBM z Systems mobile integration solutions
45
46
IBM z Systems Integration Guide for the Mobile and API Economy
5
Chapter 5.
Real-world scenarios
This chapter summarizes five scenarios that integrate mobile apps with mainframe
applications. Each scenario describes the project context, including business drivers and
solution goals, and the key decision factors used for deciding on the most appropriate
mainframe integration solution. We describe the solution architecture and conclude with the
next steps the organization is pursuing at the time of publication.
The examples in this chapter describe the following integration scenarios:
򐂰 Web service enablement
򐂰 Web service reuse
򐂰 REST service enablement
򐂰 Mobile Enterprise Application Platform
򐂰 API Management
© Copyright IBM Corp. 2015. All rights reserved.
47
5.1 Web service enablement
This scenario focuses on the enablement of CICS web services, which are consumed
(indirectly) by mobile and other clients.
5.1.1 Introduction
Many banks have embarked on a core banking transformation strategy to gain flexibility
and reduce cost. A service-oriented architecture (SOA) is normally the preferred architecture
because it facilitates maximum reuse of existing assets. After services are created,
application developers (including mobile app developers) can more easily access the core
banking services.
Bank A uses a mainframe-based multi-channel core banking package that provides functions
like transaction accounts, loans, mortgages, and payments. In the past, these transactions
were tightly integrated with other business applications, where the transactions were invoked
directly using connector and messaging technologies.
With the new business drivers, such as enablement of mobile applications for better
engagement with customers, and API economy for enabling partners to reach new markets
and customers, Bank A wants to leverage its existing core banking application to create a
new set of APIs. The Bank A business team knows that an increased mobile and device
application presence will enhance the brand image and increase customer satisfaction. The
goal is to be seen as an innovative bank that engages with its customers and partners in new
ways, for example, through hackathons.
The initial step for Bank A is to create a more flexible interface to the CICS core banking
applications. These are the key questions to be addressed in this project:
򐂰 Which service enablement architecture should be used (REST or SOAP/XML-based web
services)?
򐂰 Which CICS service enablement solution should be implemented?
5.1.2 Key decision factors
Bank A considered several factors when deciding how to service-enable the CICS core
banking application, but the primary factors were solution maturity and solution adoption.
The key decision factors are reviewed next.
Mainframe application interface
The core banking functions expose a COMMAREA interface based on the package
proprietary data protocol. With the existing CICS integration solutions, knowledge of this
interface is required by the developers who are developing channel enablement applications.
The new solution should provide tooling for service creation and a way to define and
exchange well-defined service and message protocols.
Existing application integration infrastructure
The core banking application currently runs on CICS TS V4.2 and DB2 V10. The target
solution must support the existing CICS version.
48
IBM z Systems Integration Guide for the Mobile and API Economy
The existing application integration architecture includes an application server that is used
for channel applications and an enterprise service bus (ESB) that is used for service
composition.
The target solution must be compatible with the existing integration architecture.
Mobile app integration requirements
Mobile apps that are used by Bank A clients use a REST interface and JSON payload to
access core banking functions. Other applications also use a REST interface but many of
the vendor packages that are used by the bank today support only a web service (SOAP)
interface.
An eventual goal is to develop a services catalog (REST and SOAP) and developer portal that
will support Bank A developers and third parties.
Non-functional requirements
These are the main non-functional requirements of the project:
򐂰 Minimize risks
The core banking application is a critical application that is used at high volume (peak
transaction rate of 500 TPS). An essential project requirement is to be able to implement
new mobile apps in a nondisruptive way.
The business-critical core banking services must be available at all times. The
infrastructure must be able to support continuous service availability across planned
and unplanned outages.
򐂰 Optimize performance and scalability
The solution must be optimized and must meet the performance and scalability
expectations of Bank A.
򐂰 Security
The solution must offer a range of security solutions based on open standards, and be
protected against denial-of-service attacks.
Bank A also wants to implement a service enablement solution that has been widely adopted
in the banking industry.
Chapter 5. Real-world scenarios
49
5.1.3 Solution architecture
Bank A has chosen to implement a solution based on SOAP web services (Figure 5-1)
because CICS web services is a mature solution that is widely deployed in the finance
industry.
Other
channels
SOAP/HTTP
z/OS
XML/MQ
Other
Web
REST
Gateway
Application
Server
XML/MQ
SOAP/HTTP
SOAP/HTTP
Enterprise
Service Bus
CICS
JSON/REST
z Systems
Mobile
Figure 5-1 Web service enablement
The major components of the solution are briefly described next.
CICS web services
Core banking functions are exposed as web services for the following reasons:
򐂰 The web services specification offers a mature standard for service definition and a range
of additional specifications like WS-Security.
򐂰 The CICS native web services support is a mature solution with a large deployment base.
򐂰 CICS web services are supported with CICS TS V4.2 and require only traditional CICS
systems programming skills to implement.
Enterprise service bus (ESB)
An ESB is used for routing and protocol conversion.
Application server
The channel applications are exposed as XML-based services.
REST Gateway
The “homegrown” REST gateway converts REST/JSON requests that come from mobile and
web clients to XML/MQ or SOAP/HTTP.
5.1.4 What’s next
Bank A is currently rolling out the first wave of CICS web services, which are (indirectly)
consumed by mobile apps. Future plans include the deployment of IBM DataPower for
additional security capabilities, and a project has been initiated to replace the homegrown
REST gateway with an API Management solution to improve service management and
governance.
50
IBM z Systems Integration Guide for the Mobile and API Economy
5.2 Web service reuse
This scenario focuses on the RESTful service enablement of a CICS/ DB2 application to
improve integration efficiency between their digital channels services and the core Customer
System on z/OS. In this scenario, reuse is made of the existing connectivity and integration
architecture, which is based upon IBM MQ, CICS web services, IBM Integration Bus and
IBM DataPower.
5.2.1 Introduction
Bank B is a large national retail and commercial bank, offering a comprehensive set of
banking, credit, and insurance services. The bank’s core Customer System is a CICS/DB2
z/OS application, largely developed in COBOL. This system is accessed through multiple
routes, including MQ, web services and file transfer.
Several integration layers sit between the bank's WebSphere Application Serving mid-tier and
the Customer System. These include IBM Integration Bus, DataPower, and CICS Transaction
Gateway. These layers support the traditional branch and call applications, and also the
bank’s new digital platforms.
To increase agility, improve efficiency and simplify the layers of integration, Bank B plans to
rationalize the number of existing access points into CICS/DB2 from a little under a thousand
discrete services today, to fewer than 150 over the next 18 months. To achieve this, the bank
intends to establish a set of REST APIs through which all core services can be invoked.
The bank is interested in exploiting JSON payloads because it avoids some of the more
rigorous data coupling characteristics associated with more strongly typed data payloads,
such as XML. As an example, if a new field is added to an XML payload, by a service
provider, all consumers must then adhere to the news scheme. By contrast, the equivalent
service provider change to a JSON payload would simply be ignored by the consuming
applications. This decoupling of data payloads is attractive to Bank B.
Bank B exploits a number of technologies in production, which can satisfy the bank’s
requirement to expose the Customer System as a set of REST APIs. The question to be
addressed by this project is which of the following options is the most appropriate to
REST-enable the bank’s CICS/DB2 Customer System?
򐂰 IBM Integration Bus
򐂰 IBM DataPower Gateway
򐂰 z/OS Connect
5.2.2 Key decision factors
Bank B considered a number of factors when deciding how to REST-enable the Customer
System, however the bank’s primary drivers were to reduce the number of existing interfaces
and exploit REST API interfaces with JSON data payloads. The key decision factors are
reviewed next.
Mainframe application interface
Today, the Customer System is exposed through multiple connectivity options: IBM MQ,
CICS web services, and CICS Transaction Gateway. The decision for which connectivity
option is adopted largely depends on which channel or business silo is undertaking
the development.
Chapter 5. Real-world scenarios
51
The new solution should enable the Customer System to be invoked in a standard way,
irrespective of the application language, location (on-premises or cloud-based application),
or data model employed by the calling application.
Existing application integration infrastructure
The Customer System is based on CICS TS V4.2 and DB2 V10. The target solution must
support these software versions; however Bank B is keen to use new functions as early as
possible, as the bank moves through its upgrade cycle.
The existing application integration architecture uses IBM MQ V6.0, WebSphere Message
Broker v6.1 (precursor to IBM Integration Bus), CICS Transaction Gateway V6.1 and
DataPower XI50 appliances. The target solution should reuse, where possible, the existing
investments made in technology and architecture designs.
Mobile app integration requirements
The mobile services offered to Bank B’s consumers are available as an app iOS and Android
users, also through a mobile web interface to both mobile OS users. Both the mobile and
web apps access REST/JSON services through the bank’s digital platform, consisting of
outward-facing DataPower security gateways, and mid-tier WebSphere Application Servers.
This mid-tier then calls the Customer System via web services to DataPower, and then MQ to
WebSphere Message Broker, which can aggregate multiple calls to the Customer System.
The mobile app will continue to access the Customer System in a similar manner, however
through a subset of the existing interfaces and, where possible, with a shorter path length to
the underlying CICS subsystem.
Non-functional requirements
The primary non-functional requirements in this project are all related in some way to
simplification, and can be categorized as follows:
򐂰 Simplification through fewer interfaces
A critical objective is to reduce the current thousand existing interfaces down to a few
dozen. This can be achieved in part by retiring duplicated interfaces and non-shared
interfaces across multiple business silos.
򐂰 Performance and Scale
Today, multiple connectivity and integration layers are in place to link the bank’s digital
platforms to the Customer Systems, resulting in high latency and poor performance for
mobile users.
򐂰 Security and Management
The bank’s stringent security requirements mandate that any changes to integration
designs must not reduce the security protocols associated with access to the Customer
System. Indeed, a by-product of the reduced number of interfaces and simplification of
integration layers is that the management and controls necessary to secure the Customer
System are significantly reduced. This is similarly true for fault identification and resolution
of the end-to-end service for mobile-to-Customer System.
52
IBM z Systems Integration Guide for the Mobile and API Economy
5.2.3 Solution architecture
Bank B has chosen to adopt a solution based on the reuse of the existing DataPower
appliances to provide a RESTful API interface across all channel application teams within the
bank. The DataPower appliances, acting as a gateway between the WebSphere Application
Server mid-tier and the mainframe, convert the REST APIs and invoke the Customer System
using the existing CICS web service interface. This was considered to be the fastest way to
expose REST APIs, while meeting the non-functional requirements. The solution is shown in
Figure 5-2.
Assorted
service
consumers
Call Center /
Branches
z/OS
Linux on Z
Other
Web
IBM
DataPower
Gateway
WebSphere
Application Server
IBM
Integration
Bus
CICS
IBM MQ
SOAP/HTTP
IBM
DataPower
Gateway
Mobile
JSON/REST
z Systems
Figure 5-2 Web service reuse
The major components of the solution are briefly described next.
IBM DataPower Gateway
In this scenario, DataPower is positioned in two places: at the edge of the network, acting as
a security appliance; and internally within the network, acting as a combined security
enforcement point and integration appliance. The latter appliance is relevant to this
discussion, because it performs the following functions:
򐂰 Data conversion between the inbound JSON to XML/SOAP payloads
򐂰 Request mapping from the inbound REST call to the appropriate CICS web service
WebSphere Application Server
WebSphere Application Server provides Java hosting for presentation and business logic that
is tailored for each inbound channel. It accesses data from the Customer System through
DataPower and IBM Integration Bus.
IBM Integration Bus
Where appropriate for the calling service, IBM Integration Bus provides additional levels of
service aggregation and orchestration. For the purposes of this project, direct access to
single, CICS-based services was largely sufficient to satisfy the requirements of the each of
the channels platform team.
Chapter 5. Real-world scenarios
53
5.2.4 What’s next
Bank B is currently in the process of creating the REST/JSON service mappings to the CICS
web services in the Customer System in DataPower. This gives the bank the speed and
flexibility to establish a foundation that the bank can settle upon as its reduced set of core
services. In parallel to this decision, the Customer System team made the decision to further
explore the use of z/OS Connect as a mechanism to publicize and directly REST-enable the
CICS application. The team sees RESTful APIs as a necessary interface for any major
system within the bank.
5.3 REST service enablement
This scenario focuses on the REST service enablement of IMS using z/OS Connect to
support emerging mobile and digital channels.
5.3.1 Introduction
Bank C is a mid-sized retail bank offering financial services to individuals and corporate
clients. The bank’s core banking systems are “homegrown” applications developed in COBOL
and Java and hosted predominantly in IMS, DB2 z/OS and WebSphere Application Server
z/OS. In addition, further applications are hosted within CICS environments. These banking
systems are all accessed using IBM MQ, which provides a reliable, request/response
messaging model. This access method supports all existing channels across the bank,
including branch, call center, Internet and, more recently, the bank’s smartphone and tablet
banking apps.
With the increasing need to respond quickly to regulatory changes, coupled with the
expectation from lines of business that new offerings be delivered in weeks not months,
there is great interest in the promise of the API economy to provide this agility. Some of
the attractive features of this API-based approach are as follows:
򐂰 Self-service and discovery of services
򐂰 Standardized interfaces, based on REST over HTTP/S
򐂰 JSON payloads for flexible data representation
To exploit this agility, Bank C is developing an enterprise-wide API framework to expose core
services and data, both internally and with partner organizations. Bank C wants to surface its
existing core banking systems in IMS, through a REST service interface. The objective is to
unburden the bank’s development and partner communities from custom protocols and the
details of the underlying implementation. Longer term, the intention is to manage access to a
suite of APIs from which new applications can be created.
The initial step for Bank C is to determine how best to surface its IMS core banking systems
through a REST interface. The key question to be addressed in this project is this one:
򐂰 Which REST service enablement technology should be adopted: IBM DataPower
Gateway or z/OS Connect?
54
IBM z Systems Integration Guide for the Mobile and API Economy
5.3.2 Key decision factors
Bank C considered a number of factors when deciding how to REST-enable the IMS core
banking application, but the primary factor was to use a common solution for all z Systems
subsystems that would enable the bank to participate in an API framework. The key decision
factors are reviewed next.
Mainframe application interface
At present, the core banking functions are exposed through a set of MQ queues, messages
from which are read by the IMS application. Developers creating new applications must have
knowledge of both the COBOL COPYBOOK data structure and details of the target MQ
queues.
The new solution should enable the service to be invoked as a REST API and, where
relevant, allow the developer to discover all details of the service necessary to successfully
invoke the IMS application.
Existing application integration infrastructure
The core banking application currently runs on IMS TS V10 and DB2 V10. The target solution
must support the existing IMS and DB2 versions.
The existing application integration architecture exploits IBM MQ V7.1 to provide a reliable
and scalable pseudo-synchronous messaging service. However, the target solution does not
need to rely on the existing messaging backbone.
Mobile app integration requirements
At present, Bank C’s mobile and tablet banking apps use a REST/JSON to access the
bank’s core systems. All mobile requests are directed to a set of dedicated channel-specific
WebSphere Application Servers, which perform a presentation-layer function before invoking
the IMS core banking system through MQ.
In the future, the presentation tier will be able to access enterprise-wide services through
an API framework, in which services will be exposed through an API management layer.
Application developers will have the option of consuming the new REST APIs or reusing
the existing MQ backbone.
Non-functional requirements
The main non-functional requirements of the project are as follows:
򐂰 Improve agility
Bank C is adopting REST-based JSON APIs in order to deliver services more quickly. The
bank sees this as a way to enable developers and partners to self-discover and consume
existing services. Moreover adopting the use of JSON payloads enables a decoupling of
the data structures between requester and provider applications.
򐂰 Adopt a common integration architecture
As the bank proceeds with its enterprise-wide API framework, it wants to consume a
standardized set of APIs, irrespective of the underlying service provider. As such, the bank
requires mainframe services to be consumed through the same REST API model. In
addition, the longer-term aspiration is to be able to surface all mainframe applications
through a common API mechanism, to reuse tools and skills.
Chapter 5. Real-world scenarios
55
򐂰 Security
A by-product of offering discoverable services is that, if left uncontrolled, any individual
with access to the IP address can identify and invoke these services. A key non-functional
requirement is to be able to control which groups and individuals have access to different
sets of services. This control includes the type of access, for instance some individuals
might simply have discover-only access, but others can invoke the service.
򐂰 Performance and scale
The solution should offer a low-latency, high throughput connectivity service to mainframe
applications. At no time should the solution introduce bottlenecks or delays, particularly
during the peak banking hours.
5.3.3 Solution architecture
Bank C has chosen to implement a solution based on z/OS Connect (Figure 5-3) because
this solution provides a unified REST/JSON interface and enables service.
Mobile
JSON/REST
REST
Gateway
JSON/
REST
Application
Server
z/OS
z/OS Connect
MQ
Web
IMS
HTTP
Gateway
Application
Server
MQ
MQ
HTTP
Other
z Systems
Other
channels
Figure 5-3 REST service enablement
The major components of the solution are briefly described next.
z/OS Connect
Core banking services are exposed through z/OS Connect V1 for the following reasons:
򐂰 Application developers can discover services.
򐂰 It provides a common solution for IMS today and, in future, the WebSphere Application
Server for z/OS, DB2 z/OS and CICS subsystems.
򐂰 Tooling for data transformation is available with the IMS Explorer.
򐂰 Security capabilities including authentication, authorization and audit.
Application server
The channel applications are exposed as both MQ and REST-based services.
HTTP and REST Gateways
The inbound HTTP and REST gateways act as channel aggregation points for each of the
different channels entering the bank’s network.
56
IBM z Systems Integration Guide for the Mobile and API Economy
5.3.4 What’s next
The first REST services are being rolled out in a pilot phase, fulfilling a balance-enquiry
function from the IMS subsystem. In the near future, this will be extended to include
amendment functions which support account transfers and payments. Longer term, REST
APIs will be exposed through z/OS Connect EE V2.0 and will be consumed as part of the
bank’s enterprise-wide API Management framework.
5.4 Mobile Enterprise Application Platform
This scenario focuses on the implementation of IBM MobileFirst Server and reuse of an
existing CICS warehouse management application.
5.4.1 Introduction
Retailer A is one of the largest global retailers, operating stores and online in 12 countries
around the world. The supply chain, logistics, and warehouse management systems are
in-house-developed COBOL and PL/1 applications hosted in CICS, IMS, and DB2 z/OS.
These systems are predominantly accessed by “green screen” terminals from stores,
warehouses and regional offices in each of their operating countries.
A significant competitive differentiator for the retailer is the optimization of the supply chain.
The ability to efficiently source, warehouse and transport produce from supplier to consumer
is an important competitive differentiator.
All of the information relating to the performance of Retailer A’s warehouses is managed
by a CICS Warehouse Management Solution (WMS). To deploy the warehouse team most
effectively, the warehouse manager must regularly access WMS. This procedure requires
the warehouse manager to regularly return to a single place in a vast warehouse to access
a 3270 terminal.
The retailer decided that a better approach might be for this information to be available to
warehouse managers on a mobile device wherever they are in the warehouse. These key
questions are to be addressed in this project:
򐂰 What is the most expedient method for mobile enabling WMS?
򐂰 What mobile technology should be used for developing the app and hosting the app in an
enterprise app store?
5.4.2 Key decision factors
Retailer A considered a number of ways to mobile-enable the CICS WMS application, but the
primary factors were to implement a solution quickly, with no additional software components
deployed to z/OS and with zero outages to WMS. The key decision factors are reviewed next.
Mainframe application interface
At present, WMS functions are exposed through a comprehensive set of green screen menus
that are accessed from a 3270 terminal in each of the warehouses.
The new mobile tablet solution should not offer the same menu of functions, but rather should
focus on the most commonly used functions.
Chapter 5. Real-world scenarios
57
Existing application integration infrastructure
WMS currently runs on CICS TS V4.1 and DB2 V10. The target solution must support these
same versions. Until now, WMS has been accessed through only a 3270 interface.
Mobile app integration requirements
Retailer A has not previously deployed any mobile apps that access its CICS applications. For
this project, the following options were considered:
򐂰
򐂰
򐂰
򐂰
CICS TS Feature Pack for Mobile Extensions
z/OS Connect
Web Services
IBM MobileFirst adapter
Non-functional requirements
These are the main non-functional requirements of the project:
򐂰 Speed of deployment
The new mobile service must be deployed as quickly as possible. The objective is to
create and deliver a pilot mobile app within a few weeks, during a change freeze.
򐂰 Zero disruption to warehouse management services
WMS operates 24x7 and, during the change freeze, it is not allowed to make significant
changes to the system.
򐂰 Security
Warehouse managers log in to WMS using their SAF-based user ID and password.
Authentication with the mobile app must be done by using the same credentials.
5.4.3 Solution architecture
Retailer A does not want to exploit features in the CICS Web Interface 3270 bridge (Web
3270 bridge), which allows the company to quickly and efficiently expose the green screen
menus as a set of HTML pages. This solution requires minimal changes to the CICS
infrastructure.
IBM MobileFirst Platform Foundation on Linux on z Systems is used for the flexible adapter
framework and the integrated app store.
A summary of the solution architecture is shown in Figure 5-4 on page 59.
58
IBM z Systems Integration Guide for the Mobile and API Economy
z/OS
Linux on z
Web 3270 bridge
JSON/REST
Mobile
MobileFirst
Server
Adapter
HT TP
CICS
3270
Terminal
z Systems
Figure 5-4 Mobile Enterprise Application Platform with IBM MobileFirst Platform Foundation
The major components of the solution are briefly described next.
IBM MobileFirst Platform Foundation
This technology was employed for several reasons, including to do these tasks:
򐂰 Create the mobile app for multiple devices.
Rather than create custom apps for iOS and Android tablets, a hybrid app is created using
the IBM MobileFirst Studio, for which the application code is 100% reusable across iOS
and Android devices.
򐂰 Create HTTP adapters that invoke the Web 3270 bridge.
Adapters are developed using IBM MobileFirst Studio and deployed in an IBM MobileFirst
Server. An adapter processes a message from a mobile device as follows:
– The adapter transforms the JSON request message from a mobile device into a
request for the Web 3270 bridge.
– The adapter sends the request to CICS in an HTTP request.
– CICS starts the user application (the target 3270 transaction) running in a bridge
environment.
– The response message is returned to the adapter.
– The adapter transforms the response into a JSON message that is returned to the
mobile device.
򐂰 Simplify the mobile user interface.
In many cases, navigating the complex green screen menu system from a tablet was
impractical and so IBM MobileFirst adapter was used to aggregate multiple requests to
the CICS application, and then present a much reduced set of pages to the mobile app.
Web 3270 Bridge
The Web 3270 bridge provides an interface so that you can run 3270-based CICS
transactions without a 3270 terminal. The 3270 terminal and user are replaced by an
application program (in this case an IBM MobileFirst adapter).
Chapter 5. Real-world scenarios
59
5.4.4 What’s next
Exploitation of the Web 3270 bridge is a tactical solution delivering a mobile interface into
CICS quickly and with zero impact on the application or CICS infrastructure. However,
although expedient, this approach is inflexible because each time a change is made to
one of the green screen menus, the IBM MobileFirst adapters must also be changed.
Longer term, other connectivity options will be explored for integrating the CICS application,
specifically z/OS Connect Enterprise Edition V2.0 and web services.
5.5 API Management
This scenario focuses on establishing a managed API framework that allows developers, both
internally and externally, to discover and securely consume business services available in the
organization.
5.5.1 Introduction
Bank D is a boutique retail bank, offering a custom suite of retail and business banking
and credit card services. Its modern core banking systems are based on CICS/DB2
applications, developed in COBOL and Java. Multiple access points exist to these systems,
for example using IBM MQ and web services; however the predominant access method for
new applications is through REST services.
In recent years, the bank has made significant investment in its digital channels, supporting
new web and mobile application services. Bank D has placed customer service as its top
priority to encourage growth and has invested in new tablet applications for staff. These
mobile services need to access the core banking systems, a Master Data Management
(MDM) system and a business rules engine.
A new mobile application is being planned that will enable the bank’s small business advisors
to offer tailored financial products to customers in real time. The mobile app will allow an
advisor to meet with clients at their place of business, retrieve customer profile and financial
data, and be advised of what financial products to offer the client.
Bank D is also under pressure to respond to regulatory change and new business
requirements. Under a new regulatory directive, the bank will need to offer secure access
to its payments systems to third-party payments providers.
Based on the needs to deliver new mobile services quickly, and to comply with new
regulations, Bank D wants to enable a set of enterprise-wide APIs. The intention is to
improve agility and speed to market of new financial products by empowering the bank’s
own development community; and also to offer a subset of APIs to the bank’s partner
community in order to extend into a wider array of markets.
The key decision to address in this project is how to enable an enterprise-wide API framework
that supports these items:
򐂰
򐂰
򐂰
򐂰
򐂰
60
Development and creation of APIs
Self-discovery of APIs
Robust security and traffic shaping
Re-use of existing internal services
Insight into the consumption of APIs
IBM z Systems Integration Guide for the Mobile and API Economy
5.5.2 Key decision factors
Bank D considered a number of factors when deciding how to deploy and manage APIs but
these were the primary factors:
򐂰 To simplify the reuse of existing mainframe applications and data from internal and
external clients.
򐂰 The governance (access control, management and monitoring) of the published APIs.
Mainframe application interface
Currently Bank D uses many different interfaces to the z/OS based applications. The
requirement is to define a set of reusable APIs to increase speed of mobile app development,
and improve integration with cloud-based applications and interoperability with third parties.
Existing application integration infrastructure
The core banking systems, including the Accounts and Customer applications run on CICS
TS V5.2 and DB2 V10. The IBM Master Data Management (MDM) solution provides a
comprehensive and searchable view of customer data, and Operational Decision
Management (ODM) is used for processing business rules (for instance to determine the
level of risk in extending a loan at a given rate of interest).
Most core systems are already service-enabled as SOAP or REST services. The core
banking services have in the past been exposed as SOAP services, and more recently the
commonly called services, like balance inquiry and posting inquiry, have been REST-enabled
using z/OS Connect. In other cases, for example the Cards Management System (CMS),
applications are accessed as REST services though a Java JAX-RS layer deployed in a
WebSphere Liberty server.
The IBM DataPower Gateway is used today as a security gateway, for example, to protect
against denial of service attacks and to authenticate client requests.
Mobile app integration requirements
The new mobile app is a native iOS app that is provided to bank advisors on company-owned
Apple iPads. The app must display real-time client financial data, compare the financials
against other similar businesses located in the same area, and allow the bank advisor to
apply for a line of credit while at the client’s workplace.
The app must securely integrate with several mainframe applications through a set of APIs,
as in these examples:
listClients
Retrieve information about clients based on a set of filters, including
type of business and geographic location.
viewClientProfile
View the client profile, including address, accounts, credit cards,
outstanding loans and cash flow.
listTransactions
List the transaction history of the client.
getCreditRating
Get a credit rating.
Chapter 5. Real-world scenarios
61
Non-functional requirements
These are the main non-functional requirements of the project:
򐂰 Speed of deployment
The mobile solution must be deployed quickly in order to gain a competitive advantage
over other banks that offer similar small business financial services.
򐂰 Security
All personal and financial data must be stored on the mainframe and encrypted in transit.
򐂰 24/7 availability
As the new primary way to engage small businesses, the new mobile solution must be
available at all times.
򐂰 API lifecycle
The creation, deployment, and discovery of APIs must support versioning and be simple to
implement.
򐂰 Management and monitoring
The solution must provide the operational metrics and analytics capability to be able to
monitor API usage and manage the traffic demand when APIs are experiencing peak
loads.
5.5.3 Solution architecture
Bank D has chosen to adopt a solution based on IBM API Management because it meets the
following key requirements:
򐂰 API enablement of both REST and SOAP-based mainframe services
򐂰 Governance of APIs shared across multiple channels
򐂰 Reuse of an existing security integration architecture based on IBM DataPower
IBM API Management supports the set of REST APIs used by the bank advisor mobile
app, and will be used in the future for hybrid cloud and partner integration. The solution in
Figure 5-5 shows an example set of deployed APIs.
API
Management
Linux on z
z/OS
CMS
Mobile
JSON/REST
Cloud based
apps
WebSphere
Liberty
Server
IBM DataPower
Gateway
listClients
viewClientProfile
listTransactions
getCreditRating
etc.
CICS
Accounts
z/OS Connect
JSON/REST
CICS
Loans
Business
Rules
SOAP/HTTP
JSON/REST
Third
Party
Providers
Master
Data
Management
DB2
z Systems
Figure 5-5 API enablement of core systems
The major components of the solution are briefly described next.
62
IBM z Systems Integration Guide for the Mobile and API Economy
z/OS Connect
z/OS Connect V1 provides a REST interface to the CICS Accounts and Loans applications.
These services are used by the viewClientProfile and listTransactions APIs.
Business Rules
IBM Operation Decision Management (ODM) provides a SOAP interface that is used by the
getCreditRating API to calculate a risk score for a client.
IBM Master Data Management (MDM)
MDM contains customer profile information that is used by the listClients,
viewClientProfile and listTransactions APIs.
WebSphere Liberty
A WebSphere Liberty server provides a REST interface to a Cards Management System
(CMS) that is used by the viewClientProfile API.
IBM DataPower Gateway
IBM DataPower Gateway is used as a security gateway and provides a secure and highly
available runtime for the deployed APIs.
API Management
The IBM API Management is used to manage the API lifecycle, to create new API versions,
and to revert to prior versions when required. A developer portal is used to communicate
information about the APIs, such as the API’s interface, API documentation, and code
samples. This information allows the developers to test and try the APIs.
5.5.4 What’s next
Bank D is in the process of establishing an API framework that will be called from mobile
apps, including the bank advisor app. The bank will deploy z/OS Connect EE V2.0 to take
advantage of the workstation-based tooling and Swagger 2.0 support, which the bank chose
as the standard for API descriptions.
There is recognition in the bank that the API framework can easily be extended to support
upcoming regulations that require the bank to provide more open access to certain services,
for example, to allow third parties to initiate payments.
At this time, Bank D is also investigating the use of StrongLoop technologies to create new
APIs based on a JavaScript framework. The bank sees StrongLoop advancing the speed with
which the bank can create new APIs to then be governed by API Management, plus the
enterprise support for Node.js as a necessity for the emerging skillset in the API world.
Chapter 5. Real-world scenarios
63
64
IBM z Systems Integration Guide for the Mobile and API Economy
6
Chapter 6.
Summary
This chapter summarizes the integration architectures that can be used in mobile projects
and compares the main mobile integrations solutions that are discussed in this paper.
This chapter describes the following topics:
򐂰 Common integration architectures
򐂰 Mobile integration solutions
© Copyright IBM Corp. 2015. All rights reserved.
65
6.1 Common integration architectures
The mainframe supports a number of integration architectures that can be used in mobile
projects. Table 6-1 compares the mobile integration architectures discussed in this paper.
Table 6-1 Common integration architectures
Integration architectures
Description
When to use
APIs and API management
Architecture for creating, assembling,
managing, securing, and socializing web
APIs.
Use when business functions need to be
discoverable and need a high degree of
operational governance.
Web services
Service-oriented architecture based on
standards like SOAP, XML, and Web
services (WS.*) specifications.
Not normally used by mobile app itself.
Use when solution requires application
integration between different service
types and platforms, and XML is the
predominant data payload.
REST
Resource-oriented architecture based
on HTTP URL and verbs, and JSON.
De facto standard for mobile, web, and
cloud applications.
JSON payloads are less brittle to
application changes.
Messaging
Asynchronous transport mechanism.
Exploit when app uses MQTT and for
publish/subscribe applications, or when
reusing existing messaging
infrastructure.
Use when assured delivery is required.
66
IBM z Systems Integration Guide for the Mobile and API Economy
6.2 Mobile integration solutions
The mainframe provides a number of mobile integration solutions. Table 6-2 compares the
main mobile integration solutions discussed in this paper.
Note: For summary guidance about mobile integration solutions that are specific to the
CICS, IMS, and DB2 subsystems, see Chapter 4, “IBM z Systems mobile integration
solutions” on page 25.
Table 6-2 Mobile integration solutions
Integration solutions
Description
When to use
z/OS Connect V1
WebSphere Liberty feature that enables
REST interface to mainframe services
and builds on existing connector
technologies.
Use to enable unified REST interface
and interoperability with z/OS security
and monitoring services (for example,
RACF and SMF).
Use when you want to avoid multiple
data transformations (that is,
REST/JSON used as message format
from the mobile to the mainframe).
z/OS Connect EE V2.0
Extends the support available with z/OS
Connect V1. Includes tooling for API
creation and deployment.
Use when requiring workstation-based
tooling for creation of RESTful APIs
based on z/OS assets.
Use to enable discovery of defined APIs
based on Swagger 2.0 standard.
IBM API Management
Helps with managing the full lifecycle of
creating, publishing and governing web
APIs.
Use to extend the value of mainframe
and other assets by socializing SOAP or
REST APIs to developers, and providing
controlled access.
IBM StrongLoop
Helps with creating APIs from existing
and aggregated services, based on a
Node.js framework.
Use to rapidly create APIs that re-use
and aggregate mainframe services and
other assets. APIs created here can
subsequently be governed by API
Management.
IBM DataPower Gateway
SOA and mobile security gateway.
Use for securing mobile access to
mainframe, and as deployment runtime
for APIs.
IBM Integration Bus
ESB with comprehensive support for
any-to-any transformation.
Use for complex integration
requirements, service aggregation, and
industry-standard message formats.
IBM MobileFirst Platform
Comprehensive mobile enterprise
application platform, including flexible
adapter framework.
Use to develop server side mobile
integration code in JavaScript or Java.
Use for push notifications.
IBM MessageSight
Appliance for handling large volume of
connections from IoT or mobile devices.
Use to enable bidirectional messaging
connectivity to mobile devices. Use to
deploy a publish/subscribe pattern.
Chapter 6. Summary
67
68
IBM z Systems Integration Guide for the Mobile and API Economy
Related publications
The publications listed in this section are considered particularly suitable for a more detailed
discussion of the topics covered in this paper.
IBM Redbooks
The following IBM Redbooks publications provide additional information about the topic in this
document. Note that some publications referenced in this list might be available in softcopy
only.
򐂰 CICS and SOA: Architecture and Integration Choices, SG24-5466
򐂰 IBM CICS and the JVM server: Developing and Deploying Java Applications, SG24-8038
򐂰 IBM System z in a Mobile World: Providing Secure and Timely Mobile Access to the
Mainframe, SG24-8215
򐂰 Implementing IBM CICS JSON Web Services for Mobile Applications, SG24-8161
򐂰 IMS Integration and Connectivity Across the Enterprise, SG24-8174
򐂰 The Power of the API Economy: Stimulate Innovation, Increase Productivity, Develop New
Channels, and Reach New Markets, REDP-5096
You can search for, view, download or order these documents and other Redbooks,
Redpapers, Web Docs, draft and additional materials, at the following website:
ibm.com/redbooks
Online resources
These websites are also relevant as further information sources:
򐂰 Digital transformation: Creating new business models where digital meets physical. 2011:
http://www.ibm.com/services/us/gbs/thoughtleadership/ibv-digital-transformation.html
򐂰 Digital reinvention: Preparing for a very different tomorrow. 2013:
http://www.ibm.com/services/us/gbs/thoughtleadership/digitalreinvention/
򐂰 Swagger:
http://swagger.io/specification
򐂰 Liberty Profile z/OS Connect Quick Start Guide and Exploration of z/OS Connect
Functions:
http://www.ibm.com/support/docview.wss?uid=tss1wp102439&aid=7
򐂰 StrongLoop:
http://strongloop.com/
򐂰 IBM API Management:
http://www.ibm.com/software/products/en/api-management
© Copyright IBM Corp. 2015. All rights reserved.
69
򐂰 IBM DataPower Gateway:
http://www.ibm.com/software/products/en/datapower-gateway
򐂰 IBM Integration Bus:
http://www.ibm.com/software/products/en/ibm-integration-bus
򐂰 IBM MobileFirst Platform:
http://www.ibm.com/software/products/en/mobilefirstplatform
򐂰 CICS TG:
http://www.ibm.com/software/products/en/cics-ctg
򐂰 IMS SOAP Gateway:
http://www.ibm.com/software/products/en/imsentesuitsoapgate
򐂰 IMS Mobile Feature Pack:
http://www.ibm.com/software/data/ims/mobile.html
򐂰 IBM MessageSight:
http://www.ibm.com/software/products/en/messagesight
Help from IBM
IBM Support and downloads
ibm.com/support
IBM Global Services
ibm.com/services
70
IBM z Systems Integration Guide for the Mobile and API Economy
Back cover
REDP-5319-00
ISBN 0738454788
Printed in U.S.A.
ibm.com/redbooks