Java Enterprise with Polyglot JVM

Olena Syrota,EPAM JAVA Competency Center

April 2013

New Prospectsof Java Enterprisewith Polyglot JVM

1 │ EPAM SYSTEMS, INC.

New Prospects of Java Enterprise with Polyglot JVM

Introduction

One of the most frequent questions today is “what language will replace Java?” Then, what should we do with all the existing Java technolo-gies of enterprise applications development (Java EE, Spring, Akka)? All these technologies are definitely valuable. Is it possible to replace a programming language and make use of the best practices at the same time? I suppose, it is.

Now let’s take a closer look and elaborate here on the Polyglot JVM trend and its influence.

Introduction of Polyglot JVM has two goals. The

first one is to clear the way for innovations, while the second one is to preserve all Java technolo-gies in the enterprise applications sector. But it will be long before we come to these conclu-sions.

This paper targets developers of enterprise applications. I hope it will help to systemize the knowledge on architectures of Java-based server platforms, and, perhaps, it will inspire to study dynamic languages.

New Prospects of Java Enterprise with Polyglot JVM

2 │ EPAM SYSTEMS, INC.

Object ManagementArchitecture, CORBA

Server platform architectures originally come from Object Management Architecture (OMA) and CORBA, developed by OMG Group.

It’s funny how the elder generation of developers interpret OMG as Object Management Group

while for the younger generation it’s Oh My God!

Object Management Architecture (OMA, http://www.omg.org/oma) was developed for distributed object systems where the client uses RPC to invoke remotely an object method.

More details about the types of resources for the invocation via RPC can be found here:

https://www2.opengroup.org/ogsys/catalog/c706 (part 2.1.1.5).

Depending on what is treated as a remote resource, there are the following resource types: a server, a service, and an object. Careful exam-ination of these resource types allows to suggest the corresponding application architec-

tures for every resource type, i.e. client-server, service-oriented, and distributed object architec-tures.

Thus, OMA was created for the third type of resources, the objects. Today other types of resources, service (e.g. via SOAP) and server (e.g. via SQL, HTTP), are more actively used.

But the shift of the resource type from an object to a server/service didn’t prevent a great number of OMA ideas to be transferred to the architecture of Java-based platforms for enter-prise applications.

Figure 1 OMA architecture

New Prospects of Java Enterprise with Polyglot JVM

3 │ EPAM SYSTEMS, INC.

Figure 2ORB Structure, object adapter is marked out red

The important part of OMA is Object Request Broker (ORB). ORB is wider than just object-ori-ented RPC. To some extent, it is an analogue of the applications server in terms of functionality.

CORBA (Common Object Request Broker Architecture and Specification) specifies how ORB should be realized.

ORB Architecture is based on two main ideas:

• the client architecture should be simple;

• all the scalability mechanisms allowing

the server to sustain high load are on the server, which makes the server architecture more complicated.

ORB introduces the concept of a container for business logic objects (object adapter); a container creates and destroys these objects on the server. The image below illustrates the ORB structure, with the object adapter marked out red.

All of the above is required to ensure the server work under high load. Thus,

1) the client is not allowed to create server objects manually for fear they won’t be destroyed;

2) the server may apply scalability mecha-nisms to objects (unload an object in case it hasn’t been invoked for a long time, load it if necessary).

In this scheme the client’s permissions are limit-

ed to requesting the server object link from the server and remotely invoking the object method.

In addition to the business logic container, there is an OMA concept of services (Object Services) as a part of the server platform (see the scheme below). The list of services includes distributed transaction service, event service and others (for the full list follow the link: http://www.omg.org/spec/#CS).

New Prospects of Java Enterprise with Polyglot JVM

4 │ EPAM SYSTEMS, INC.

Copiright Springer Verlag Berlin Heidelberg 2004

Figure 3CORBA Object Services

Figure 4Server platform structure: containers and services

The server object implementation can request services through the object adapter mentioned above.

Thus, CORBA accumulates the ideas which are

actively used in modern Java-based server platforms, namely the usage of containers and services as shown on the picture below.

CORBA contains a lot of other ideas which are widely used nowadays. It was CORBA where the concept of interceptor (CORBA specifica-tion, Version 2.3, Chapter 21) was introduced. In CORBA, interceptor is a “hook” helping to

invoke services during server object construc-tion or invocation. Today interceptors are widely used in IoC-containers in Spring and in Java EE.

New Prospects of Java Enterprise with Polyglot JVM

5 │ EPAM SYSTEMS, INC.

Java EE / Spring platformsarchitecturesIn comparison to CORBA, modern server platforms architectures (Java EE and Spring in particular) have certainly evolved. The following new frameworks were added to server platforms:

• Web-framework;

• IoC-container;

• ORM- framework.

The usage of the GIOP/IIOP protocol for client-servers communication is central in CORBA. Nowadays, HTTP, SOAP, and REST (over HTTP) protocols are used for this purpose.

To ensure compatibility with the HTTP protocol, a servlet-container is added to the server platform. The servlet-container processes HTTP only, and actually provides no programming model for building business logic. The code written for servlet-containers is highly depend-ent on the HTTP protocol.

It resulted in new web-frameworks created to perform the following tasks:

1) removing business logic dependency from the communication protocol;

