Rocketing Ahead With An API Engine

June 26, 2017 Timothy Prickett Morgan

The history of computing is governed by a plethora of opposing forces, with the polar opposites interweaving and interleaving to create more general trends that undulate and cause the waves we ride on top of or get swamped by. There is a tendency toward abstraction and the desire to get closer to the iron to wring the absolute most performance out of a specific system, for instance. Humans don’t think in binary or assembler – well most humans don’t but there are always a few genius weirdos – so the speed of execution is sacrificed for the speed of the process of coding and the shareability of the resulting code.

In the hyperscale world, the metaphor of choice for application coding is the application programming interface, or API. It is this API abstraction layer that can make an operating system, a SQL database or a NoSQL data store, a file system, any of a number of frameworks for doing all kinds of other levels of abstractions, any virtual machine (Java, hypervisor, or whatever), and any programming language callable from any other software device. There are even APIs to talk to firmware and hardware and to invoke their functions. It is the API that makes n-tier applications running on a single system or diverse applications with various levels of tiering and scale on distributed systems talk to each other and perform a workflow that actually comprises the work. APIs make object-oriented programming happen outside of a particular runtime and across runtimes. They are what make the IT infrastructure of the world go around and around, and perhaps more importantly, when functions in systems and their often monolithic applications are exposed as APIs, they actually preserve those functions and make them usable for more sophisticated applications that will build upon them. APIs open up applications while at the same time making them stickier. That’s a neat trick, that.

It has been a long journey from the 5250 green screens that were the only option for communicating from the outside world into an IBM midrange system back in the 1970s and 1980s, and at the tail end of that the PC went commercial and Windows became the de factor desktop for business and the client/server revolution exploded and screenscaping – the act of programmatically transforming those fields in the hundreds to thousands of green screens that actually comprised an old-school, monolithic RPG or COBOL program into something that looked and felt like a native Windows application. Even though screen scraping in its various guises helped keep many OS/400 and IBM i applications relevant in prior decades, and is still used for certain parts of the application stack, even if the mouse did not kill the green screen, the touchscreens on smartphones and tables and the poking and pinching and swiping that we all do with these devices pretty much did. And now, because just making a screen prettier is not enough, API abstraction layers are the way that many applications are being rearchitected for more modern devices.

“What we find is that almost everybody in the IBM i base has some sort of modernization effort going on,” says Dan Magid, vice president of applications development and DevOps and chief technologist for IBM i solutions at Rocket Software, tells The Four Hundred. “But screen scraping and similar technologies were very much centered on the IBM i programming staff. What we are seeing in a lot of situations is that there is a web development or a mobile team that is doing this work and it is not necessarily the IBM i team that is doing it. And even when the IBM i team is doing the work, they are being told to go learn Node.js or Angular or Ruby and that this will be their job. So the focus for a lot of our customers is to expose the existing application functions and data from the IBM i platform so it can be consumed by these other teams, and a lot of times these people do not know anything about the IBM i platform. The just want a web service that they consume.”

This, says Magid, is why sales of a new tool called Rocket API, has been taking off and now has a base of a couple of hundred users, which is pretty big compared to the 700 or so customers that are using the LegaSuite application modernization tools from Rocket or the even larger and older base of thousands of customers using J Walk and other products. Rocket API allows companies to sniff around their monolithic RPG and COBOL applications and generate API calls based on the screen interactions and hand them over to people who have no idea what an IBM i platform, RPG or COBOL, or the DB2 for i database management system, is.

One insurance company that is a Rocket API customer had two full time people who were writing APIs from scratch in a bunch of different programming languages, and with this API layer they are now able to kick out several new services based on the API engine every workday – much more quickly. And it lets them tie these back-end IBM i services into whatever tool they are using to create the application because these are all just RESTful APIs that are being called.

“Building Windows interfaces was hard – it was a lot of work,” says Magid. “Building web interfaces is not that hard, and now the effort is in getting that function out of the existing system.” The other big benefit, he adds, is that Rocket API can support multiple datastreams from legacy systems and customers can create web user interfaces that uses APIs to call multiple functions from multiple applications running on multiple (and sometimes incompatible) platforms. At Safety Insurance, a marquee customer that has deployed Rocket API, the software is being used to glue together functions embedded in applications running outside of the company as well as inside, and now eleven queries that are necessary to do a claim processing request is done with a single click that kicks off an API call across those eleven application functions.

“One of the other drivers of demand for our Rocket API product is that more and more executives are recognizing the significant value the IBM i and their IBM i applications provide,” Magid explains and this is good news for the IBM i installed base. “We are hearing much less talk of replatforming. Rather than embark on the risky and expensive path of moving platforms, they are now focused on leveraging that IBM i value while using Rocket API to expose those application functions and that IBM i data via new technology and interfaces. They much more rapidly get the benefits of innovative technology while protecting their existing investment in the IBM i.”

The API server at the heart of Rocket API can run natively on IBM i itself or it can run on external servers running Windows or Linux or even on Linux partitions on the same physical system as the IBM i applications. The API server is multithreaded and can run distributed across multiple sockets and nodes to scale without too much overhead. It dings somewhere between 5 percent and 10 percent of the performance of the system and adds a little more to the application latency, but not so much so that end users will get annoyed – on the order of 5 percent or so. As security and management functions are being added to Rocket API, the latency could get a bit larger, but even 10 percent of a sub-second response time is not so bad. If the overall transactions have a latency of under 200 milliseconds, no one will even notice, we think.

The Rocket API engine is written mostly in Java with a little bit of C/C++ where the performance is particularly important; it was created by a handful of developers who were instrumental in creating the foundational SmallTalk object-oriented programming language that was, before Java came along in 1995, supposed to be the future of cross-platform programming at Big Blue. (Remember that who AD/Cycle thing?) Rocket API has value-based pricing, which is available under a perpetual license or a monthly license and which scales with the amount of traffic that gets pumped through the API engine and how many calls it does. The perpetual license costs anywhere from around $10,000 for a small organization to six figures for larger organizations that crank a lot of API calls; if you divide the perpetual price by 36 months, that is about what the monthly service fees are for the tool.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search