Java Enterprise with Polyglot JVM

285 views

Published on

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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
285
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Java Enterprise with Polyglot JVM

  1. 1. New Prospects of Java Enterprise with Polyglot JVM Olena Syrota, EPAM JAVA Competency Center April 2013
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.

×