Framework
This is a rant explaining why we have our own framework and why you should seriously consider using Q2, even inside your preferred framework.
jPOS has a long history. We started the project right after Java 1.0 was released, we were quite excited with the mysterious OAK language. There were no frameworks those days, not even IDEs. No Gradle, no Maven, no Ant, no logging frameworks, and not even Java EE. There were no Java collections, no Java concurrency, not even platform threads; we ran off the so-called 'Green Threads'. No NIO, no Generics, no Lambdas. At that time, Java had approximately 460 classes in its rt.jar. CVS, vi, and make were our tools.
We were early adopters of many frameworks. Most notably, we embraced JINI, which was an amazing piece of technology with its Reggie, Mahalo, and JavaSpaces. Then came J2EE in its various versions, starting with J2EE 1.0, which was configured out of serialized classes (not even XML). We followed JBoss, PicoContainer, QI4J, and the awesome JPublish to deal with SSR (20 years ago). We also got excited about all the trends, such as AOT with AspectJ and OSGi with its various implementations, among others.
As users began implementing gateways and switches using jPOS, we faced the challenge of providing runtime configuration for a rapidly growing number of servers, channels, and multiplexers. In some cases, there were thousands of these components within a single server. We also needed ways to secure credentials and encryption keys, ensure PCI-compliant logging, and implement alerting. Additionally, during a time when machines weren't very fast, it was crucial to reconfigure the system on the fly with minimal downtime. We achieved this by hot-deploying functionality through dynamic class loading and seamlessly adding or removing services.
The framework was called QSP and was named after an initial gateway application used to convert XML to ISO-8583.
QSP is a Q code used in ham radio that means "Relay message, for free". Because jPOS is free software, we found the "QSP" code very appropriate. Actually, a brilliant name, unfortunately, just for a nerdy mind.
QSP was very simple, it used a single XML file containing the configuration for the whole application. As applications started to grow to hundreds of endpoints, we felt the need for a full rewrite and we decided to have one service per XML configuration, so each service life-cycle could be handled separately, and that's when Q2 was born. Q2 was basically QSP version 2.
Q2 is very simple. Everything is a service that we call a QBean. QBeans are registered in a JMX MBeanServer and have a very simple life-cycle:
- init
- start
- stop
- destroy
Services are defined in a directory called deploy that is actively monitored by the Q2 process. These services can be managed and monitored via JMX. Services are defined in an XML file that we call QBean descriptors.
Q2 is the control plane of your jPOS based application.
Alright, this is nice, but you might be thinking, "You didn't have popular frameworks 25 years ago, but you do have very mature ones now!" And you're absolutely right. The problem is, there are too many of them. We have people using jPOS inside application servers, sometimes legacy ones. People are using it on mainframes. You might prefer Spring, but perhaps you lean towards Vert.x, Micronaut, or you want to stick with Microprofile. Maybe you're a SuperSonic Subatomic developer running Quarkus, and that's perfectly fine. The good news is, you can launch Q2 inside your preferred framework with just a single line of code:
new Q2().start();
While you might lean towards using frameworks X, Y, or Z and setting up jPOS components using Java, we strongly recommend exploring Q2. Directly integrating components can become a complex task, especially when ensuring all parts communicate seamlessly. You might be hesitant about XML configurations, but remember, you're already familiar with POMs. Please invest some time in the upcoming chapters, where we delve into the workings of Q2, the jPOS Space, and the Transaction Manager. This knowledge will be invaluable, streamlining your transition to production and saving you significant time in the long run.