Früher war nicht alles besser!
Als Beispiel seien (RPG) Programme genannt, die den kompletten Code in einer Quellcode Datei beinhalteten.
Das waren und sind dann schnell mal einige tausend Zeilen Code, die da im Laufe der Zeit zusammenkommen.
Im Normalfall alles mit globalen Variablen (zumindest bei RPG) und jeder Menge Bezugszahlen und Goto’s.
Solche Programme zu analysieren oder gar anzupassen ist immer wieder ein aufwendiges und meist riskantes Unterfangen – selbst für die Leute, die sie ursprünglich erstellt haben, wenngleich diese meist schon nicht mehr im Unternehmen sind.
Genau aus dem Grund hat sich in der Softwareentwicklung die Idee der Modularisierung durchgesetzt, damit man große Monolithen Programme in kleinere Module „zerhacken“ kann, welche dann nicht nur leichter zu lesen und zu ändern sind, sondern auch leicht wiederverwendbar sind, denn neben dem Problem der Unübersichtlichkeit kommt ja noch dazu, dass bei älteren Programmen, Code oft in mehrere Programme kopiert wurde und nach 10-20 Jahren auf die unterschiedlichsten Arten mutiert ist.
Im Falle von IBM i und RPG kam zunächst die Anweisung CALL ins Spiel, welche es möglich machte Programme aus anderen aufzurufen und Parameter in beide Richtungen zu schieben, allerdings zum Preis von Speicherauslastung und Geschwindigkeit.
Mit Einführung von ILE Mitte der 90er Jahre kamen dann die (Sub)Procedures und Serviceprogramme hinzu, die eine völlig neue Arbeitsweise ermöglichten und leider bis heute noch nicht überall im Einsatz sind.
Plötzlich konnte man auch in RPG mit lokalen Variablen arbeiten und sich an die Programmiermuster anlehnen, die in der restlichen Welt schon zum Standard gehörten.
Eine lockerere Bindung zwischen den einzelnen Programmteilen mit einer sehr hohen Geschwindigkeit sind die Belohnung, wenn man sich auf diese Art zu Entwickeln einlässt. Dennoch bestehen auch zwischen Programmen und Serviceprogrammen noch Bindungen, die bei Änderung z.B. des Interfaces berücksichtigt werden müssen.
In anderen Programmierumgebungen ist dies nicht anders. Ob .NET, Java, JavaScript oder was auch immer. Um auch noch dieses letzte bisschen Bindung los zu werden, haben sich Entwickler auf der ganzen Welt viele Gedanken gemacht und sind letzten Endes auf das Konzept der sog. Microservices gekommen, welche es möglich machen, Funktionalität so zur Verfügung zu stellen, dass sie nicht nur modular, skalierbar, schnell, sicher und plattformunabhängig ist, sondern auch ohne jegliche statische Bindung auskommt.
Dank IceBreak, dem einzigen nativen ILE Webserver und Applikationsserver, steht diese Möglichkeit auch allen IBM i Entwicklern zur Verfügung. Ob in RPG, Cobol, C, C++ oder CL entwickelt wird. Jegliches ILE Serviceprogramm lässt sich mit IceBreak als Microservice nutzen.
IceBreak übernimmt dabei auch die Rolle des zentralen Microservice Routers. D.h. jegliche Anfragen von außen kommen mittels Parameter und werden dabei i.d.R. als JSON Dokument oder in der URL übergeben.
Dadurch kann sich das Interface einer Funktion ändern, ohne, dass man irgendwelche Programme zwangsläufig umwandeln muss.
Nehmen wir als Beispiel den Service „msProduct“, der über die Procedure „getRows“ verfügt und uns Produkte aus der Tabelle (PF) PRODUCT in Bibliothek IceBreak zurückgibt:
https://as400:60060/router/msProduct/getRows?payload={
“start”: 11,
“limit”: 20,
}
Erweitert man das Interface jetzt z.B. noch um einen Suchparameter:
https://as400:60060/router/msProduct/getRows?payload={
“start”: 11,
“limit”: 20,
“search” : “sony”
}
müssen alle Programme, die den Service bisher aufgerufen haben in keinster Weise angepasst werden, sofern sie den neuen Parameter nicht benötigen.
Positiver Nebeneffekt dieser Programmierweise:
Diese Services lassen sich von überall aufrufen. Ob RPG Programm oder .NET Dienst, Desktopprogramm, aus Webanwendungen oder mobilen App’s.
Sie sind an einer Zusammenarbeit oder Beratung in diesem Bereich interessiert?
Kein Problem.
Schreiben Sie mir einfach.
Ich freue mich auf Ihre Mitteilung unter
Email: mal@mlitters.com
oder rufen Sie mich einfach an.