2) introducing architecture patterns for the application logic (e.g. MVC) which speed up web-application development;

3) controlling the objects life cycle in scopes relevant for web-applications.

Now let’s move to IoC-container (Inversion of Control). IoC-container solves the following task: it allows to transfer the ability to control the life cycle of any server object to the container, while the business logic code still does not depend on the container itself.

The ORM-framework for persistent objects takes an important place in the platform struc-ture. Why emphasize such an obvious fact? In practice, this framework should not possess the functions of a container (i.e. to control the life cycle of a persistence object). That mistake, Container Managed EJB Entity Beans, was made in EJB 2.0. Still, this solution proved ineffi-cient.

It can be illustrated as follows:

Figure 5Standard architecture of a Java-based server platform

New Prospects of Java Enterprise with Polyglot JVM

6 │ EPAM SYSTEMS, INC.

Java EE

As far as you see, we have singled out two important design elements of CORBA which are actively used in Java EE as well – containers of server objects and services as a part of a server platform.

The main containers in Java EE are a serv-let-container, EJB-container and IoC-container. The main services include the transaction service JTS, security service, JDBС, naming service JNDI, message service JMS, HTTP service, and management service JMX.

In fact, Java EE originated from CORBA. If you doubt, please create an application with Remote EJB support, receive an error while invoking EJB, and look at the stack – you will see the words CORBA, poa (portable object adapter) and marshalling.

Spring

Spring represents the same architecture as Java EE (CORBA), where containers, services and frameworks are actively used.

Figure 6Java EE platform structure

Figure 7Spring platform structure

New Prospects of Java Enterprise with Polyglot JVM

7 │ EPAM SYSTEMS, INC.

Still, there are some differences:

1) Spring can be deployed standalone or on the basis of the web server that provides the servlet-container and basic services;

2) Spring incorporates the APIs for working with enterprise services. The APIs can be provided once required.

Spring vs Java EE

During Java EE and Spring Framework Panel

Discussion at JavaOne 2012, the following viewpoint was proposed: Spring is innovation, Java EE is standardization. Technology innova-tions should prove their right for life first to be standardized afterwards. The poor EJB 2.0 Entity Bean solution still affects the opinion about EJB technology. Too hasty standardiza-tion was the main reason for this failure.

Figure 8Java EE and Spring Framework Panel Discussion, JavaOne 2012

Java Enterprise without Java?

The ideas, patterns, and practices described in “Enterprise Edition” in fact don’t depend on Java. Sure, they work on the Java platform, but they are valuable regardless of Java.

Can we preserve this value and change the programming language at the same time? For now, the question is why we should change the language at all.

Summarizing the architectures from the previ-ous section, I would like to suggest the following scheme with business logic components includ-ed.

New Prospects of Java Enterprise with Polyglot JVM

8 │ EPAM SYSTEMS, INC.

After studying the scheme, you may be wonder-ing if business logic components should be dependent on the language of the server platform implementation.

Their independence would allow to preserve all the best practices and all the stack of the server platform technologies, as well as to introduce innovations and all the advantages of other languages, e.g. functional or dynamically typed ones. Among advantages of other languages there are laconism, closures, operator overload-ing, intuitive syntax for collections, and the func-tional programming paradigm. Additionally, dynamic languages make DSL usage with Java Enterprise possible.

Another question is whether a server platform should be open for innovations. For sure, some of them would be more convenient to implement in another programming language because of the tasks they are able to solve.

It seems we are done here with the question of why another programming language may be useful.

But here is one more question: how do we achieve this?

Independence of server objects from the language of service platform implementation was introduced back in CORBA. That was achieved by the platform standardization and the IDL (interface definition language) usage for server objects implementation. However, strict standardization of a server platform leaves little space for innovations. As a result, CORBA is rarely used for corporate systems development.

To find the solution, we should go beyond the limits of the previous scheme and look for the server platform foundation. This foundation is JVM, as shown below (next page).

Figure 9

New Prospects of Java Enterprise with Polyglot JVM

9 │ EPAM SYSTEMS, INC.

Figure 10

If the server platform and business logic are written in different languages executed on the same JVM, it will allow to achieve the following goals:

1) To preserve all the best practices of the existing server platforms;

2) To ensure that the server platform is open for innovations;

3) To develop the server platform and business logic in different languages.

These are the reasons why Polyglot JVM is actively developing. The following examples just prove it:

1) Grails platform (based on Groovy);

2) Django with Jython;

3) JSF + Groovy;

4) Spring + Groovy (http://www.ibm.com/developerworks/java/library/j-groovierspring1/index.html, http://habrahabr.ru/post/145158/).

Thus, Polyglot JVM meets two goals: it makes way for innovations and allows to keep all the best technologies/practices in the enterprise applications sector.

New Prospects of Java Enterprise with Polyglot JVM

10 │ EPAM SYSTEMS, INC.

Polyglot JVM

JVM has been always separated from Java and executed its own instruction set called bytecode. The program written in another language and compiled into bytecode could be built on JVM. Prior to JDK 6 and JDK 7 it was possible only for statically typed languages.

Scala, a statically typed language appeared in 2003, could be easily compiled into the JVM-by-tecode.

The first attempt to support dynamically typed languages was made in JDK 6 with Java Script-ing API (javax.script.*). Still, it wasn’t a complete solution. The script code required a scripting engine attached via Java Scripting API to work. This solution led to poor performance due to “double” interpretation: first, the script code interpretation by the engine, and second, the engine code interpretation by the virtual machine.

Later, the script code performance was consid-erably improved due to the new JDK 7 instruc-tion invokedynamic, which made JVM a real “polyglot”. Now the following languages can run atop JVM: Java, Scala, JRuby, Groovy, Clojure, Jython, and others.

For more information about JVM languages, I recommend this presentation.

New Prospects of Java Enterprise with Polyglot JVM

11 │ EPAM SYSTEMS, INC.

Alternative architecturesand Polyglot JVM

At the moment other server platforms are being developed, e.g. those based on the event driven architecture (EDA), and Akka in particular (http://www.oraclejavamagazine-digital.com/javamagazine/20121112?pg=56#pg56).

The ideology of containers and services is also applicable for EDA-based platforms. Still, it is necessary to review their list of services and make it different from the list of CORBA/Java EE/Spring services. That can be perfectly illustrated by the distributed transaction service. Using events instead of remote invocation (RPC) allows to achieve loose coupling, although this approach makes it unclear where to set the transaction boundaries. Setting transaction boundaries lead to tight coupling (http://natishalom.typepad.com/nati_shaloms_blog/2007/08/lessons-from-am.html).

As a result, it is the same about EDA: its practic-es have their own value and do not depend on a programming language.

Traditionally, Akka is considered alongside with Scala and Java, but there are cases when other languages are used, e.g. Akka + Groovy (http://littlesquare.com/2012/02/playing-with-akka-groovy-rest-maven/).

Polyglot JVM used for EDA allows to preserve the best practices in technologies and to enjoy the advantages of other languages at the same time.

New Prospects of Java Enterprise with Polyglot JVM

12 │ EPAM SYSTEMS, INC.

Conclusions

Java technologies for enterprise applications are definitely valuable. Thanks to Polyglot JVM all these technologies can be preserved while new languages can be used at the same time.

In a nutshell, Polyglot JVM makes way for inno-vations and allows to preserve all the best prac-tices in the enterprise applications sector, i.e.

1) it saves the best practices of server platforms for Java;

2) it makes server platforms open for innova-tions;

3) it brings all the advantages of the function-al and dynamically typed languages into busi-ness logic development due to the possibility to implement business logic in the language different from the one of server platform

implementation;

4) it minimizes expenses: the team uses the languages they know, and there is no need to waste time and money on retraining.

© 1993-2013 EPAM Systems. All Rights Reserved.

Global41 University Drive Suite 202,Newtown (PA), 18940, USAPhone: +1-267-759-9000Fax: +1-267-759-8989

EUCorvin Offi ces I. Futó street 47-53Budapest, H-1082, HungaryPhone: +36-1-327-7400Fax: +36-1-577-2384

C IS9th Radialnaya Street, bldg. 2Moscow, 115404, RussiaPhone: +7-495-730-6360Fax: +7-495-730-6361

Established in 1993, EPAM Systems (NYSE: EPAM) provides complex software engineering solutions through its award-winning Central and Eastern European service delivery platform. Headquartered in the United States, EPAM employs approximately 8,500 IT professionals and serves clients worldwide from its locations in the United States, Canada, UK, Switzerland, Germany, Sweden, Belarus, Hungary, Russia, Ukraine, Kazakhstan, and Poland.

EPAM is recognized among the top companies in IAOP’s “The 2012 Global Outsourcing 100”, featuring EPAM in a variety of sub-lists, including “Leaders – Companies in Eastern Europe”. The company is also ranked among the best global service provid-ers on “The 2012 Global Services 100” by Global Services Magazine and Neogroup, which names EPAM “Leaders - Global Product Development” category.

For more information, please visit www.epam.com