What are the new perspectives with JVM Polyglot Java Enterprise

Here are we going to talk about the architecture of the server platforms for Enterprise Java applications using Java EE, Spring, Akka.

Why are we willing to write?

At JavaOne 2012 was discussed a lot about the trends and changes in the world of Java and JVM-JVM Polyglot, lambdas, modularity.

At the Conference, there was a feeling that all the previous Java EE should not depend on the programming language.

Now frequently asked the question is:

• What language does Java replace?
• Where to put all existing enterprise application development technology?

These technologies are uniquely valuable.

• Is it possible to simultaneously replace programming language while maintaining existing achievements and investments?

Apparently Yes.

Now I will try to learn more about the impact of the trend Polyglot JVM.
The introduction of Polyglot JVM achieves two goals: opens the way for innovation and enables you to save all of the Java technology in corporate applications. But the path to these conclusions will be long;
This article is for developers of enterprise applications. Hopefully, it will help systematize knowledge architectures Java-based server platforms and perhaps inspire a wider range of languages.

The Object Management Architecture, CORBA

At the source server platform architectures for enterprise applications are Object Management Architecture (OMA) and CORBA, developed by the OMG.

The structure of the Object Management Architecture developed for distributed object systems, in which the client uses an RPC remote method called to the object.

Depending on how you interpret the remote resource, the following resource model: the Server service object. If you carefully look at these resource types, each type “begs” your type of application architecture:

• client/server,

• service-oriented,

• distributed object architecture.

So, OMA created for the third resource type for purposes. Now increasingly used other types of resources, a service (e.g. SOAP) Server (for example, SQL, HTTP).
But changing the type of the resource with the object on the Server/service did not prevent the transfer, many ideas of OMA, in particular, on the Java EE architecture.

An important part of the OMA is the broker object queries-Object Request Broker (ORB). ORB is wider than just object-based RPC. Functionally, this is partially equivalent to the application server.

CORBA (Common Object Request Broker Architecture and Specification) specifies how the ORB must implement.
Circle architecture based on two main ideas: the structure of the client should be simple;

It is in ORB virtually introduced the concept of a container for business logic objects (this is called an object adapter): business logic on the server creates and destroys the tank. The figure below shows an object adapter highlights the structure of the ORB and the red border.

The motivation for this was to ensure the server under high load. So,

• The client is not allowed to create manual server objects is suddenly forgotten ruin;

• The server can apply to objects of scalability mechanisms (unload object, if It has not accessed, downloaded if it’s needed).

All the powers in this scheme client work — ask the reference to the server object server with business logic and remotely call an object method.
In addition to the business logic objects container in OMA is the notion of services (Services) as part of the server platform. In the figure below. Among the services: the Microsoft distributed transaction service, security service, event service and other

Server object implementation can access the services through the object above adapter.
Thus, in CORBA laid ideas which used in modern Java Server platforms: the use of containers and services, as shown in the following figure.

CORBA has also brought many other ideas which are used extensively in the present moment. In CORBA introduced the concept of “interceptor” (CORBA specification, version 2.3, chapter 21). An interceptor in CORBA is a “hook” with which services may call during the creation of the server object or when calling a server object. Now interceptor is actively used in IoC containers in Spring and Java EE.

2. Java EE Platform Architecture/Spring

Modern architecture server platforms (in particular, Java EE, Spring) evolved after CORBA.
They added frameworks:

• Web framework;

• An IOC container;

• ORM framework.

CORBA is focusing on the use of client/server communication protocol GIOP/IIOP. Currently for client/server communication uses the HTTP, SOAP, and REST (over HTTP).To ensure the operation of the HTTP protocol in the server platform ingredients included servlet-container. Servlet container assumed only work with the HTTP protocol and, in fact, did not provide any programming model for writing business logic. The code is written for the servlet container, replete with dependencies on the HTTP protocol.

In this regard, there appeared a Web framework that performs tasks:
Remove the dependence of business logic code from the communication protocol;
Introduce architectural patterns for application modules (e.g., MVC), which accelerate the development of Web-oriented applications;
Manage the lifecycle of objects in scope, having a place for Web applications.

Now about the IoC container (Inversion of Control). An IOC container solves the following problem: lifecycle management allows you to pass any object on the server container, but the business logic code will not depend on the container.
An important place in the ORM framework tool for storing objects.

Why I pay attention to this obvious fact? The practice has shown that this context should not have the features of a container (that is, to manage the lifecycle of the stored objects). This error is a Container Managed Entity EJB Beans — was allowed in EJB 2.0. The practice has shown that such a decision would not stick.
Here’s how you can portray.

In the section on CORBA, highlighted two essential structural elements, which are used extensively in Java EE platform-containers Server objects and services as part of the Server platform.
Key containers are Java EE servlet container, EJB container and an IoC container, and among the first services: JTS transaction service, security service, JDBC, JNDI, NCS Service service JMS messages, HTTP service management with JMX.

In fact, Java EE is the heir of CORBA. If in doubt, make the Remote EJB-enabled application, make a mistake when performing an EJB and look at the stack will see words CORBA, pa (portable object adapter) and marshaling.

