Evolution of Microservices and the Payara Platform Solution

For some time now there has been an undeniable growth of interest for Microservices. The core concept itself, however, is not that new.

As early as 1996 we talked about distributed objects, mainly in the context of an early and now mostly forgotten technology called CORBA. CORBA promised to deliver business objects, for which the network and their exact implementation was mostly abstracted away. In a CORBA world, these business objects representing a service that focused on a single thing could essentially live anywhere. If an application was the aggregation of a number of these distributed objects, each of them living on their own server, one could be updated or restarted without having to take down the entire application.

Unfortunately, CORBA as both a spec and an implementation was riddled with issues and soon faded away. After CORBA came EJB, which was originally a remote only technology, EJB re-used many parts of CORBA but also invented many parts of its own. Specifically the component model was unique to EJB, and at the time was actually considered as “CORBA done right”, after similar attempts to create such model all painfully failed in CORBA itself. Around the time of EJB, the term “distributed objects” changed to “remote objects”. 

With CORBA and Remote EJB being based on binary protocols, the next step in this evolution came when Microsoft came up with SOAP (Simple Object Access Protocol) as an XML based format using  mainly HTTP as its network protocol. Of course, many technologies that have “Simple” in their name aren’t actually simple at all, and for SOAP this indeed appeared to be true.

Nevertheless, SOAP had some advantages over remote EJB in that it was language neutral and somewhat possible for humans to read the XML messages being exchanged. Java EE embraced SOAP as a first-class technology, first with JAX-RPC and then with JAX-WS. The nomenclature also changed. From “distributed objects”, via “remote objects” and “simple objects”, we arrived at “web services”. Although there are subtle differences in concepts all these evolutionary variations can essentially do the same thing; provide a single business function to remote clients.

Despite simplifications in working with SOAP that JAX-WS had brought about, SOAP remained a rather complex technology. It had originally been designed to be used via another “Simple” technology called SMTP (Simple Mail Transfer Protocol), or in other words email. Of course, nobody ever used SOAP over email and in practice, only HTTP was used. SOAP however still carried all the baggage of its attempts to abstract from HTTP. This soon led to the creation of REST, which is a simpler and fully HTTP native style. While REST is often said to follow-up SOAP, they are somewhat different things. REST is actually a “style” with SOAP being a “protocol”.

Java EE provides first-class support for REST via the JAX-RS API. This time the nomenclature stayed largely the same though; we still talk about a web service, although sometimes the term RESTful web service is used to distinguish it from a SOAP-based web service. With that, we finally arrive at Microservices.

Microservices are an architectural type that builds on (mostly) RESTful web services. Where RESTful web services, in general, can be used for just about anything, for instance, to expose an API to external users, Microservices are specifically dedicated to be independent business services that together form a suite of such services that make up an application. Microservices are typically associated with clouds. Not so much out of sheer necessity perhaps, but because cloud hosting was, and still is, the dominant type of deployment target when Microservices came about. Java EE itself has no explicit support for Microservices or clouds. The cloud topic was briefly touched upon for Java EE 7 but then abandoned. Java EE 8 didn’t really address it either, although the EE Security API introduced in EE 8 was created with cloud deployments in mind. A separate effort called MicroProfile was started though, and this does provide direct support for the Microservices architectural type. It builds directly on Java EE and is in fact worked on by all active Java EE vendors.

The APIs offered by MicroProfile could have been in Java EE proper, but due to Java EE being transferred and rebranded as Jakarta EE it currently isn’t. This does mean that the level of support and inclusion differs somewhat between the various vendors. Some vendors have separate products for Java EE and MicroProfile or only incorporate a few MicroProfile APIs with their main Java EE product. Other vendors do allow a free mix and match but require a separate configuration and/or install step for that. There’s also a difference between whether the MicroProfile APIs are included in commercial support or not; for some vendors, this is the case, for others, it’s not.

Payara Platform is arguably the simplest solution here. Both Jakarta EE (Java EE) and all MicroProfile APIs are included in Payara Server, which is available as an open source product with both Community and fully supported Enterprise versions available.

Additionally, there’s Payara Micro which due to its small size and easy deployment model is even more suited for Microservices. Payara Micro contains almost all Jakarta EE (Java EE) APIs and all MicroProfile APIs, and is also available as open source with a Community and fully supported Enterprise version.

With Payara Server supporting both Java EE and all MicroProfile APIs, it’s very much possible to migrate existing Java EE production applications piece by piece to take advantage of the MicroProfile APIs and the Microservices style, and then rather effortlessly run this same application on Payara Micro.

Learn more with our Getting Started guide: