In “IBM i and DataPower as a SOA Host Platform”, I reasoned my decision to choose IBM i and IBM Datapower as my platform going forward. This is not a “keep” of an older decision on my part as my firm did not have an IBM i or any other Power Systems platform. This was a wholly new direction based on need and features.

In this post, I will take readers from that decision onto outlining both a Hardware Infrastructure View and a Software Architecture View. Then I will walk you through a typical transaction.

To start, one of my requirements was for a highly available (HA) platform. I wanted a no-single-point-of-failure design with each component able to fail to an alternate site. The disaster recovery site would be a warm site, not a hot load balanced site. This allows me to put the hardware in place as it is fairly inexpensive and only license the capacity I need at the hot main site. IBM allows me to shift my licenses between the machines when I failover for maintenance.

In the design to the left, the bottom portion is the new Power11 Servers with Flashsystem storage. We consulted with IBM Expert Labs to configure the systems for HA using independent ASPs (iASPs) on the IBM i with Global Mirror. Under normal operation, the SAN is being mirrored, thus offloading that workload to the SAN. Both of the IBM i are running but only one has the iASP attached. The DataPowers are load balanced in HA and point to the prod machine unless there is a failover. In failure, the failed component in the DR site can take over. This, in the case of the IBM i, would mean mounting the iASP. Now for the real work. How do we design our software architecture to make this a SOA platform that requires less focus on technology and gives more time for business functionality? That performance/efficiency benefit comes from simplification.

Below is the high-level view of what I see as our Services Oriented Architecture.

The bottom left, “Application Specific Services” is where all of the business logic is orchestrated. I chose to use RPG (**FREE) as the programming language of choice for the platform. At least the way we use it, the name RPG really is immaterial. Not only do we not do any legacy type of RPG coding, we don’t even do what might be in the realm of modern RPG. To us, this language should be called PL/i only because PL/SQL is already taken. That’s a lower case i for integrated not an upper case I for one. We use it for data structures and control structures to contain what is primarily SQL cursor loops and independent SQL statements. We considered Java and C++ as well. But RPG is more up to date. And RPG being an SQL precompiler based language gives us better performance using database API calls rather than interpreted SQL at runtime versus Java/JDBC. All of them could also do record format I/O rather than SQL, but on the advice of IBM Expert Labs, we decided SQL was the better approach and that made RPG the better language. Much of this had to do with our pervasive use of XML parsing and the XML Datatype inside SQL. As well as SQL being the best interface for calling external web services and for publishing RPG programs as webservices by first making them into stored procedures as recognized by SQL/DB2. Another benefit is that IBM controls what is RPG. So, it never gets outdated by committee or forked off into different strains. It is what IBM says it is. That may not sound like a benefit. But in a world where you need to stay up to date, trust me, it is.

So, our RPGSQL applications are represented in the lower left corner of the diagram. We design our RPG modules to be services and orchestrate them via RPG programs and by implementing Data Queues for service invocation when we want to do something asynchronously, which also allows us to multithread the queue with multiple jobs running the same service. That’s our full stack for business services: RPG with SQL with XML. But what else is in the SOA diagram?

Most importantly, we connect externally exposed services and higher-level orchestrations as program calls using the built in IBM Webshere Server (Apache). Using the HTTP Admin (http://myhost:2001/HTTPAdmin) interface, we publish the program call as a web service. In the case of passing large payloads (e.g. XML documents) as a parameter, we generally use SQL to first publish the program as a Stored Procedure in SQL. Thus, the HTTP Admin setup is to publish the stored procedure as a web service. In either case, we use a single application owner as the user account to run the webservice. Keep in mind in the diagram that this is behind the security infrastructure of the DataPower and the IBM i is not internet accessible. One can do the same configuration in the IBM Cloud. We are on premises because it made sense for us to start there for production data. But I do envision prod joining dev in the IBM Cloud in the future.

Next up on our diagram is the DataPower. It is used as outlined for security, message standardization, and message dispatch. Thus, applications will call services published by DataPower with the security credentials required. For web and mobile apps, this is a signed OAUTH token with claims. The client app signs on to the Identity and Access Management in the cloud and gets the token. Then the app calls the API published by DataPower, which validates the token and calls the API published by IBM i. The claims, such as who is this user or what role are they tied to, get passed as additional parameters in the IBM i service definition that are not passed parameters on the DataPower service definition.

By offloading the transform and transport mechanism to the DataPower, I not only gain in labor efficiency by using the right tool for the right job, but I also gain by limiting the size of my Power11 system and in turn the number of IBM i licenses to the business processing that is done on the IBM i. Again, right tool for the right job.

And that is how our SOA architecture implements a web or mobile application. In the web case, our application is served up as HTML/CSS/JS (top of the infrastructure diagram). That web app authenticates the user against the cloud IAM to get a token. The app calls various APIs published on DataPower, presenting the token with claims. The DataPower calls the real API endpoints on IBM i turning claims into additional parameters so that the IBM does not have to act as an identity provider but just as a service provider and the service runs under a service account. The IBM i scales out services internally using Data Queues and Jobs. And SQL is used to make any external service calls proxied by DataPower as well to layer-in external security requirements.

We also support a high number of system-to-system e-business services. For us this means HIPAA X12 EDI, NCPDP SCRIPT, HL7 ER7, HL7 CDA/XML, and HL7 FHIR/JSON forms of data. It also means TCP, sFTP, SMTP (Direct Secure Messaging), SOAP Web Services, and REST Web Services for transport with varying security and identity features. All of the security, transforms, and transports are again in the DataPower and the service invocation is a web service connection to/from the IBM I; keeping the business service programming about business, not about connection details.

As you may note, I am only using two products, IBM i and IBM DataPower, from a software architecture perspective. There aren’t layers of products for databases, messaging, orchestration, access control logic, business logic execution, etc. With IBM i, it isn’t just one vendor, it’s one product. Same with DataPower as an appliance. So, all my back-end programming staff does is program RPG/SQL with a little XSL/XQuery. This simplification allows them to concentrate on the real value of software engineering that is working with users to document business use cases and turn those into services.

My next post will be on programming in this model with examples using VSCode as our IDE and PowerVS for our dev platform. But I won’t be done there. I’ll bring it home with a sample web app and IAM integration before going into AI enhancement later this year.