Spring

Spring is a representative of the same architecture and Java EE (CORBA): actively used containers, services, and frameworks.
However, there are differences:
Spring can be deployed separately or on a Web server that provides the servlet container and essential services;
Spring delivers in its composition the API for working with the necessary enterprise services that can be provided.

Spring vs. Java EE

Do not want to breed “holy war” on the topic of Java EE vs. Spring.
Undoubtedly, Spring provides the programmer with more innovative programming model.
Java EE at the session and Spring Framework Panel Discussion at JavaOne 2012 offered the following perspective: Spring is innovation, Java EE-standardization. Changes in technologies must prove their right to life, and then can be standardized. Wrong decision EJB 2.0 Entity Bean still spoils the view EJB technology, the reason for this failure was hasty standardization technology.

Enterprise Java without Java?

Described the ideas, patterns, practices that constitute the “Enterprise Edition” not inherently depend on Java. Of course, they work on the Java platform but are separate from the Java value.
Can I save this value and, in doing so, change the programming language? First, it would be logical to consider why change?
Summarizing the architecture from the previous section, I would like to propose the following figure, in which adding business logic components.

Analyzing the question is: should the business logic components are language dependent on which server platform implemented.
If this independence is possible, it will save the entire stack all the previous server platform technologies, as well as bring innovation and all the advantages of other languages for example, functional or dynamically typed languages. Of the benefits of other languages-conciseness, closures, operator overloading, the intuitive syntax for working with collections, the functional programming paradigm. Dynamic Languages open the door to use DSL with Java EE.
At the same time, the question arises, what server platform should be open to innovation. Perhaps some of these innovations will be convenient to make a different programming language because of the nature of their tasks.
With the question, why you might want to another programming language, sorted out.

Now the issue is and how to achieve this?
The achieved by standardizing platforms and using IDL (interface definition language) when writing server objects. However, rigid standardization of server platform closes the path of innovation. As a result, CORBA distributed little when building enterprise systems.
To find a solution, it is necessary to go beyond the previous picture and look for the Foundation on which is built the server platform itself. This Foundation is the JVM, see. In the figure below.

If the server platform is written in different languages that run on the same JVM, it will achieve the goals of:
Retains all existing outputs server platforms;
Allows you to open a server platform for innovation;
Allows you to develop business logic and server platform in different languages.

That’s why actively developing the direction of Polyglot JVM.
The following examples illustrate the findings:

• Grails platform (based on Groovy);

• Django with Jython;

• JSF + Groovy;

• Spring + Groovy

So, use Polyglot JVM achieves two goals: opens the way for innovation and enables you to save all of the developments in the sector of enterprise applications.

Translate the JVM

The JVM has always been separated from Java and had its set of instructions-byte code. A program written in another language and compiled to bytecode can perform on the JVM.
However, before JDK 6 and JDK 7, it was only possible to statically typed languages.
Scala is a statically typed language that appeared in the 2003 year is compiled into bytecode without problems by existing at the time the JVM instruction set.

The first step to support dynamically typed languages made in JDK 6 — the library added to the Java Scripting API (Java.script script. *). However, this decision was partial. To enable scripting code worked, needed a scripting engine for this language. Such a decision was not a performance, because in fact performed “double” interpretation of the first interpretation of script code using the engine, and then interpreting engine system virtual machine.

Real “Polyglot” JVM became in JDK 7 thanks to the emergence of a new JVM instruction invoke dynamic, designed for dynamic languages. Thanks to this instruction code scripting performance dramatically improved.
At the moment on the JVM may work in the following languages: Java, Scala, Clojure, Groovy, JRuby, Jython, and others.
For more information, recommend a presentation on languages for the JVM.

Alternative architecture and Polyglot JVM

Now evolving and other server platforms, for example, by event-driven architecture (EDA), in particular, Akka.
For platforms based on EDA also applies the ideology of containers and services. However, the list should be revised and might differ from the list of services, CORBA/Java EE/Spring. It’a nicely illustrates the example distributed transaction service.

Use events instead of remote procedure calls (RPC) allow achieving loose coupling. However, this approach becomes unclear where to install the transaction boundaries. Setting the transaction boundaries leads to high coupling

Thus, for EDA the same picture-developments in the field of EDA have their value and not to depend on the programming language.
Akka is regarded with Scala and Java. However, there are precedents for other languages, such as aqua + Groovy (http://littlesquare.com/2012/02/playing-with-akka-groovy-rest-maven/).
Use Polyglot JVM for EDA also helps keep developments in technologies and platforms and use the advantages of other languages.

Conclusions

Java technology for enterprise applications is undeniably valuable. Thanks to the Polyglot JVM, you can save all these technologies, and this opens the possibility of the use of new languages in the enterprise.

So, Polyglot JVM paves the way for innovation and enables you to save all of the developments in the sector of business applications:
Keep all existing best practices for Java Server platforms;

Open the server platform for innovation;
Develop business logic in a language other than the language of the server platform and bring in the development of business logic with all the advantages of functional languages and languages with dynamically typed;