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 innovations and allows to preserve all the best practices in the enterprise applications sector, i.e.

1. New Prospects
of Java Enterprise
with Polyglot JVM
Olena Syrota,
EPAM JAVA Competency Center
April 2013

2. 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 technologies 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
1 │ EPAM SYSTEMS, INC.
first one is to clear the way for innovations, while
the second one is to preserve all Java technologies in the enterprise applications sector. But it
will be long before we come to these conclusions.
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.

3. New Prospects of Java Enterprise with Polyglot JVM
Object Management
Architecture, 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/c70
6 (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 examination of these resource types allows to
suggest the corresponding application architec-
Figure 1
OMA architecture
2 │ EPAM SYSTEMS, INC.
tures for every resource type, i.e. client-server,
service-oriented, and distributed object architectures.
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 enterprise applications.

4. New Prospects of Java Enterprise with Polyglot JVM
The important part of OMA is Object Request
Broker (ORB). ORB is wider than just object-oriented 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:
•
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.
the client architecture should be simple;
•
the server to sustain high load are on the
server, which makes the server architecture
more complicated.
all the scalability mechanisms allowing
Figure 2
ORB Structure, object adapter is marked out red
All of the above is required to ensure the server
work under high load. Thus,
ed to requesting the server object link from the
server and remotely invoking the object method.
1) the client is not allowed to create server
objects manually for fear they won’t be
destroyed;
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).
2) the server may apply scalability mechanisms 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-
3 │ EPAM SYSTEMS, INC.

5. New Prospects of Java Enterprise with Polyglot JVM
Copiright Springer Verlag Berlin Heidelberg 2004
Figure 3
CORBA Object Services
The server object implementation can request
services through the object adapter mentioned
above.
actively used in modern Java-based server
platforms, namely the usage of containers and
services as shown on the picture below.
Thus, CORBA accumulates the ideas which are
Figure 4
Server platform structure: containers and services
CORBA contains a lot of other ideas which are
widely used nowadays. It was CORBA where
the concept of interceptor (CORBA specification, Version 2.3, Chapter 21) was introduced. In
CORBA, interceptor is a “hook” helping to
4 │ EPAM SYSTEMS, INC.
invoke services during server object construction or invocation. Today interceptors are widely
used in IoC-containers in Spring and in Java EE.

6. New Prospects of Java Enterprise with Polyglot JVM
Java EE / Spring platforms
architectures
In 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 dependent 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;
Figure 5
Standard architecture of a Java-based server platform
5 │ EPAM SYSTEMS, INC.
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 structure. 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 inefficient.
It can be illustrated as follows:

7. New Prospects of Java Enterprise with Polyglot JVM
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 servlet-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.
Figure 6
Java EE platform structure
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.
Figure 7
Spring platform structure
6 │ EPAM SYSTEMS, INC.
Spring
Spring represents the same architecture as
Java EE (CORBA), where containers, services
and frameworks are actively used.

8. New Prospects of Java Enterprise with Polyglot JVM
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.
Discussion at JavaOne 2012, the following
viewpoint was proposed: Spring is innovation,
Java EE is standardization. Technology innovations 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 standardization was the main reason for this failure.
Spring vs Java EE
During Java EE and Spring Framework Panel
Figure 8
Java 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.
7 │ EPAM SYSTEMS, INC.
Summarizing the architectures from the previous section, I would like to suggest the following
scheme with business logic components included.

9. New Prospects of Java Enterprise with Polyglot JVM
Figure 9
After studying the scheme, you may be wondering 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 overloading, intuitive syntax for collections, and the functional 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.
8 │ EPAM SYSTEMS, INC.
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).

10. New Prospects of Java Enterprise with Polyglot JVM
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);
9 │ EPAM SYSTEMS, INC.
2) Django with Jython;
3) JSF + Groovy;
4) Spring + Groovy
(http://www.ibm.com/developerworks/java/lib
rary/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.

11. New Prospects of Java Enterprise with Polyglot JVM
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.
Later, the script code performance was considerably improved due to the new JDK 7 instruction invokedynamic, which made JVM a real
“polyglot”. Now the following languages can run
atop JVM: Java, Scala, JRuby, Groovy, Clojure,
Jython, and others.
Scala, a statically typed language appeared in
2003, could be easily compiled into the JVM-bytecode.
For more information about JVM languages,
I recommend this presentation.
The first attempt to support dynamically typed
languages was made in JDK 6 with Java Scripting 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.
10 │ EPAM SYSTEMS, INC.

12. New Prospects of Java Enterprise with Polyglot JVM
Alternative architectures
and 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/jav
amagazine/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_b
log/2007/08/lessons-from-am.html).
11 │ EPAM SYSTEMS, INC.
As a result, it is the same about EDA: its practices 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-ak
ka-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.

13. New Prospects of Java Enterprise with Polyglot JVM
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 innovations and allows to preserve all the best practices 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 innovations;
3) it brings all the advantages of the functional and dynamically typed languages into business logic development due to the possibility
to implement business logic in the language
different from the one of server platform
12 │ EPAM SYSTEMS, INC.
implementation;
4) it minimizes expenses: the team uses the
languages they know, and there is no need to
waste time and money on retraining.

14. 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 providers 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
G lob al
EU
CIS
41 University Drive Suite 202,
Newtown (PA), 18940, USA
Phone: +1-267-759-9000
Fax: +1-267-759-8989
Corvin Offices I. Futó street 47-53
Budapest, H-1082, Hungary
Phone: +36-1-327-7400
Fax: +36-1-577-2384
9th Radialnaya Street, bldg. 2
Moscow, 115404, Russia
Phone: +7-495-730-6360
Fax: +7-495-730-6361
© 1993-2013 EPAM Systems. All Rights Reserved.