New Java Enterprise Perspectives with Polyglot JVM
In this article I want to share my thoughts on the architecture of server platforms for enterprise Java applications using Java EE, Spring, Akka.
Why the desire to write? At JavaOne 2012, a lot was told about trends and changes in the Java and JVM world - Polyglot JVM, lambdas, modularity. At the conference, there was a feeling that all the achievements of Java EE should not depend on the programming language. Now they often ask the question - which language will replace Java? But then what to do with all existing technologies for developing enterprise applications? These technologies are uniquely valuable. Is it possible to replace a programming language at the same time and at the same time preserve existing developments and investments? Apparently yes.
Now I’ll try in more detail about the impact of the Polyglot JVM trend.
Introduction The Polyglot JVM achieves two goals: it paves the way for innovation and allows you to preserve all Java technologies in the enterprise application sector. But the path to these conclusions will be long ;-)
This article is for developers of enterprise applications. I hope it helps to systematize knowledge of the architecture of server platforms based on Java and, perhaps, inspires to expand the range of languages used.
At the origins of server platform architectures for enterprise applications are Object Management Architecture (OMA) and CORBA, developed by OMG.
The Object Management Architecture (OMA, http://www.omg.org/oma ) was developed for distributed object systems in which a client makes an RPC remote call to an object method.
More information about the types of resources for accessing via RPC can be found here https://www2.opengroup.org/ogsys/catalog/c706 (section 2.1.1.5). Depending on how to interpret the remote resource, the following resource models are allocated: server, service, object. If you carefully look at these types of resources, then for each type its own type of application architecture "begs": respectively, client-server, service-oriented, distributed object architecture.
So, OMA was created for the third type of resources - for objects. Now other types of resources are more actively used - a service (for example, SOAP), a server (for example, SQL, HTTP).
But changing the type of the resource from the object to the server / service did not prevent the transfer of many ideas from OMA, in particular, to the Java EE architecture.
OMA Architecture
An important part of OMA is the Object Request Broker (ORB). ORB is wider than just an object-oriented RPC. Functionally, it is partly an analog of the application server.
CORBA (Common Object Request Request Broker Architecture and Specification) specifies how ORB should be implemented.
The ORB architecture is based on two important ideas :
The ORB essentially introduces the concept of a container for business logic objects (this is called an object adapter): the business logic objects on the server are created and destroyed by the container. The figure below shows the ORB structure and the object adapter is highlighted in red.
ORB structure, object adapter is highlighted with a red border. The
motivation for this was to ensure that the server is running under high load. So, 1) the client is not allowed to create “server-side” server objects — it suddenly forgets to destroy it, 2) the server can apply scalability mechanisms to objects (unload an object if it has not been accessed for a long time, load it if necessary). All the client’s authority in this work scheme is to request from the server a link to the server object with business logic and remotely call the object method.
In addition to the container of business logic objects in OMA, there is the concept of Object Services as an integral part of the server platform - see the figure below. Among the services: distributed transaction service, security service, event service and others (for a complete list of services, see http://www.omg.org/spec/#CS ).
CORBA Object Services
A server object implementation can access services through the above object adapter.
Thus, CORBA contains ideas that are actively used in modern server platforms in Java: the use of containers and services, as shown in the following figure.
Composition of the server platform: containers and services
CORBA also incorporated many other ideas that are currently in heavy use. So, it was CORBA that introduced the concept of “interceptor” ( CORBA specification, version 2.3 , chapter 21). The CORBA interceptor is a hook that can be used to invoke services when creating a server object or when invoking a server object. Interceptors are now heavily used in IoC containers in Spring and in Java EE.
Modern server platform architectures (in particular, Java EE, Spring) have undergone a certain evolution after CORBA.
The following frameworks were added to their composition:
CORBA is focused on the use of the client communication protocol with the GIOP / IIOP server. Currently, the HTTP, SOAP, and REST protocols (over HTTP) are used to communicate between the client and the server.
To ensure working with the HTTP protocol, a servlet container is included in the server platform. The servlet container took upon itself only the work with the HTTP protocol and, in fact, did not present any programming model for writing business logic. Code written for the servlet container abounds with HTTP protocol dependencies.
In this regard, web frameworks have appeared that perform tasks:
Now about the IoC container (Inversion of Control). An IoC container solves the following problem: it allows you to transfer the lifecycle management of any object on the server to the container, but the business logic code will not depend on the container itself.
An important place in the platform was taken by the ORM framework for persistent objects. Why am I focusing on this obvious fact? Practice has shown that this framework should not have the functions of a container (that is, manage the life cycle of stored objects). This error - Container Managed EJB Entity Beans - was made in EJB 2.0. Practice has shown that such a solution did not take root.
Here's how it can be represented.
Typical Java-based server platform architecture
The CORBA section highlights two important design features that are heavily used in the Java EE platform — server object containers and services as part of the server platform.
The main containers in Java EE are a servlet container, an EJB container, and an IoC container, and among the main services: JTS transaction service, security service, JDBC, JNDI naming service, JMS messaging service, HTTP service, JMX management.
Java EE Platform Structure
Essentially, Java EE is a descendant of CORBA. If in doubt, make an application that supports Remote EJB, make a mistake when executing EJB and look at the stack - you will see the words CORBA, poa (portable object adapter) and marshalling.
Spring is a representative of the same architecture as Java EE (CORBA): containers, services and frameworks are actively used.
Spring Platform Structure
However, there are differences:
I absolutely do not want to breed “holy war” on the topic of Java EE vs Spring.
Undoubtedly, Spring provides the programmer with a more innovative programming model.
At the Java EE and Spring Framework Panel Discussion session at JavaOne 2012, the following points of view were proposed: Spring is innovation, Java EE is standardization. Technology innovations must prove their right to life, and then can be standardized. The unsuccessful EJB 2.0 Entity Bean solution still spoils the opinion of EJB technology, the reason for this failure was the hasty standardization of the technology.
Photo from JavaOne 2012, Java EE and Spring Framework Panel Discussion
The ideas, patterns, and practices that make up the Enterprise Edition described are essentially Java independent. Of course, they work on the Java platform, but have a separate value from Java.
Is it possible to preserve this value while changing the programming language? At first it would be logical to consider - why change the language?
Summarizing the architectures from the previous section, I want to offer the following figure, in which the components of business logic are added.
Analyzing this figure, the following question arises: should the components of business logic be dependent on the language in which the server platform is implemented .
If such independence is possible, this will save all the achievements, the entire stack of server platform technologies, as well as bring innovation and all the advantages of other languages, for example, functional or languages with dynamic typing. The advantages of other languages include conciseness, closures, operator overloading, intuitive syntax for working with collections, and a functional programming paradigm. Dynamic languages also pave the way for using DSL with Java EE.
At the same time, the question arises that the server platform should be open to innovation . Perhaps some of these innovations will be conveniently done in another programming language due to the nature of the tasks they solve.
With a question, why another programming language may be needed, figured out.
Now to the question - how to achieve this?
The independence of server objects from the language of the implementation of the server platform was proposed back in CORBA. This was achieved by standardizing the platform and using IDL (interface definition language) when writing server objects. However, the rigorous standardization of the server platform blocks the path to innovation. As a result, CORBA is not very common in building enterprise systems.
In order to find a solution, it is necessary to go beyond the previous figure and look for the foundation on which the server platform itself is built. This foundation is the JVM, see the figure below.
If the server platform and business logic are written in different languages that run on the same JVM, this will achieve the goals:
That is why the direction of Polyglot JVM is actively developing .
The following examples confirm the conclusions made:
So, the use of Polyglot JVM achieves two goals: it paves the way for innovation and allows you to save all the best practices in the enterprise application sector.
The JVM has always been separate from Java and has run its own set of instructions - bytecode. A program written in another language and compiled into bytecode could be executed on the JVM.
However, before JDK 6 and JDK 7, this was only possible for languages with static typing.
Scala, a language with static typing that appeared in 2003, was compiled without problems into bytecode based on the set of instructions for the JVM that existed at that time.
The first step to support dynamic typing languages was made in JDK 6 - the Java Scripting API library (javax.script. *) Was added. However, this solution was only partial. In order for the script code to work, a scripting engine for this language was needed. This solution did not differ in performance, since in essence a “double” interpretation was performed - first, the interpretation of the script code using the engine, and then the interpretation of the engine code by the virtual machine.
The JVM became a true "polyglot" in JDK 7 thanks to the advent of a new instruction for the JVM invokedynamic , specially designed for dynamic languages. Thanks to this instruction, the performance of script code execution has been significantly improved.
Currently, the following languages can work on top of the JVM: Java, Scala, JRuby, Groovy, Clojure, Jython, and others.
For more information, I recommend a presentation on languages for the JVM.
Other server platforms are also being developed, for example, based on event driven architecture (EDA), in particular, Akka ( http://www.oraclejavamagazine-digital.com/javamagazine/20121112?pg=56#pg56 ).
For platforms based on EDA, the ideology of containers and services is also applicable. However, the list of services for them should be reviewed and different from the list of CORBA / Java EE / Spring services. This is beautifully demonstrated by the example of a distributed transaction service. Using events instead of remote calls (RPCs) allows for poor connectivity. However, with this approach, it becomes unclear where to set the boundaries of the transaction. Setting transaction boundaries leads to strong cohesion ( http://natishalom.typepad.com/nati_shaloms_blog/2007/08/lessons-from-am.html ).
Thus, the same picture for EDA - developments in the field of EDA have their own value, and are independent of the programming language.
Traditionally, Akka is paired with Scala or Java. However, there are precedents for using other languages, for example Akka + Groovy ( http://littlesquare.com/2012/02/playing-with-akka-groovy-rest-maven/ ).
Using the Polyglot JVM for EDA also allows you to save groundwork in technology and platforms while taking advantage of other languages.
Java technologies for enterprise applications are undeniably valuable. Thanks to the Polyglot JVM, you can save all of these technologies, and at the same time you can use new languages in your enterprise.
So, Polyglot JVM opens the way to innovation and allows you to save all the achievements in the enterprise application sector:
Wow That seems to be all ;-)
Why the desire to write? At JavaOne 2012, a lot was told about trends and changes in the Java and JVM world - Polyglot JVM, lambdas, modularity. At the conference, there was a feeling that all the achievements of Java EE should not depend on the programming language. Now they often ask the question - which language will replace Java? But then what to do with all existing technologies for developing enterprise applications? These technologies are uniquely valuable. Is it possible to replace a programming language at the same time and at the same time preserve existing developments and investments? Apparently yes.
Now I’ll try in more detail about the impact of the Polyglot JVM trend.
Introduction The Polyglot JVM achieves two goals: it paves the way for innovation and allows you to preserve all Java technologies in the enterprise application sector. But the path to these conclusions will be long ;-)
This article is for developers of enterprise applications. I hope it helps to systematize knowledge of the architecture of server platforms based on Java and, perhaps, inspires to expand the range of languages used.
1. Object Management Architecture, CORBA
At the origins of server platform architectures for enterprise applications are Object Management Architecture (OMA) and CORBA, developed by OMG.
| It's funny that now the developers are older, the abbreviation OMG is the Object Management Group, the younger generation - Oh My God! |
The Object Management Architecture (OMA, http://www.omg.org/oma ) was developed for distributed object systems in which a client makes an RPC remote call to an object method.
More information about the types of resources for accessing via RPC can be found here https://www2.opengroup.org/ogsys/catalog/c706 (section 2.1.1.5). Depending on how to interpret the remote resource, the following resource models are allocated: server, service, object. If you carefully look at these types of resources, then for each type its own type of application architecture "begs": respectively, client-server, service-oriented, distributed object architecture.
So, OMA was created for the third type of resources - for objects. Now other types of resources are more actively used - a service (for example, SOAP), a server (for example, SQL, HTTP).
But changing the type of the resource from the object to the server / service did not prevent the transfer of many ideas from OMA, in particular, to the Java EE architecture.
OMA Architecture
An important part of OMA is the Object Request Broker (ORB). ORB is wider than just an object-oriented RPC. Functionally, it is partly an analog of the application server.
CORBA (Common Object Request Request Broker Architecture and Specification) specifies how ORB should be implemented.
The ORB architecture is based on two important ideas :
- client architecture should be simple;
- all scalability mechanisms that allow the server to withstand high loads are located on the server, as a result of which the server architecture is more complex.
The ORB essentially introduces the concept of a container for business logic objects (this is called an object adapter): the business logic objects on the server are created and destroyed by the container. The figure below shows the ORB structure and the object adapter is highlighted in red.
ORB structure, object adapter is highlighted with a red border. The
motivation for this was to ensure that the server is running under high load. So, 1) the client is not allowed to create “server-side” server objects — it suddenly forgets to destroy it, 2) the server can apply scalability mechanisms to objects (unload an object if it has not been accessed for a long time, load it if necessary). All the client’s authority in this work scheme is to request from the server a link to the server object with business logic and remotely call the object method.
In addition to the container of business logic objects in OMA, there is the concept of Object Services as an integral part of the server platform - see the figure below. Among the services: distributed transaction service, security service, event service and others (for a complete list of services, see http://www.omg.org/spec/#CS ).
CORBA Object Services
A server object implementation can access services through the above object adapter.
Thus, CORBA contains ideas that are actively used in modern server platforms in Java: the use of containers and services, as shown in the following figure.
Composition of the server platform: containers and services
CORBA also incorporated many other ideas that are currently in heavy use. So, it was CORBA that introduced the concept of “interceptor” ( CORBA specification, version 2.3 , chapter 21). The CORBA interceptor is a hook that can be used to invoke services when creating a server object or when invoking a server object. Interceptors are now heavily used in IoC containers in Spring and in Java EE.
2. Java EE / Spring Platform Architectures
Modern server platform architectures (in particular, Java EE, Spring) have undergone a certain evolution after CORBA.
The following frameworks were added to their composition:
- web framework;
- IoC container;
- ORM framework.
CORBA is focused on the use of the client communication protocol with the GIOP / IIOP server. Currently, the HTTP, SOAP, and REST protocols (over HTTP) are used to communicate between the client and the server.
To ensure working with the HTTP protocol, a servlet container is included in the server platform. The servlet container took upon itself only the work with the HTTP protocol and, in fact, did not present any programming model for writing business logic. Code written for the servlet container abounds with HTTP protocol dependencies.
In this regard, web frameworks have appeared that perform tasks:
- remove the dependence of code with business logic on the communication protocol;
- Introduce architectural patterns for application modules (e.g. MVC) that accelerate the development of web-based applications
- manage the life cycle of objects in the scope of web applications.
Now about the IoC container (Inversion of Control). An IoC container solves the following problem: it allows you to transfer the lifecycle management of any object on the server to the container, but the business logic code will not depend on the container itself.
An important place in the platform was taken by the ORM framework for persistent objects. Why am I focusing on this obvious fact? Practice has shown that this framework should not have the functions of a container (that is, manage the life cycle of stored objects). This error - Container Managed EJB Entity Beans - was made in EJB 2.0. Practice has shown that such a solution did not take root.
Here's how it can be represented.
Typical Java-based server platform architecture
2.1. Java EE
The CORBA section highlights two important design features that are heavily used in the Java EE platform — server object containers and services as part of the server platform.
The main containers in Java EE are a servlet container, an EJB container, and an IoC container, and among the main services: JTS transaction service, security service, JDBC, JNDI naming service, JMS messaging service, HTTP service, JMX management.
Java EE Platform Structure
Essentially, Java EE is a descendant of CORBA. If in doubt, make an application that supports Remote EJB, make a mistake when executing EJB and look at the stack - you will see the words CORBA, poa (portable object adapter) and marshalling.
2.2. Spring
Spring is a representative of the same architecture as Java EE (CORBA): containers, services and frameworks are actively used.
Spring Platform Structure
However, there are differences:
- Spring can be deployed separately or based on a web server that provides a servlet container and basic services;
- Spring provides an API for working with the necessary enterprise services, which can be delivered as they are used.
2.3. Spring vs Java EE
I absolutely do not want to breed “holy war” on the topic of Java EE vs Spring.
Undoubtedly, Spring provides the programmer with a more innovative programming model.
At the Java EE and Spring Framework Panel Discussion session at JavaOne 2012, the following points of view were proposed: Spring is innovation, Java EE is standardization. Technology innovations must prove their right to life, and then can be standardized. The unsuccessful EJB 2.0 Entity Bean solution still spoils the opinion of EJB technology, the reason for this failure was the hasty standardization of the technology.
Photo from JavaOne 2012, Java EE and Spring Framework Panel Discussion
3. Java Enterprise without Java?
The ideas, patterns, and practices that make up the Enterprise Edition described are essentially Java independent. Of course, they work on the Java platform, but have a separate value from Java.
Is it possible to preserve this value while changing the programming language? At first it would be logical to consider - why change the language?
Summarizing the architectures from the previous section, I want to offer the following figure, in which the components of business logic are added.
Analyzing this figure, the following question arises: should the components of business logic be dependent on the language in which the server platform is implemented .
If such independence is possible, this will save all the achievements, the entire stack of server platform technologies, as well as bring innovation and all the advantages of other languages, for example, functional or languages with dynamic typing. The advantages of other languages include conciseness, closures, operator overloading, intuitive syntax for working with collections, and a functional programming paradigm. Dynamic languages also pave the way for using DSL with Java EE.
At the same time, the question arises that the server platform should be open to innovation . Perhaps some of these innovations will be conveniently done in another programming language due to the nature of the tasks they solve.
With a question, why another programming language may be needed, figured out.
Now to the question - how to achieve this?
The independence of server objects from the language of the implementation of the server platform was proposed back in CORBA. This was achieved by standardizing the platform and using IDL (interface definition language) when writing server objects. However, the rigorous standardization of the server platform blocks the path to innovation. As a result, CORBA is not very common in building enterprise systems.
In order to find a solution, it is necessary to go beyond the previous figure and look for the foundation on which the server platform itself is built. This foundation is the JVM, see the figure below.
If the server platform and business logic are written in different languages that run on the same JVM, this will achieve the goals:
- saves all existing developments of server platforms;
- allows you to ensure the openness of the server platform for innovation;
- allows you to develop business logic and server platform in different languages.
That is why the direction of Polyglot JVM is actively developing .
The following examples confirm the conclusions made:
- Grails platform (based on Groovy);
- Django with Jython;
- JSF + Groovy ;
- Spring + Groovy ( http://www.ibm.com/developerworks/java/library/j-groovierspring1/index.html , http://habrahabr.ru/post/145158/ ).
So, the use of Polyglot JVM achieves two goals: it paves the way for innovation and allows you to save all the best practices in the enterprise application sector.
4. Polyglot JVM
The JVM has always been separate from Java and has run its own set of instructions - bytecode. A program written in another language and compiled into bytecode could be executed on the JVM.
However, before JDK 6 and JDK 7, this was only possible for languages with static typing.
Scala, a language with static typing that appeared in 2003, was compiled without problems into bytecode based on the set of instructions for the JVM that existed at that time.
The first step to support dynamic typing languages was made in JDK 6 - the Java Scripting API library (javax.script. *) Was added. However, this solution was only partial. In order for the script code to work, a scripting engine for this language was needed. This solution did not differ in performance, since in essence a “double” interpretation was performed - first, the interpretation of the script code using the engine, and then the interpretation of the engine code by the virtual machine.
The JVM became a true "polyglot" in JDK 7 thanks to the advent of a new instruction for the JVM invokedynamic , specially designed for dynamic languages. Thanks to this instruction, the performance of script code execution has been significantly improved.
Currently, the following languages can work on top of the JVM: Java, Scala, JRuby, Groovy, Clojure, Jython, and others.
For more information, I recommend a presentation on languages for the JVM.
5. Alternative architectures and Polyglot JVM
Other server platforms are also being developed, for example, based on event driven architecture (EDA), in particular, Akka ( http://www.oraclejavamagazine-digital.com/javamagazine/20121112?pg=56#pg56 ).
For platforms based on EDA, the ideology of containers and services is also applicable. However, the list of services for them should be reviewed and different from the list of CORBA / Java EE / Spring services. This is beautifully demonstrated by the example of a distributed transaction service. Using events instead of remote calls (RPCs) allows for poor connectivity. However, with this approach, it becomes unclear where to set the boundaries of the transaction. Setting transaction boundaries leads to strong cohesion ( http://natishalom.typepad.com/nati_shaloms_blog/2007/08/lessons-from-am.html ).
Thus, the same picture for EDA - developments in the field of EDA have their own value, and are independent of the programming language.
Traditionally, Akka is paired with Scala or Java. However, there are precedents for using other languages, for example Akka + Groovy ( http://littlesquare.com/2012/02/playing-with-akka-groovy-rest-maven/ ).
Using the Polyglot JVM for EDA also allows you to save groundwork in technology and platforms while taking advantage of other languages.
6. Conclusions
Java technologies for enterprise applications are undeniably valuable. Thanks to the Polyglot JVM, you can save all of these technologies, and at the same time you can use new languages in your enterprise.
So, Polyglot JVM opens the way to innovation and allows you to save all the achievements in the enterprise application sector:
- save all existing developments of server platforms for Java;
- ensure openness of the server platform for innovation;
- to develop business logic in a language other than the server platform implementation language, and to bring into the development of business logic all the advantages of functional languages and languages with dynamic typification;
- take care of the financial side of the issue: use those languages that the team knows and do not waste time and money on retraining.
Wow That seems to be all ;-)