This post is part of a series exploring the unique aspects and capabilities of WebSphere Liberty when running on z/OS.
We'll also explore considerations when moving from WebSphere traditional on z/OS to Liberty on z/OS.
To start at the beginning, follow
this link to the first post.
The next post in the series is
here.
---------------
WebSphere Application Server (or WAS to its friends) began life as a product called Component Broker. There were originally totally separate versions (and code bases) for z/OS and what we called ‘distributed’, by which we meant everything that wasn’t z/OS. In the beginning it all existed to support CORBA distributed objects, mostly written in C++. There was no Java at all (Java was a new thing at the time).
Eventually the product got renamed, Java support was added, and the focus shifted to Java EE and support for native (non-Java) objects went away. But the separation of a z/OS version from everything else remained.
From the very beginning the distributed version existed in a single process, but z/OS was different. Stealing from the idea of a CICS TOR/AOR (terminal-owning/application-owning region) or maybe from an IMS control and dependent region, WAS on z/OS consisted of several processes. Originally it was a control region and a server region. Later it became a controller region and a servant region. I’ve forgotten why, but the slight name change was a real hassle at the time.
While originally the two implementations were totally separate, as we moved to support Java EE we shifted to a common code base, at least for the parts that were closely involved in the application. The servant region (where the application runs) were more common code with distributed than not, while the controller region remained all non-Java and unique to z/OS.
As more time passed, a JVM was introduced into the controller and some common code with distributed existed there too. Nevertheless, the z/OS and distributed implementations remain quite different internally and interesting situations developed where the distributed implementation code assumed a single process but found itself running in one of several processes that made up a server instance on z/OS.
Eventually, for reasons best gone into elsewhere, a decision was made to start mostly all over and write a new server that was ultimately named Liberty. Given the history of problems with differences in between z/OS and distributed implementations, we decided from the start that at the core there would just be one implementation that worked exactly the same everywhere. That said, we would add optional additional features specific to z/OS that would let us integrate with and exploit z/OS capabilities. But they would all be optional (well, mostly…).
And so, at an extremely high level, that’s how we got to where we are. Next we’ll go through the long and sordid history of product names. Sigh….