New perspectives on Java Enterprise with the Polyglot JVM
In this article I want to share thoughts about the architecture of server platforms for enterprise applications in Java using Java EE, Spring, Akka.
Why did you want to write? At JavaOne 2012, a lot was discussed about trends and changes in the world of Java and JVM - Polyglot JVM, lambda, modularity. At the conference, there was a feeling that all the Java EE developments should not depend on the programming language. Now often ask the question - which language will replace Java? But then what to do with all existing technologies for developing corporate applications? These technologies clearly have value. Is it possible at the same time to replace a programming language and at the same time preserve existing developments and investments made? Apparently yes.
Now I will try to learn more about the impact of the trend of Polyglot JVM.
Introduction Polyglot JVM achieves two goals: it opens the way to innovation and allows you to keep all Java technologies in the enterprise application sector. But the path to these conclusions will be long ;-)
This article is for enterprise application developers. I hope it will help to systematize knowledge of the architecture of server platforms based on Java and, perhaps, will inspire to expand the range of languages ​​used.
The origins of enterprise application server platform architectures are the Object Management Architecture (OMA) and CORBA, developed by the OMG team.
The Object Management Architecture (OMA, http://www.omg.org/oma ) was designed for object-based distributed systems in which a client makes a remote method call of an object using RPC.
You can read more about the types of resources for contacting RPC here https://www2.opengroup.org/ogsys/catalog/c706 (section 2.1.1.5). Depending on how to treat a remote resource, the following resource models are distinguished: server, service, object. If you look closely at these types of resources, then for each type, a different type of application architecture arises: customer-server, service-oriented, and distributed object architecture, respectively.
So, OMA was created for the third type of resources - for objects. Now other types of resources are more actively used - service (for example, SOAP), server (for example, SQL, HTTP).
But changing the type of resource from an object to a server / service did not prevent transferring 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 object-oriented RPC. Functionally, this is partially an analogue of an application server.
CORBA (Common Object Request Broker Architecture and Specification) specifies how the ORB should be implemented.
The ORB architecture is based on two important ideas :
It is in ORB that the concept of a container for business logic objects is introduced (this is called an object adapter): business logic objects on the server create and destroy a container. The figure below shows the ORB structure and the object adapter is highlighted with a red border.
ORB structure, object adapter is highlighted with red border
The motivation for this was to ensure server operation under high load. So, 1) the client is not allowed to create server objects “manually” - he suddenly forgets to destroy, 2) the server can apply scalability mechanisms to objects (unload an object, if it hasn’t been accessed for a long time, load it if needed). All client authority in this workflow is to request the server for 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 services (Object Services) as an integral part of the server platform - see figure below. Services include distributed transaction services, security services, event services, and others (for a complete list of services, see http://www.omg.org/spec/#CS ).
CORBA Object Services
The server object implementation can access services through the object adapter mentioned above.
Thus, CORBA has ideas that are widely used in modern server platforms in Java: the use of containers and services, as shown in the following figure.
The composition of the server platform: containers and services
In CORBA, there were also many other ideas that are being used extensively at the moment. So, it was in CORBA that the concept of “interseptor” was introduced ( CORBA specification, version 2.3 , chapter 21). The CORBA interceptor is a “hook” with which services can be called during the creation of a server object or when a server object is called. Now interceptors are actively used in IoC containers in Spring and in Java EE.
Modern architecture of server platforms (in particular, Java EE, Spring) have undergone a certain evolution after CORBA.
In their composition were added frameworks:
CORBA is focused on using the client communication protocol with the GIOP / IIOP server. Currently, the HTTP, SOAP and REST protocols (over HTTP) are used to communicate the client with the server.
To support the HTTP protocol, the servlet container is included in the server platform. The servlet container only took over the work with the HTTP protocol and, in fact, did not provide any programming model for writing business logic. Code written for a servlet container is replete with dependencies on the HTTP protocol.
In this regard, web frameworks that perform tasks appeared:
Now about the IoC-container (Inversion of Control). The IoC container solves the following task: it allows you to transfer the lifecycle management of any object on the server to the container, but the code of the business logic will not depend on the container itself.
An important place in the platform was taken by the ORM framework for the saved objects. Why do I focus on this obvious fact? Practice has shown that a given framework should not have container functions (that is, control the life cycle of stored objects). This error — Container Managed EJB Entity Beans — was made in EJB 2.0. Practice has shown that this decision did not stick.
Here's how to portray it.
Typical Java Server Platform Architecture
The CORBA section highlights two important design elements that are used extensively in the Java EE platform — server object containers and services as part of the server platform.
The main containers in Java EE are servlet container, EJB container and IoC container, and the main services include the JTS transaction service, security service, JDBC, JNDI naming service, JMS messaging service, HTTP service, JMX.
Java EE Platform Structure
In essence, Java EE is a CORBA heir. If anyone doubts, make an application with Remote EJB support, make a mistake when executing an 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 used extensively.
Spring platform structure
However, there are differences:
I absolutely do not want to breed “holy war” on the subject of Java EE vs Spring.
Undoubtedly, Spring provides the programmer with a more innovative software model.
At the Java EE session and the Spring Framework Panel, the following point of view was proposed at JavaOne 2012: Spring is innovation, Java EE is standardization. Innovations in technology must prove their right to life, and then they can be standardized. The unsuccessful decision of EJB 2.0 Entity Bean still spoils the view of EJB technology, the reason for this failure was the hasty technology standardization.
Photos from JavaOne 2012, Java EE and Spring Framework Panel Discussion
The described ideas, patterns, practices that make up the “Enterprise Edition” are essentially independent of Java. 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 architecture from the previous section, I want to offer the following figure, to which the components of business logic are added.
Analyzing this figure, the following question arises: should the components of the business logic be dependent on the language in which the server platform is implemented ?
If such independence is possible, it will preserve all the achievements, the whole stack of server platform technologies, as well as bring innovations and all the advantages of other languages, for example, functional or languages ​​with dynamic typing. The advantages of other languages ​​are conciseness, closures, operator overloading, an intuitive syntax for working with collections, a functional programming paradigm. Dynamic languages ​​also open the door to 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 the question, why might need another programming language, 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 in CORBA. This was achieved by standardizing the platform and using IDL (interface definition language) when writing server objects. However, strict standardization of the server platform closes the path to innovation. As a result, CORBA is a little common when building corporate systems.
In order to find a solution, it is necessary to go beyond the previous figure and search for the foundation on which the server platform is built. This foundation is the JVM, see picture below.
If the server platform and business logic are written in different languages ​​that run on the same JVM, then this will achieve the goals:
That is why the direction of Polyglot JVM is actively developing.
The following examples confirm the findings:
So, using Polyglot JVM achieves two goals: it opens the way to innovations and allows you to save all the achievements in the enterprise application sector.
The JVM has always been separated from Java and executed 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 static-typed language that appeared in 2003 — compiled without problems into bytecode based on the JVM instruction set existing at that time.
The first step to support dynamic-typed languages ​​was made in JDK 6 — the Java Scripting API library (javax.script. *) Was added. However, this decision was 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 the “double” interpretation was performed - first interpretation of the script code using the engine, and then interpretation of the engine code by the virtual machine.
JDK 7 has become a real “polyglot” in JDK 7 due to the appearance of the new instruction for the JVM invokedynamic , specifically designed for dynamic languages. Thanks to this instruction, the performance of the script code is significantly improved.
Currently, the following languages ​​can be used on JVM: Java, Scala, JRuby, Groovy, Clojure, Jython, and others.
For more information, I recommend a presentation on languages ​​for JVM.
Other server platforms are currently 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 revised 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 (RPC) allows for weak connectivity. However, with this approach, it becomes unclear where to set the boundaries of the transaction. Setting a transaction boundary leads to strong connectivity ( http://natishalom.typepad.com/nati_shaloms_blog/2007/08/lessons-from-am.html ).
Thus, for EDA, the same picture - developments in the field of EDA have their own value, and do not depend on the programming language.
Traditionally, Akka is considered paired with Scala or Java. However, there are precedents for the use of other languages, such as Akka + Groovy ( http://littlesquare.com/2012/02/playing-with-akka-groovy-rest-maven/ ).
Using Polyglot JVM for EDA also allows you to save work in technologies and platforms while still taking advantage of other languages.
Java technology for enterprise applications is undeniably valuable. Thanks to Polyglot JVM, you can save all these technologies and at the same time the possibility of using new languages ​​in an enterprise opens up.
So, Polyglot JVM opens the way to innovations and allows you to save all the achievements in the sector of corporate applications:
Wow It seems that this is all ;-)
Why did you want to write? At JavaOne 2012, a lot was discussed about trends and changes in the world of Java and JVM - Polyglot JVM, lambda, modularity. At the conference, there was a feeling that all the Java EE developments should not depend on the programming language. Now often ask the question - which language will replace Java? But then what to do with all existing technologies for developing corporate applications? These technologies clearly have value. Is it possible at the same time to replace a programming language and at the same time preserve existing developments and investments made? Apparently yes.
Now I will try to learn more about the impact of the trend of Polyglot JVM.
Introduction Polyglot JVM achieves two goals: it opens the way to innovation and allows you to keep all Java technologies in the enterprise application sector. But the path to these conclusions will be long ;-)
This article is for enterprise application developers. I hope it will help to systematize knowledge of the architecture of server platforms based on Java and, perhaps, will inspire to expand the range of languages ​​used.
1. Object Management Architecture, CORBA
The origins of enterprise application server platform architectures are the Object Management Architecture (OMA) and CORBA, developed by the OMG team.
| It's funny that now older developers have an abbreviation OMG - this is the Object Management Group, the younger generation - Oh My God! |
The Object Management Architecture (OMA, http://www.omg.org/oma ) was designed for object-based distributed systems in which a client makes a remote method call of an object using RPC.
You can read more about the types of resources for contacting RPC here https://www2.opengroup.org/ogsys/catalog/c706 (section 2.1.1.5). Depending on how to treat a remote resource, the following resource models are distinguished: server, service, object. If you look closely at these types of resources, then for each type, a different type of application architecture arises: customer-server, service-oriented, and distributed object architecture, respectively.
So, OMA was created for the third type of resources - for objects. Now other types of resources are more actively used - service (for example, SOAP), server (for example, SQL, HTTP).
But changing the type of resource from an object to a server / service did not prevent transferring 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 object-oriented RPC. Functionally, this is partially an analogue of an application server.
CORBA (Common Object Request Broker Architecture and Specification) specifies how the ORB should be implemented.
The ORB architecture is based on two important ideas :
- client architecture should be simple;
- all the 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 complicated.
It is in ORB that the concept of a container for business logic objects is introduced (this is called an object adapter): business logic objects on the server create and destroy a container. The figure below shows the ORB structure and the object adapter is highlighted with a red border.
ORB structure, object adapter is highlighted with red border
The motivation for this was to ensure server operation under high load. So, 1) the client is not allowed to create server objects “manually” - he suddenly forgets to destroy, 2) the server can apply scalability mechanisms to objects (unload an object, if it hasn’t been accessed for a long time, load it if needed). All client authority in this workflow is to request the server for 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 services (Object Services) as an integral part of the server platform - see figure below. Services include distributed transaction services, security services, event services, and others (for a complete list of services, see http://www.omg.org/spec/#CS ).
CORBA Object Services
The server object implementation can access services through the object adapter mentioned above.
Thus, CORBA has ideas that are widely used in modern server platforms in Java: the use of containers and services, as shown in the following figure.
The composition of the server platform: containers and services
In CORBA, there were also many other ideas that are being used extensively at the moment. So, it was in CORBA that the concept of “interseptor” was introduced ( CORBA specification, version 2.3 , chapter 21). The CORBA interceptor is a “hook” with which services can be called during the creation of a server object or when a server object is called. Now interceptors are actively used in IoC containers in Spring and in Java EE.
2. Java EE / Spring Platform Architectures
Modern architecture of server platforms (in particular, Java EE, Spring) have undergone a certain evolution after CORBA.
In their composition were added frameworks:
- web framework;
- IoC container;
- ORM framework.
CORBA is focused on using the client communication protocol with the GIOP / IIOP server. Currently, the HTTP, SOAP and REST protocols (over HTTP) are used to communicate the client with the server.
To support the HTTP protocol, the servlet container is included in the server platform. The servlet container only took over the work with the HTTP protocol and, in fact, did not provide any programming model for writing business logic. Code written for a servlet container is replete with dependencies on the HTTP protocol.
In this regard, web frameworks that perform tasks appeared:
- remove the dependence of the code with business logic on the communication protocol;
- introduce architectural patterns for application modules (for example, MVC) that accelerate the development of web-based applications;
- Manage the lifecycle of objects in the scopes that occur for web applications.
Now about the IoC-container (Inversion of Control). The IoC container solves the following task: it allows you to transfer the lifecycle management of any object on the server to the container, but the code of the business logic will not depend on the container itself.
An important place in the platform was taken by the ORM framework for the saved objects. Why do I focus on this obvious fact? Practice has shown that a given framework should not have container functions (that is, control the life cycle of stored objects). This error — Container Managed EJB Entity Beans — was made in EJB 2.0. Practice has shown that this decision did not stick.
Here's how to portray it.
Typical Java Server Platform Architecture
2.1. Java ee
The CORBA section highlights two important design elements that are used extensively in the Java EE platform — server object containers and services as part of the server platform.
The main containers in Java EE are servlet container, EJB container and IoC container, and the main services include the JTS transaction service, security service, JDBC, JNDI naming service, JMS messaging service, HTTP service, JMX.
Java EE Platform Structure
In essence, Java EE is a CORBA heir. If anyone doubts, make an application with Remote EJB support, make a mistake when executing an 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 used extensively.
Spring platform structure
However, there are differences:
- Spring can be deployed separately or based on a web server that provides servlet-container and basic services;
- Spring provides an API for working with the necessary enterprise-services that can be delivered as they are used.
2.3. Spring vs java ee
I absolutely do not want to breed “holy war” on the subject of Java EE vs Spring.
Undoubtedly, Spring provides the programmer with a more innovative software model.
At the Java EE session and the Spring Framework Panel, the following point of view was proposed at JavaOne 2012: Spring is innovation, Java EE is standardization. Innovations in technology must prove their right to life, and then they can be standardized. The unsuccessful decision of EJB 2.0 Entity Bean still spoils the view of EJB technology, the reason for this failure was the hasty technology standardization.
Photos from JavaOne 2012, Java EE and Spring Framework Panel Discussion
3. Java Enterprise without Java?
The described ideas, patterns, practices that make up the “Enterprise Edition” are essentially independent of Java. 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 architecture from the previous section, I want to offer the following figure, to which the components of business logic are added.
Analyzing this figure, the following question arises: should the components of the business logic be dependent on the language in which the server platform is implemented ?
If such independence is possible, it will preserve all the achievements, the whole stack of server platform technologies, as well as bring innovations and all the advantages of other languages, for example, functional or languages ​​with dynamic typing. The advantages of other languages ​​are conciseness, closures, operator overloading, an intuitive syntax for working with collections, a functional programming paradigm. Dynamic languages ​​also open the door to 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 the question, why might need another programming language, 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 in CORBA. This was achieved by standardizing the platform and using IDL (interface definition language) when writing server objects. However, strict standardization of the server platform closes the path to innovation. As a result, CORBA is a little common when building corporate systems.
In order to find a solution, it is necessary to go beyond the previous figure and search for the foundation on which the server platform is built. This foundation is the JVM, see picture below.
If the server platform and business logic are written in different languages ​​that run on the same JVM, then this will achieve the goals:
- saves all existing 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 findings:
- 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, using Polyglot JVM achieves two goals: it opens the way to innovations and allows you to save all the achievements in the enterprise application sector.
4. Polyglot JVM
The JVM has always been separated from Java and executed 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 static-typed language that appeared in 2003 — compiled without problems into bytecode based on the JVM instruction set existing at that time.
The first step to support dynamic-typed languages ​​was made in JDK 6 — the Java Scripting API library (javax.script. *) Was added. However, this decision was 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 the “double” interpretation was performed - first interpretation of the script code using the engine, and then interpretation of the engine code by the virtual machine.
JDK 7 has become a real “polyglot” in JDK 7 due to the appearance of the new instruction for the JVM invokedynamic , specifically designed for dynamic languages. Thanks to this instruction, the performance of the script code is significantly improved.
Currently, the following languages ​​can be used on JVM: Java, Scala, JRuby, Groovy, Clojure, Jython, and others.
For more information, I recommend a presentation on languages ​​for JVM.
5. Alternative Architectures and Polyglot JVM
Other server platforms are currently 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 revised 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 (RPC) allows for weak connectivity. However, with this approach, it becomes unclear where to set the boundaries of the transaction. Setting a transaction boundary leads to strong connectivity ( http://natishalom.typepad.com/nati_shaloms_blog/2007/08/lessons-from-am.html ).
Thus, for EDA, the same picture - developments in the field of EDA have their own value, and do not depend on the programming language.
Traditionally, Akka is considered paired with Scala or Java. However, there are precedents for the use of other languages, such as Akka + Groovy ( http://littlesquare.com/2012/02/playing-with-akka-groovy-rest-maven/ ).
Using Polyglot JVM for EDA also allows you to save work in technologies and platforms while still taking advantage of other languages.
6. Conclusions
Java technology for enterprise applications is undeniably valuable. Thanks to Polyglot JVM, you can save all these technologies and at the same time the possibility of using new languages ​​in an enterprise opens up.
So, Polyglot JVM opens the way to innovations and allows you to save all the achievements in the sector of corporate applications:
- save all existing server platform for Java;
- ensure the openness of the server platform for innovation;
- develop business logic in a language other than the server platform implementation language, and bring all the advantages of functional languages ​​and languages ​​with dynamic typing to the development of business logic;
- take care of the financial side of the issue: use those languages ​​that the team knows and don’t waste time and money on retraining.
Wow It seems that this is all ;-)
Source: https://habr.com/ru/post/169321/
All Articles