Why z/OS is a great platform for developing and hosting APIs
•Download as PPTX, PDF•
0 likes•41 views
Why z/OS is a great platform for developing and hosting APIs
Recommended
Recommended
More Related Content
What's hot
What's hot (16)
Similar to Why z/OS is a great platform for developing and hosting APIs
Similar to Why z/OS is a great platform for developing and hosting APIs (20)
More from Teodoro Cipresso
More from Teodoro Cipresso (11)
Recently uploaded
Recently uploaded (20)
Why z/OS is a great platform for developing and hosting APIs
- 1. Why z/OS is a great platform for developing and hosting APIs Session 21911 Shawn Benham Teodoro (Ted) Cipresso 0
- 2. Notice and disclaimers This presentation is provided by IBM Corporation. Copyright © IBM Corporation, 2018. Use and distribution by SHARE, Inc. permitted by license. Redistribution is prohibited. U.S. Government Users Restricted Rights — use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM. Information in these presentations (including information relating to products that have not yet been announced by IBM) has been reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM shall have no responsibility to update this information. This document is distributed “as is” without any warranty, either express or implied. In no event shall IBM be liable for any damage arising from the use of this information, including but not limited to, loss of data, business interruption, loss of profit or loss of opportunity. IBM products and services are warranted according to the terms and conditions of the agreements under which they are provided. IBM products are manufactured from new parts or new and used parts. In some cases, a product may not be new and may have been previously installed. Regardless, our warranty terms apply. Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without notice. Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual performance, cost, savings or other results in other operating environments may vary. References in this document to IBM products, programs, or services does not imply that IBM intends to make such products, programs or services available in all countries in which IBM operates or does business. Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation. It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its services or products will ensure that the customer is in compliance with any law. 1
- 3. Notice and disclaimers continued 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 in connection with this publication 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. IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to interoperate with IBM’s products. IBM expressly disclaims all warranties, expressed or implied, including but not limited to, the implied warranties of merchantability and fitness for a particular, purpose. The provision of the information contained herein is not intended to, and does not, grant any right or license under any IBM patents, copyrights, trademarks or other intellectual property right. IBM, the IBM logo, ibm.com, AIX, BigInsights, Bluemix, CICS, Easy Tier, FlashCopy, FlashSystem, GDPS, GPFS, Guardium, HyperSwap, IBM Cloud Managed Services, IBM Elastic Storage, IBM FlashCore, IBM FlashSystem, IBM MobileFirst, IBM Power Systems, IBM PureSystems, IBM Spectrum, IBM Spectrum Accelerate, IBM Spectrum Archive, IBM Spectrum Control, IBM Spectrum Protect, IBM Spectrum Scale, IBM Spectrum Storage, IBM Spectrum Virtualize, IBM Watson, IBM Z, IBM z Systems, IBM z13, IBM z14, IMS, InfoSphere, Linear Tape File System, OMEGAMON, OpenPower, Parallel Sysplex, Power, POWER, POWER4, POWER7, POWER8, Power Series, Power Systems, Power Systems Software, PowerHA, PowerLinux, PowerVM, PureApplication, RACF, Real-time Compression, Redbooks, RMF, SPSS, Storwize, Symphony, SystemMirror, System Storage, Tivoli, WebSphere, XIV, z Systems, z/OS, z/VM, z/VSE, zEnterprise and zSecure are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at: www.ibm.com/legal/copytrade.shtml. Linux is a registered trademark of Linus Torvalds 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. 2
- 4. The belief 3
- 6. Why z/OS is a great platform for APIs 5
- 7. Why z/OS is a great platform for APIs • Mainframe applications are integral to business. 80%. • Their transactions and data can be published as fully RESTful APIs. • Modern z/OS is built with hybrid cloud and mobile development in mind. • You can drive a CICS/IMS/DB2/MQ or other transaction from a mobile or Cloud application … without even knowing it. • Likewise, a CICS or IMS COBOL or PL/I program can call a RESTful API…located virtually anywhere. 6
- 8. The history of APIs 7 1960 - 1980 1980 - 1990 1990 - 2000 2000 - today Application specific interfaces. Generic interfaces called by many applications. Focus on making it easier to provide and manage interfaces. Focus on making it easier to discover, consume and combine interfaces. Source: Deloitte University Press, API economy: From systems to business services
- 9. RESTful APIs and OPEN API 8 • To programmers, consuming APIs is a daily practice as most products document APIs that can be called from applications. • RESTful APIs are a good choice—particularly when agnostic of hardware, OS, and programming languages. • Why are RESTful APIs good for your business? • Your developers can compose apps more quickly by incorporating tested APIs instead of reinventing functionality which will then need to be tested. • Other businesses can compose apps that incorporate APIs you’ve chosen to make public which can bring new customers and increased revenue. • The Open API specification (openapis.org), makes it easy for people and machines to understand the capabilities of an API without access to source code, online help,…,etc. http://openapis.org
- 10. Why use Swagger / OPEN API? 9 It is more than just an API framework Write Swagger Swagger Editor allows API developers to design their swagger documents. Read Swagger Swagger UI allows API consumers to easily browse and try APIs based on Swagger Doc. Consume Swagger Swagger Codegen creates stub code to consume APIs from various languages There are a number of tools available to aid consumption:
- 11. The digital supply chain has been unlocked 10 Sources: programmableweb.com, venturescanner.com Raw materials End product Raw data Refinement (functions & services) Customer experience 3rd party experience 4th Party Refinement 4th Party experience 5th Party experience 4th Party Data Multiple companies add value at different parts of the supply chain. The cost of entry is low. Variety of experiences is high.
- 12. Turn IT into a profit center 11 There is an opportunity to change the way we think about IT From A necessary cost to create an end product. Revenue from the end product is not passed down the chain. Therefore there is a focus on trying to reduce cost. To IT is the end product or at least a link in the supply chain. Sell its value directly onto the next customer in the chain, at a margin that covers the cost of providing it.
- 13. Developers are your new customers 12 Discoverable Developers APIs are your new products
- 14. Create truly RESTful APIs to and from your mainframe with z/OS Connect EE 13 APIs to and from the mainframe Comprehensive subsystem support Point-and-click API creation Try for yourself: ibm.biz/ibmztrial Call external APIs from your mainframe applications, or expose those applications as easily consumable RESTful APIs with OpenAPI descriptions - with simple integration into enterprise API management solutions. Learn more: ibm.biz/zosconnectdc
- 16. • A Business Analyst at the “OfficeMix” company determines that an API which allows consumers to browse for and order office supplies is required for development of client-facing mobile and Web applications. • Due to several mergers and acquisitions, the “OfficeMix” company already has the required application logic and databases, but they are spread across multiple z subsystems. Scenario (fictional)
- 18. OfficeMix API Impact Analysis Demo Dealing with Change in Services
- 19. CAPTURES – MULTI-SUBSYTEM API DEMO 18
- 20. 19
- 21. 20
- 22. 21
- 23. 22
- 24. 23
- 25. 24
- 26. 25
- 27. 26
- 28. 27
- 29. 28
- 30. 29
- 31. 30
- 32. 31
- 33. 32
- 34. 33
- 35. 34
- 36. 35
- 37. 36
- 38. 37
- 39. 38
- 40. 39
- 41. 40
- 42. 41
- 43. 42
- 44. 43
- 45. 44
- 46. 45
- 47. 46
- 48. 47
- 49. 48
- 50. 49
- 51. 50
- 52. 51
- 53. 52
- 54. 53
- 55. 54
- 56. 55
- 57. 56
- 58. 57
- 59. 58
- 60. 59
- 61. 60
- 62. 61
- 63. 62
- 64. 63
- 65. 64
- 66. 65
- 67. 66
- 68. 67
- 69. 68
- 70. 69
- 71. 70
- 72. 71
- 73. 72
- 74. 73
- 75. 74
- 76. 75
- 77. 76
- 78. 77
- 79. 78
- 80. 79
- 81. 80
- 82. 81
- 83. 82
- 84. 83
- 85. 84
- 86. 85
- 87. 86
- 88. 87
- 89. CAPTURES – DEALING WITH CHANGE 88
- 90. 89
- 91. 90
- 92. 91
- 93. 92
- 94. 93
- 95. 94
- 96. 95
- 97. 96
- 98. 97
- 99. 98
- 100. 99
- 101. 100
- 102. 101
- 103. 102
- 104. 103
- 105. IBM Application Discovery and Delivery Intelligence (ADDI) 104 z Systems applications Interfaces defined? I know what I have z/OS Connect Enterprise Edition Yes they are well defined IBM Application Discovery and Delivery Intelligence (ADDI) Help me understand what my estate looks like Now I understand! Refactor code with Application Delivery Foundation (ADFz) and Optimize Testing with ADDI No This looks better!
- 106. How can ADDI help you in API enablement? 105
- 107. API impact analysis 106 Improved graphical view (as observed in the figures) of the relationships between the application’s technical components and the APIs/related services (defined by IBM z/OS Connect Enterprise Edition) - Assist developers to modify an application with greater confidence. For each API or service, you can discover which applications implement the API business logic, A detailed call graph of the API business logic implementation down to the program, table and file level.
- 108. Resources 107 Downloads Explore the docs Where to get help z/OS Connect EE open beta runtime z/OS Connect EE workstation tooling z/OS Connect EE Knowledge Center z/OS Connect EE Developer Center dW Answers z/OS Connect EE open beta forum ibm.biz/zosconnect-open-beta ibm.biz/zosconnect-tooling-download ibm.biz/zosconnect-kc ibm.biz/zosconnectdc ibm.biz/zosconnect-dw-answers ibm.biz/zcee-beta-forum
- 109. IBM z Trial 108 Try the latest z/OS Connect EE capabilities today at zero cost, and with no installation required. IBM z Trial Program Find out more, and sign up now at ibm.biz/ibmztrial
- 110. 109 PERSO N PROGRA M PROJECT Complete your session evaluations at www.share.org/evaluation and see your progress on the leaderboard!
Editor's Notes
- FOLKS! Your time is valuable…so work with me a bit here so I can optimize this session for you. How many of you, by show of hands, need me to spend a lot of time explaining why z/OS is a great platform? Good—and not a surprise. This IS SHARE. I will move fast in that section! How many of you, show of hands, know the term RESTFul API? Swagger/OPEN API? OK. Maybe touch on that. Anthony Pappageorgio has a session Thursday which will cover that in more detail. The plan: I will cover some general concepts and terms fairly quickly. Ted will take us through creating services and APIs. He will also—provided I am efficient—go over what happens when things change. We call that impact analysis
- I dare you to find a trademark that we have missed!
- Is this what your decision makers think when the hear the word mainframe It is a somewhat frightening picture…particularly that sweater! I do like the 3277-ish GA device on the left Anyone else create graphics on one of those in the 80s by chance? Anyway...the belief in many areas is that z has not changed in 30 years and that it old, slow, and on its way out. It is not…from many perspectives…and one of them is how ideal it is to support APIs and the API economy. More on that in a bit.
- The reality is that the modern mainframe—in addition to looking a lot cooler—is an excellent platform for supporting pretty much anything. That includes modern business applications and digital supply chain needs. That means it is a great place to create and deploy APIs. It really is easy to make valuable z/OS assets available, via modern APIs, to your entire enterprise. We will show you. Don’t worry about all the acronyms and terms for now…
- The title of our session is why z/OS is a great platform for APIs. So—I should mention why z/OS is a great platform for APIs. STUFF ON THE RIGHT – you know this. The legendary capabilities you have leveraged for years also work quite well to support service creation, API creation and API hosting to consumers. Who wants a slow, un-dependable, un-reliable service, un-secure service? FWIW…this is not just my opinion In their own words, this is what developers called out during a 2018 API Days session when asked “what makes a bad API”? Slow Unreliable Any downtime (!) Slow (performance) under load Guess which platform can do all that?
- You all know the figures…around 80% of what matters to businesses is on or accessible to mainframes. SO WHY MOVE IT! The RESTFul API message is a little more recent and we will get more into that in a bit. For now, just know it is an architectural style of accessing and updating data with an intent of being simple and intuitive for the application developer (consumer). The cloud and mobile messages are not new—you have heard them for years and I am not going to beat that horse. When millions of mobile requests come in…you want to be running on something that scales. Z APIs are a great way to support those requests. 4th bullet: we will show you. The last bullet is about something we introduced into zCEE a few months back called the API Requester. Translation: outbound support. Your z/OS apps can now call APIs pretty much anywhere. TONY WILL COVER THIS THURSDAY
- Don’t worry—no history lesson. Just look at the right. Standardized…consumable…with a single starting point at top. Nice! But what do we MEAN by an API? David Berlind at ProgrammableWeb has a nice analogy. A user interface for software. But we can do better than that. Consider the modern electrical wall outlet. Your vaccum cleaner has a pretty darn good idea of what it is going to get when it is plugged in to a U.S. outlet: electrical service…coming at 120 volts… and 60 hz AC. Why am I talking about vacuum cleaners: the idea is that good, modern business APIs are standardized, discoverable, and consumable. By the way, there are standard approached for that.
- REST stands for Representational State Transfer. It is not a language. It is an architectural style for accessing and updating data, typically using HTTP. My simple approach: It is a verb and a thing. And the verbs are simple: GET, PUT, POST, DELETE This is intuitive for the end consumer (the developer). Why should you care: 85% of all services are now JSON/REST (Programmable Web). This is where the world is headed. Ted—maybe we can just show an example later on? Open API? Next chart…
- Swagger and Open API are essentially interchangeable (Open API is the new name for Swagger) I do agree with Jeff Besti—had a great session earlier this week on APIs—Swagger is a much better name. WHAT IS IT? The OPEN API INITIATIVE specification aims to “define a standard, language-agnostic interface to REST APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.” [https://www.openapis.org/specification/repo] NET: OPEN APIs are easier to discover, understand, and use. Swagger also provides some really useful open source tools—they are shown above.
- Why should you even care about RESTful APIs and Swagger? With supply chains going digital that means they are becoming more and more unlocked and consumable to all. This means that different companies can come in an add value at different points in the supply chain. Specialization is much easier. Adding unique value is much easier. This increases the number and overall quality of experiences available to customers, by allowing 3rd parties to work on a smaller piece of the supply chain, and do that piece really well And a really good way to grab a piece of this supply chain is to offer a great service accessible through a standard API.
- Why do I keep talking about external opportunities? We need to change our mind set. This is not just about reducing expense internally. Because the API value is exposed earlier in the supply chain than before, the IT function of a business can potentially turn itself from a cost center into a significant profit center. Don’t get me wrong: reducing internal cost by simplifying and speeding internal service access is—but why not set yourself up to make a profit as well?
- Application developers are the true client—whether internal or external. Does not matter. Given the choice of APIs available, developers can afford to be picky. So—what are they looking for? This slide calls out some of the things developers a looking for from a ‘good’, modern, business API or when attempting to compose an API. (Composable = objects from one API can be used as input to another.) So—what product can help you do this?
- Ted will now run a demo. While setting up, just a few points: --zCEE is great for creating APIs to the mainframe (inbound). You can literally create services and APIs with 0 programming. --zCEE is also great for helping your COBOL and PL/1 apps access APIs in other LPARS or anywhere else. In this case, some program manipulation is required but we generate a lot of the required code.
- Here is a list of useful resources for z/OS Connect EE. (Don’t forget to download the runtime and the workstation tooling.) dW Answers and the open beta forums are regularly monitored by the development team.
- If you’d like to try out z/OS Connect EE without installing it, sign up for the IBM z Systems Trial Program: ibm.biz/ibmztrial