UNIVERSIDAD DE LOS ANDES SCHOOL OF ENGINEERING
Department of Systems and Computer Engineering Software Construction Group
Migrating JEE applications to
a microservice-based architecture
deployed in the cloud.
Mauricio Verano Merino
A thesis submitted in partial fulfilment of the requirements for the degree of Master in Software Engineering
at Universidad de los Andes
May, 2015
Promoters: Prof. Dr. Kelly Garces Prof. Dr. Rubby Casallas
Abstract
Currently, there are many enterprise applications developed using the Java Enter-prise Edition API’s and specifications with a monolithic architecture. This API’s and specifications was not designed to support today’s application requirements.
The way most enterprises have adapted their JEE applications for today’s requirements is improving their machines configurations. The previous fact have a big impact in terms of costs.
On the other hand, appears cloud computing paradigm. This paradigm is being adopted by many companies in order to support high scalability requirements. This technology is often used to deploy monolith applications in a cloud provider. This solution makes expenses increase compared to an application that was de-signed and developed to satisfy high scalability requirements and be deployed in the cloud.
The prior facts motivates this dissertation. We have designed and imple-mented a process to make easier the JEE modernization into a micro-service based architecture deployed in the cloud. This process was made in order to take a monolith application and turn into a distributed application, in which every small part could be scaled independently to the other parts. These facts are translated in terms of optimizing computational resources and money.
In order to observe the consequences of splitting a monolith application into small pieces of code, it was executed some load test to both applications (monolith and micro-service) using the same tests scenarios. This load tests were designed in order to compare the results obtained by each application. In addition, all the test scenarios were run three times. Finally the results are based on three metrics: average response time (milliseconds), percentage error (percentage) and throughput (number of request/second)
Resumen
En la actualidad hay un gran número de aplicaciones empresariales desarrolladas usando los API’s y las especificaciones Java Enterprise Edition con un arquitec-turas monolíticas. Este tipo de APIs o especificaciones no fueron diseñadas para soportar los requerimientos que exigen las aplicaciones de hoy en día.
La manera como actualmente las empresas adaptan sus aplicaciones desar-rolladas siguiendo las especificaciones JEE, es usando máquinas con una mejor configuración de hardware. Lo anterior es implementado teniendo en cuenta las consecuencias económicas que éste tipo de soluciones tienen. Por otro lado, surge la idea de la computación en la nube. Muchas empresas ven esta tecnología como la solución para que sus aplicaciones monolíticas cumplan con altos requerimien-tos de escalabilidad. Esta solución es muy usada actualmente, debido a su fácil implementación, ya que toman la aplicación monolítica y la despliegan en un proveedor de servicios en la nube, esta solución hará que los costos sean elevados en comparación con una aplicación diseñada para escalar y ser desplegada en la nube.
Por estos motivos, en este documento se propone un proceso para realizar la mod-ernización de aplicaciones JEE a una arquitectura orientada a micro-servicios de-splegada en la nube. Esto con el fin de transformar una aplicación monolítica en una aplicación distribuida, en la cual cada una de sus partes puede ser escalada de manera independiente, haciendo un uso más óptimo de los recursos, tanto computacionales como económicos.
Para verificar las implicaciones que tiene realizar el proceso de dividir una aplicación monolítica en varias partes más pequeñas, se ejecutaron pruebas de carga sobre ambas aplicaciones, usando los mismos escenarios de prueba. Esto con el fin de comparar los resultados en ambos casos. Las métricas que serán objeto de estudio son: tiempo medio de respuesta (milisegundos), porcentaje de error en las respuestas (porcentaje) y el rendimiento (número de usuarios/se-gundo).
Acknowledgements
I would like to thank to my advisors and my family for their support during the development of this thesis.
Table of Contents
Abstract i
Resumen ii
Acknowledgements iii
Table of Contents v
List of Figures vii
List of Tables xi
1 Introduction 1
1.1 Context . . . 1
1.2 Problem statement . . . 1
1.3 Overal Strategy . . . 2
1.4 Validation . . . 3
1.5 Organization of the dissertation . . . 3
2 Context 5 2.1 JEE applications . . . 5
2.2 Micro-services . . . 6
2.3 Cloud computing . . . 7
2.4 Model driven engineering . . . 8
3 Problem statement 11 3.1 Divide a monolith . . . 11
3.2 Lack of knowledge about deployment options . . . 12
3.3 On premise Vs Cloud . . . 12
4 State of the art 15 4.1 IaaS approaches . . . 15
4.2 PaaS approaches . . . 17
4.3 IaaS and PaaS approaches . . . 17
5 Case Study 21 5.1 Marketplace application . . . 21
6 Solution Strategy 23 6.1 JEE Application . . . 24
6.2 Cartography model . . . 24
6.3 Expose EJB as RESTful web service . . . 25
vi Table of Contents
6.3.1 Class level annotations . . . 25
6.3.2 Method level annotations . . . 26
6.3.3 Communication between modules . . . 28
6.4 Cartography model annotated . . . 29
6.5 Reorganized and annotated code with wrappers . . . 30
6.5.1 Model to text (M2T) transformation . . . 30
6.5.2 Java parser . . . 31
6.6 Compiled code . . . 33
6.7 Cloud provisioning . . . 34
6.7.1 Application requirements . . . 34
6.7.2 Virtual containers . . . 34
6.8 Software deployment . . . 35
7 Validation 37 7.1 Data set . . . 37
7.1.1 Dividing marketplace into micro-services . . . 37
7.2 Provisioning and deployment . . . 39
7.3 Load Test . . . 41
7.3.1 Test environment . . . 42
7.3.2 Test scenarios . . . 42
7.4 Results . . . 43
7.4.1 GET . . . 43
7.4.2 POST . . . 50
7.4.3 Master . . . 57
7.5 Discussion . . . 64
7.5.1 Get Item . . . 64
7.5.2 Get Product . . . 66
7.5.3 Post Item . . . 67
7.5.4 Post Product . . . 69
7.5.5 Master Get . . . 70
7.5.6 Master Post . . . 72
8 Conclusions and Future Work 77
List of Figures
2.1 This figure shows an achitecture of a JEE application. [Ora11] . 5 2.2 This figure shows an example of technology heterogeneity. [New15] 7
2.3 This figure shows an example of micro-service scalability. [New15] 8
2.4 This figure shows a cloud categories comparison. . . 9
3.1 This figure shows an example of a JEE application. [Ger] . . . . 12
5.1 This figure shows a component diagram from the monolith textit-marketplace application. . . 22
5.2 This figure shows a deployment diagram from the monolith textit-marketplace application. . . 22
5.3 This figure shows all the metrics related to the source code of the case study:textitmarketplace. . . 22
6.1 This figure shows all the proposed process . . . 24
6.2 Thie figure above shows the java parser and the model to text (M2T) transformation . . . 30
6.3 Thie figure above shows and overview of the cloud provisioning. . 34
7.1 The figure above shows all the metrics related to the source code of the textitCart micro-service. . . 38
7.2 The figure above shows all the metrics related to the source code of the textitItem micro-service. . . 38
7.3 The figure above shows all the metrics related to the source code of the textitMaster micro-service. . . 39
7.4 The figure above shows all the metrics related to the source code of the textitProduct micro-service. . . 39
7.5 This figure shows a deployment diagram of the micro-service ori-ented textitmarketplace application. . . 40
7.6 This figure shows a deployment diagram of the cluster test envi-ronment . . . 42
7.7 The above figure shows a comparison between the monolith archi-tecture and the micro-service oriented archiarchi-tecture in terms of the average response time against the number of threads. The service consumed was get all items through an HTTP GET request. . . . 64
7.8 The above figure shows a comparison between the monolith archi-tecture and the micro-service oriented archiarchi-tecture in terms of the percentage of error against the number of threads. The service consumed was get all items through an HTTP GET request. . . . 65
viii List of Figures
7.9 The above figure shows a comparison between the monolith archi-tecture and the micro-service oriented archiarchi-tecture in terms of the throughput against the number of threads. The service consumed was get all items through an HTTP GET request. . . 65
7.10 The above figure shows a comparison between the monolith archi-tecture and the micro-service oriented archiarchi-tecture in terms of the average response time against the number of threads. The service consumed was get all products through an HTTP GET request. . 66
7.11 The above figure shows a comparison between the monolith archi-tecture and the micro-service oriented archiarchi-tecture in terms of the percentage of error against the number of threads. The service consumed was get all products through an HTTP GET request. . 66
7.12 The above figure shows a comparison between the monolith archi-tecture and the micro-service oriented archiarchi-tecture in terms of the throughput against the number of threads. The service consumed was get all products through an HTTP GET request. . . 67
7.13 The above figure shows a comparison between the monolith archi-tecture and the micro-service oriented archiarchi-tecture in terms of the average response time against the number of threads. The service consumed was create item through an HTTP POST request. . . . 67
7.14 The above figure shows a comparison between the monolith archi-tecture and the micro-service oriented archiarchi-tecture in terms of the percentage of error against the number of threads. The service consumed was create item through an HTTP POST request. . . . 68
7.15 The above figure shows a comparison between the monolith archi-tecture and the micro-service oriented archiarchi-tecture in terms of the throughput against the number of threads. The service consumed was create item through an HTTP POST request. . . 68
7.16 The above figure shows a comparison between the monolith archi-tecture and the micro-service oriented archiarchi-tecture in terms of the average response time against the number of threads. The service consumed was create product through an HTTP POST request. . 69 7.17 The above figure shows a comparison between the monolith
archi-tecture and the micro-service oriented archiarchi-tecture in terms of the percentage of error against the number of threads. The service consumed was create product through an HTTP POST request. . 69
7.18 The above figure shows a comparison between the monolith archi-tecture and the micro-service oriented archiarchi-tecture in terms of the throughput against the number of threads. The service consumed was create product through an HTTP POST request. . . 70
7.19 The above figure shows a comparison between the monolith archi-tecture and the micro-service oriented archiarchi-tecture in terms of the average response time against the number of threads. The service consumed was get all mastercarts through an HTTP GET request. 70
7.20 The above figure shows a comparison between the monolith ar-chitecture and the micro-service oriented arar-chitecture in terms of the percentage error against the number of threads. The service consumed was get all mastercarts through an HTTP GET request. 71
List of Figures ix
7.21 The above figure shows a comparison between the monolith archi-tecture and the micro-service oriented archiarchi-tecture in terms of the throughput against the number of threads. The service consumed was get all mastercarts through an HTTP GET request. . . 71 7.22 The above figure shows a comparison between the monolith
archi-tecture and the micro-service oriented archiarchi-tecture in terms of the average response time against the number of threads. The service consumed was create mastercart through an HTTP POST request. 72 7.23 The above figure shows a comparison between the monolith
ar-chitecture and the micro-service oriented arar-chitecture in terms of the percentage error against the number of threads. The service consumed was create mastercart through an HTTP POST request. 72 7.24 The above figure shows a comparison between the monolith
archi-tecture and the micro-service oriented archiarchi-tecture in terms of the throughput against the number of threads. The service consumed was create mastercart through an HTTP POST request. . . 73
List of Tables
4.1 Comparative table with different approaches . . . 15
7.1 The above table shows a comparison between the average response time from a monolith application against a micro-service applica-tion consuming aGET service in the Item module. . . 44 7.2 The above table shows a comparison between the percentage of
er-ror from a monolith application against a micro-service application consuming aGET service in the Item module. . . 45 7.3 The above table shows a comparison between the throughput from
a monolith application against a micro-service application consum-ing a GET service in the Item module. . . 46 7.4 The above table shows a comparison between the average response
time from a monolith application against a micro-service applica-tion consuming aGET service in the Product module. . . 47 7.5 The above table shows a comparison between the error percentage
from a monolith application against a micro-service application consuming aGET service in the Product module. . . 48 7.6 The above table shows a comparison between the throughput from
a monolith application against a micro-service application consum-ing a GET service in the Product module. . . 49 7.7 The above table shows a comparison between the average response
time from a monolith application against a micro-service applica-tion consuming aPOST service in the Item module. . . 51 7.8 The above table shows a comparison between the error percentage
from a monolith application against a micro-service application consuming aPOST service in the Item module. . . 52 7.9 The above table shows a comparison between the throughput from
a monolith application against a micro-service application consum-ing a POST service in the Item module. . . 53 7.10 The above table shows a comparison between the average response
time from a monolith application against a micro-service applica-tion consuming aPOST service in the Product module. . . 54 7.11 The above table shows a comparison between the error percentage
from a monolith application against a micro-service application consuming aPOST service in the Product module. . . 55 7.12 The above table shows a comparison between the throughput from
a monolith application against a micro-service application consum-ing a POST service in the Product module. . . 56 7.13 The above table shows a comparison between the average response
time from a monolith application against a micro-service applica-tion consuming aGET service from the Master module. . . 58
xii List of Tables
7.14 The above table shows a comparison between the error percentage from a monolith application against a micro-service application consuming aGET service from the Master module. . . 59 7.15 The above table shows a comparison between the throughput from
a monolith application against a micro-service application consum-ing a GET service from the Master module. . . 60 7.16 The above table shows a comparison between the average response
time from a monolith application against a micro-service applica-tion consuming aPOST service from the Master module. . . 61 7.17 The above table shows a comparison between the error percentage
from a monolith application against a micro-service application consuming aPOST service from the Master module. . . 62 7.18 The above table shows a comparison between the throughput from
a monolith application against a micro-service application consum-ing a POST service from the Master module. . . 63
1
Introduction
1.1 Context
JEE APIs and specifications are commonly used in enterprise applications; JEE is an extension of the Java SE. This extensions (specifications) make JEE able to fulfill different non-functional requirements like: transactional operations, con-currency, security, web services, among others. Prior benefits make JEE useful to achieve different requirements.
Currently, we have many approximations in terms of distributed software ar-chitectures. One of the most recent architectural style is called Micro-services. This architectural style is based on the Simple Responsibility Principle (SRP) in which the architect divides an application in small parts that are specialized a small tasks subset. In addition, as described by Krause [Kra15] "Microservices are important simply because they add unique value in a way of simplification of complexity in systems.". This architectural style gives different benefits in terms of: increased cohesion, polyglot applications, isolation, resilience, among others.
There have been many advances in order to simplify the infrastructure ac-quiring process, in terms of costs and hardware. To solve some of this problems systems have adopted Cloud computing. This technology allows users to provi-sion and reserve instances through Internet in a short space of time. This makes easier the provisioning process. In addition, the business model is a little bit dif-ferent, because the charges are made only by use, there does not exist a fixed-rate payment.
1.2 Problem statement
In the industry there are millions of enterprise applications developed using Java Enterprise Edition (JEE or J2EE). Usually JEE specifications uses a monolith architecture in which coexist many compilation units like: Session Beans, Message
2 1.3. Overal Strategy
Driven Beans, Managed Beans, Entities, among others. This fact makes that scaling those applications is expensive and time consuming.
In addition, not all cloud providers support the deployment of EJB’s.
Besides, modern applications need to supports a high number of concurrent users trying to access different resources, this implies that architects need to design and implement a highly scalable architecture in order to fulfill the desired quality scenarios. It is important to mention that scalability is not the only issue in monolith applications, there are other quality attributes that are not successfully achieved in monolith architectures.
1.3 Overal Strategy
• Contribution 1: Divide a monolith application
Most JEE applications have been implemented using a monolith archi-tecture in which every layer of the application lives in the same appli-cation server. Our concern resides on migrating appliappli-cations developed using a monolith architecture into a micro-service based architecture. In order to divide the monolithic application, we divide the application into functional entities. Our case study is build by four modules (Mas-ter, Cart, Item and Product). After the division process each module is going to be an isolated micro-service.
• Contribution 2: Create REST wrappers and REST communi-cation between modules
In order to execute the modernization process, we receive a JEE ap-plication, then this application is manually annotated by the architect with our annotations to create the REST wrappers and replace the in-jection dependencies calls with an HTTP requests.
To replace the calls between modules, we have developed aJava parser
that is in charge of finding the custom annotations. After finding the annotations, the parser comments the lines of code that invokes other modules and add some lines to make the HTTP request with the an-notation parameters provided by the architect.
Introduction 3
• Contribution 3: Deploy JEE application in a cloud provider
To successfully get the deployment process we have used virtual con-tainers. Our approach uses Docker container. In pursuance of the deployment process, we have created a Docker image with all the soft-ware required to run a JEE application (e.g. Java, Maven, Glassfish 4, GIT, among others). After this process we have created a custom image. The previous image was pushed to the Docker Hub Registry, in order to be able to use it from different locations.
After this process, we have made the provision process using a third party service. This service makes some abstraction of the cloud provider that enables developers to easy provision instances with dif-ferent Docker images.
1.4 Validation
In pursuance of validation process, we have used the marketplace case study
described in chapter 5. This case study let us apply the proposed modernization process and execute load tests to the deployed applications in order to get the results.
In the validation process, we have always used both applications: the monolith application and the micro-service application to compare the results obtained during the load tests.
1.5 Organization of the dissertation
This dissertation consists of seven chapters distributed as follows: in chapter 2 it is all related to the context which gives a general overview of the topics needed to understand the rest of the document. At chapter 3 we mention and explain the problem statement we try to solve. The chapter 4 contains the state of the art and the related work that motivate us. The chapter 5 describes the application that is going to be object of study in the validation chapter. The chapter 6 contains the solution strategy, this is a detailed description about our solution proposal. The chapter 7 consists of the validation process, how was made the validation, the obtained results after executing the tests and some discussion based on those results. Finally, the chapter 8 presents the proposed conclusions and future work.
2
Context
The main goal of this chapter is to give to the reader a general overview around some topics that motivate this work. In addition, we are going to give some concepts that we think are key to understand the whole work and the importance it have. The way this chapter is organized is: first we are going to talk about JEE applications, then we explain the micro-service architectural style, third we are going to talk about cloud computing and finally we are going to talk about model driven engineering (MDE).
2.1 JEE applications
Java Enterprise Edition is commonly used in enterprise applications. Basically almost all JEE applications have a monolith architecture as shown in figure 2.1. If you observe the figure, you can deduce a layer-based architecture with three layers: client, Java EE server and Enterprise Information System (EIS).
Figure 2.1 This figure shows an achitecture of a JEE application. [Ora11]
6 2.2. Micro-services
In the Java EE server layer there are two tiers: web tier and Business tier. At the web tier is related to the views, those views can be: JSP pages, JSF or plain servlets.
The business tier contains all related to the EJB’s: Session Beans, Message Beans, Managed Beans and Entities. This tier contains the application business logic and responds to the web tier interaction.
Usually the Java EE server layer is deployed into an application server like: WebLogic, Glassfish or JBoss. This servers makes easier the developers work, because the server can handle some functionality like: transactions, concurrency, security, among others. This let developers to concentrate his efforts developing the business logic.
The next tier is the EIS (Enterprise Information System) tier, this layer is in charge of making persistent the information that comes from the business tier, this task is usually is done by a JPA implementation (e.g. eclipselink, hibernate, etc). This layer it is composed by databases, this database could be a single or various instances.
The JEE architect know that in a JEE architecture like shown in figure 2.1 many modules with their corresponding EJB’s are going to be deployed in the same application server. This means, that a single application server is respon-sible for attending and managing the life-cycle of many Beans. As the number of Beans increases the application server is going to need more computational resources in order to attend all the requests.
2.2 Micro-services
According to Newman [New15] a micro-service is an architectural style defined assmall, autonomous services that works together. This means that each micro-service is expected to be small, in order to reduce the amount of lines of code that each project have. When the number of LOC’s is small, it is easier make specific changes. This decomposition makes the application less coupling by following the single responsibility principle (SRP).
The single responsibility principle [Mar09] says that"each module, subsystem, class or method should not have more than one reason to change". This means that if we have different components each one must have one independently re-sponsibility and need to be be independent from the rest of components. This let developers to deploy a single component without the need to re-deploy the whole application.
Currently we have not been talking about how small must be a micro-service. According to Newman [New15] smaller the service, the more you maximize the benefits and downsides of micro-service architecture. Firstly this makes us to think in terms of number for lines of code, but this metric is a bit subjective, because this metric would vary from one programming language to other. The prior fact knowing that some languages more verbose than others.
Secondly, other perspectives like the said by Jon Eaves [New15] a micro-service could be"something that could be re-written in two weeks". Again, this proposed measure its subjective, the time to re-write "something" depends in the expertise of the developers and other factors like complexity. At this point it is clear that defining how small must be a micro-service is not an easy task and may vary
Context 7
from one application to another. The best way to know how small must be each micro-service is to define what your organization or application can be named as a small functionality that can be isolated.
Additionally it is important to talk about what it means that a micro-service is
autonomous. This means that each micro-service is a self-sustainable entity that is able to change independently of each other modules. This fact is translated in a loose-coupling system. To effectively create an autonomous service, the architect needs to design his API and services URLs correctly. In addition, it is desirable to avoid deploying different micro-services in the same machine. In conclusion each micro-service is going to be deployed in his own machine. As a result, all the communication between micro-services is going to be through HTTP requests.
At the present we have mentioned just some characteristics about micro-services. Now we are going to talk about the benefits of adopting this architec-tural style. Firstly, using micro-services enable architects to use different tech-nologies in order to met different non-functional requirements. This means that the whole application could be polyglot(e.g. figure 2.2) and as said by New-man [New15] "Pick the right tool for each job rather than “one-size-fits-all” approach". In addition, enabling an application use different technology stacks makes adopting new technologies easier.
Figure 2.2 This figure shows an example of technology heterogeneity. [New15]
Other benefits of using micro-services is the resilience. Because all the system is distributed in small parts, each micro-service is responsible of handling partial and total failure. Therefore, if one service fails, the rest of the application will be working correctly. Additionally the use of a micro-service oriented architecture, let the architect improve the scalability requirements of the application. This is achieved thanks to the autonomously proposed by the micro-services. Therefore, each micro-service can be scaled in a different way, according to the demand. An example of the different scalability requirements for each micro-service is shown in the figure 2.3.
2.3 Cloud computing
Cloud computing has emerged as a new technology, that many companies want to adopt in order to reduce infrastructure costs. First of all, it is important to clarify that a virtualized data center is not the same as cloud computing environment. Now we are going to talk about some characteristics that are mandatory to talk about a cloud computing environment.
off-8 2.4. Model driven engineering
Figure 2.3 This figure shows an example of micro-service scalability. [New15]
premise way. This means that users can access the services everywhere, this is achieved through an Internet connection.
Second, the services must beelastic in order to increase or decrease resources by demand. This feature is related to costs and an efficient scalability.
Third, the payment is flexible, you only need to pay by use, this is translated in that you don’t have a fixed payment. If the demand increase, the costs also increase, if the demand decrease, the cost decrease. To make sure this works, it is very important that the service could bemeasurable. This is one of the main distinguishing characteristics of a cloud environment, if the service can not be measured, it is not a cloud environment.
Fourth, the service must bevirtualized, in order to support as many platforms as possible.
Fifth, the service must be delivered in an auto-service model, an the user can add resources on demand.
Sixth feature is that the resources must be delivered asservice, this means that the final user can access the resources through an API.
The last feature, each cloud provider must give his users a service-level agree-ment (SLA). In this docuagree-ment the provider specifies a contract and establish a compliance about the services he provides.
Today exists many cloud computing services, but all of them can be grouped in three main categories: Software as a Service (SaaS), Infrastructure as a Service (IaaS) and Platform as a Service (Paas). The main differences between all this categories is shown in figure 2.4. In this figures is showed a comparison between all the cloud services and a local infrastructure.
2.4 Model driven engineering
Model driven engineering (MDE) was designed to let developer work in a high abstraction level, using concepts from the design phase in order to avoid working in lower levels like: managing memory, CPU, among others.
In addition, MDE is expected to reduce development complexity and increase developers productivity. One of the main concerns of MDE was that all time languages are trying to raise the level of abstraction but always they are in a
Context 9
Figure 2.4 This figure shows a cloud categories comparison.
computing-oriented focus [Sch06]. MDE proposes a new paradigm, in which the abstraction is made in terms application domain. Having this in mind, when the abstraction is related with business terms it is centered in that domain. As consequence, "MDE tools impose domain-specific constraints" [Sch06].
MDE works with models and transformations, that takes an input and pro-duces an output.
Usually the input for those transformations receives a model or a text file (e.g. domain specific language file (DSL)) and then the input is passed through a trans-formation. The transformation could be from different natures: text to model (T2M), model to model (M2M) and model to text (M2T). The output of the transformation depends on the nature.
3
Problem statement
Cloud computing appears as a solution to make software and infrastructure more easily for business, while assuring a pay as you use cost and certain Quality Scenarios (QS) depending on the service level agreement (SLA) given by the provider.
Actually in software industry the number of enterprise applications that are de-ployed in a virtual-enabled environment is growing; many companies want to deploy their applications in a cloud computing environment to get the benefits of adopting such technology (e.g., costs reduction, profit increase, time to market decrease, elasticity, among others).
3.1 Divide a monolith
Having in mind that the JEE applications usually have a particular architecture as show in figure 3.1. In this architecture coexists different types of beans like Session Beans, Managed Beans, Message Beans and Entities, it is clear that one application server could have many components deployed in the same machine. As consequence of this scenario, the architect would need a big machine with higher configuration that enable the adequate operation and performance of the application. A big machine implies more costs to the enterprise.
On the other hand, when a developer wants to introduce a new feature or fix a found bug, it is mandatory that the developer compiles and re-deploys the whole application in order to make a release with the new added-feature, this is translated in terms of time and costs.
As a result of making a re-deploy process in a monolith application produces a downtime for the whole application. This downtime is independently to the number of modifications that has been made to the application.
In particular, when the JEE applications throw an exception they produce a very large stacktrace where is difficult to find where the exception was produced. This process gets more difficult in proportion to the amount of components that are deployed in the same server application.
12 3.2. Lack of knowledge about deployment options
Figure 3.1 This figure shows an example of a JEE application. [Ger]
3.2 Lack of knowledge about deployment options
The development of cloud based applications may be difficult, specially during deployment, where developers need to be aware of the options offered by each cloud vendor in order to achieve the desired quality attributes and evaluate the restrictions cloud providers impose.
When an application is deployed in a cloud-based environment, the architect should take into account how the cloud computing paradigm works, and how to achieve the non-functional requirements. Fulfilling those requirements in a cloud environment is not as easy as deploying your application in a virtual machine on a cloud provider.
To successfully deploy an application in a cloud environment and take full ad-vantage of the desired benefits, the application architecture should be designed or re-designed taking into account certain concerns around cloud deployment. In order to re-design the application the architect must have in mind the non-functional requirements and how to achieve them.
By default, cloud paradigm is supposed to be very dynamic, this implies e.g. fre-quently machines will be turned on and off, and the architect needs to know how to handle this with different strategies, like designing an stateless application, giving more responsibility to the client-side, among others.
Besides each cloud provider have his own services and different ways enable users to deploy applications, in most cases the architect will need to deal with: secu-rity groups, choose an OS with different versions, plugins, DNS, network, among others.
In addition after the provisioning process the architect or developer needs to con-figure the production environment with the required libraries through a command prompt or wizard depending on the selected operating system.
3.3 On premise Vs Cloud
In an on-premise installation is assumed that all the quality scenarios are suc-cessfully achieved, but business interests or a modernization plan could enforce a migration process to a cloud environment.
Having this in mind, an on-premise installation requires hardware and a physical location to install it, therefore the company needs to acquire those assets. To purchase the hardware the company needs to create an hardware over-dimension process thinking in the future growth of the application. This overhead is trans-lated in more expenses that does not generate revenue to the company.
Problem statement 13
In addition, having in mind that, JEE applications requires a large amount of computational resources, as the applications gets bigger it will require more re-sources in order to achieve the initial quality scenarios. The easiest way to support more users in an on-premise installation is acquiring more computational units, considering the overhead variable, that again is translated into more costs to the company.
The worst case could be if the application is designed to support a determined number of users and the demand of users increases in a unexpectedly way making the application crash or degrade its services. As a result, many users will not be able to use the application which is translated into a decreasing revenue.
In addition, it is known that a JEE deployment in a cloud platform is not an easy task, and not all cloud providers supports EJB’s, making this a high restriction that forces the organization to use only some providers that usually are the most expensive in the market.
4
State of the art
Some of the cloud computing problems were mentioned in section 3. These problems have been researched at many projects using different approaches and scopes. These works are related to: cloud portability, elasticity requirements, monitoring cloud applications and servers, cloud deployments, among others. At the same time, these problems could be solved from the perspective of the Infrastructure as a Service or from the Platform as a Service approach as follows.
Field Name QS
Description
Reference
Architectures Deployment Test Monitoring
Academic
Sybl+Mela X X
Kevoree X X
ModaCloud X X X
Cloud Platforms: X
MADCAT X X X
Towards. X X
ROAR X X X X
Migration to PaaS Clouds X
STREAM-AP X X
Industry Cloud 66 X
Codeship X X
Table 4.1 Comparative table with different approaches
4.1 IaaS approaches
Moldovan et al.[MCTD13] develop MELA, a framework that enables developers and providers to analyze different metrics about cloud services multi-elasticity. The multi-elasticity could be represented into three dimensions: resource elastic-ity, cost elasticity and quality elasticity. MELAalso enables monitoring services for the application and the infrastructure where the application is deployed. Additionally, this framework provides real time elasticity analysis about cloud services behavior. This work let the architect know how to monitor and evaluate cloud services’ elastic behavior, defining the proper cost and quality indicators and, therefore, their boundaries. Consequently, the architect can use this indica-tors for optimizing and controlling the services’ elasticity.
16 4.1. IaaS approaches
Another similar approach has been build by Copil et al.[CMTD13] while adding a Domain Specific Language (DSL) to MELA. This DSL is called SYBL. The project has the same functionality as MELA, but enriched with SYBL, which enables developers or providers to specify elasticity requirements in all three di-mensions monitored by MELA. This requirements are used to add or remove resources to the cloud services.
The difference between these two projects and our approach is that SYBIL and
MELA only provide the elasticity requirements and services monitoring specifi-cation . In contrast, we enable architects, who do not have further knowledge about cloud computing, to migrate JEE applications into a micro-service oriented architecture and deploy it in the cloud. The deployment process starts with the JEE monolith application. Hence, we let the architect to divide the application in small parts, based mainly in the architect knowledge. Moreover, we enable the architect to deploy his JEE application in a cloud provider.
Dingel et al. developedROAR (Resource Optimization, Allocation and Rec-ommendation System [SWE14], a model-based approach that addresses to solve different cloud computing problems. These problems are focused on answering how to select the best cost-effective resources’ configuration for a specific appli-cation, and also to fulfill quality of service requirements. To achieve the previous problem, experimentation is needed as load testing over a variety of resources’ configurations.
By consequence, the architect needs to deploy the application in different re-sources’ configurations and execute load testing over those configurations. Af-terwards, he should evaluate which configurations guaranteed the compliance of QoS requirements. If there is a need to determine which is the best cost-effective option, it is necessary to develop a resource optimization engine that meets the target QoS, and also gets the best cost-effective configuration.
Roar allows the architects to make a high level application description and to specify the Quality of Service requirements through a domain specific language calledGROWL. This DSL makes an abstraction of the QoS requirements and the load testing needed.GROWLtransforms the high level load testing plan and the QoS into an XML file that is compatible with JMeter to execute the it. The QoS supported by ROAR are response time andthroughput. To execute the test and know the performance of the application, they have developed a JMeter plug-in that allows them to correlate the metrics of the target server with the test data, in order to verify the compliance of QoS. In addition, ROAR uses an analysis model that identifies correlation between the QoS and the different resources’ configurations. This task supports the application deploying using a deployment template. In the particular AWS case, Cloud Formation Template, this service makes easier the deployment using different resources’ configurations.
The approach given by ROAR is different from our proposal, because his in-put is a domain specific language with the definition of quality attributes for a determined application. Our approach receives the source code of the JEE ap-plication. Furthermore our proposal is focused in enabling architects to migrate from a monolith architecture shown in figure 2.1 to a micro-service oriented ar-chitecture. Additionally our approach let architects to make decisions about how he or she wants to divide the initial (monolith) application to get small parts. In addition we let architects or developers to deploy his application in a IaaS or PaaS provider not only using a IaaS like ROAR.
State of the art 17
ModaClouds is a project developed by Ardagna et al. [AdNM+12] focused in the lock-in problem when you decide to deploy on the cloud. The lock-in provider problem is present in IaaS, PaaS and SaaS, which means that there does not exist a mechanism that let you move from one provider to another in a maintainable way. ModaClouds is using Model Driven Development (MDD) to describe the design of the system and automatically creates interfaces and connectors for application integration. Besides, ModaClouds uses a Decision Support System (DSS) that enables the people to select which cloud provider to choose with the aim of deploying different components. This DSS compares aspects like costs, risk, and quality analysis methods such as CORAS and PREDIQT. The named aspects should conform to two principal quality attributes: Response Time and Availability. Furthermore, ModaClouds has two phases:
• Design phase: the goal of this phase is to describe with high level languages the model driven application design, in order to make the cost an risk analysis using the DSS.
• Run-time phase: the goal in this phase is to achieve the QoS and cost minimization. In addition, you can monitor servers data.
Compared to our approach, ModaClouds is focused on designing software sys-tems for multi-cloud environments. Moreover, it enables the users to favour performance and availability tactics when deploying an applications. Our objec-tive is centered on empowering the architect to define a different architecture in order to achieve better scalability, costs and a JEE deployed in the cloud.
4.2 PaaS approaches
Nogueira et al. research [NdSGdSLPdMF13] is focused on promoting the PaaS portability; e.g. that when you "sign" a contract with a PaaS provider, you could migrate your application and its data to another provider without any problem and with any significant time lose. In other words, this process brakes the cloud computing lock-in provider problem.
The way Nogueira et al. solve this problem is by allowing architects and develop-ers to describe their applications through a domain specific language. They use MDE to remove the relationship between the application logic, and the platform or provider details. This enables the standardization of the application and leaves the lock-in problem. Finally, they developed some test to verify the conformance between the generated application code and the specific platform requirements. The main difference between our work and the work of Nogueira et al. is that we focus in the software architecture and the cloud deployment of a JEE ap-plication. In terms of the architecture we propose a migration from a monolith application to a micro-service oriented architecture that is conform to the single responsibility principle [Mar09] in order to divide the application and deployed in different hardware each micro-service.
4.3 IaaS and PaaS approaches
Daubert et al. developed Kevoree [DFB+12], a run-time model oriented frame-work that enables cloud dynamic resources adaptation. This approach gives the
18 4.3. IaaS and PaaS approaches
developers an abstraction model that makes easier the manipulation and de-scription of a topology. This manipulation is achieved using a domain specific modelling language, KMF (Kevoree Modeling Framework), and its run-time to manipulate business process adaptation. The implication of this procedure is that the framework allows adaptation composition and coordination and infras-tructure adaptation.
Moreover,Kevoree can be extended to support web services orchestrations vari-ability modeling and QoS analysis. This framework lets developers or architects describe their infrastructure topology, which supposes the introduction of Nodes, Channels, Groups and Components.
The defined interaction implies that the architect must have special background in topics related to infrastructure, cloud computing and distributed systems, due to the need of describing a topology in terms of the named semantic elements. Additionally, this framework, does not allow to modernize and re-architect the application. In the same way,Kevoreeis focused in infrastructure, so it manages all the themes related to the infrastructure in which the applications run, but not in how to deploy that application.
Sodhi et al. [SP12] expose that you cannot make a software architecture with-out having in mind the environment in which that application will be deployed. In the particular case of cloud computing, you have to worry about the deploy-ment and the implications that the deploydeploy-ment has in your quality attributes. This means that if you deploy a monolith application in a cloud computing envi-ronment, it does not necessarily mean that you are going to have automatically a scalable application or this deployment it is going to be expensive. Scalability has to be considered in terms of application design by making use of some archi-tectural tactics and design patterns. This work is related to three major quality attributes: Reliability,Performance and Security.
In our approach, we focus in the application architecture. We know the impor-tance of the application design when you want to deploy it in a cloud enable environments; you should take advantage of all the benefits that they offer (elas-ticity, scalability, costs, among others). Likewise, we allow the architect to re-architect the application in a micro-service oriented re-architecture. As well, we take micro-services and we deploy in a cloud environment. This help us to improve deployment process.
Bergmayr et al. [BBCI+13] developed a work called ARTIST. This project have developed a migration method and a comprehensive tool suite.
This project rise to help enterprises to move from a software as a product strategy to deliver software as a service hosted in a cloud environment.
Moreover, it is clear that software modernization is a big challenge, especially when the modernization implies a paradigm shift. ARTIST work in change the way software is delivered, by this reason, they are focused in two main topics: how software is modernized and business aspects like: how is going to be delivered and sold the software.
Additionally ARTIST implements his solution based on MDE to automate the reverse engineering process of legacy software and forward engineering in order to create a cloud-based software. The wayARTIST works is based on something calledModel Driven Modernization (MDM), this is used to discover models in a reverse engineering step to create comprehensive views about the legacy software. Then is executed a forward engineering process until the software satisfies the
State of the art 19
modernization requirements, in order to obtain a platform independent model (PIM). Finally, based on the previous PIM, it is generated the source code thar realize the migrated software,
5
Case Study
5.1 Marketplace application
The case of study we are going to use is a marketplace application, that consists of four modules that uses the master-detail pattern. The marketplace application contains these entities: Item, Product, Cart and CartMaster. This components are related as shown in figure 5.1.
Each entity has his own responsibilities. Cart, Item, Product and CartMaster exposes CRUD functionalities. In addition, the CartMaster entity is the master module and is the only module that interact with Cart, Item and Product. This application was generated using thecrudmaker [Cru15], that is a MDE crud gen-erator, which creates JEE applications with CRUD functionalities.
Basically, the marketplace application let an user have a shopping cart, that it can purchase items from different products. The user can create, read, update and delete all the products he or she wants and his respective quantities(items). Basically the item entity only makes a match between a product and his quantity.
Having in mind the marketplace application in figure 5.2 it is shown a deploy-ment diagram that shows how a monolith application is deployed. This diagram consists of two instances: one for the database server and the other for the appli-cation server. The database server use a MySQL relational database management system.
This application is composed of 1560 lines of code arranged in 35 folders, with a total number of 77 classes. In addition this project contains 156 methods and a 2.5% of lines duplicated. A full details about the metrics of this project can be find in the figure 5.3
22 5.1. Marketplace application
Figure 5.1 This figure shows a component diagram from the monolith textitmarketplace application.
Figure 5.2 This figure shows a deployment diagram from the monolith textitmarketplace application.
Figure 5.3 This figure shows all the metrics related to the source code of the case study:textitmarketplace.
6
Solution Strategy
The main purpose of this work is to enable software architects to deploy JEE ap-plications in the cloud without being an expert in infrastructure (e.g. operating system, network, security groups, etc). We propose a 9 steps process that let an architect modernise a JEE application, and deploy it on a cloud infrastructure as easy as possible. Each step is going to be explained in detail later in this chapter.
As mentioned in chapter 2, JEE applications usually have a monolith architec-ture in which coexists the user interface, business logic, database access, among others [Kra15]. Having this in mind, we decided to migrate the JEE application to a micro-service oriented architecture.
The first thing we need to do is define how is going to be divided the monolith application, here we can use different strategies like: divide by functional units, divide by use cases, divide by layers, among others. In our approach, we imple-mented the first strategy, divide the monolith by functional units. This decision was made in order to isolate each functional entity, making every micro-service responsible for one functional unit (e.g. Product, Item, Cart or Master).
In addition, if the company needs to create a new micro-service with additional functionality the developers can focus his efforts in creating the new micro-service instead of trying to modify an existing big project that contains all source code of the application.
After spliting the application we have an architecture like showed in figure 7.5. To see more information about the number of LOC’s, number of clases, etc. We have used Sonar as we did in the chatper5 to get the metrics related each micro-service.
Afterwards, we are going to modernise the JEE application using a micro-service architectural style which improves scalability requirements. In addition to the micro-service style we also uses the representational state transfer, well-known as REST. In this process the architect needs to deal with some trade-offs in terms of quality attributes (e.g. response time vs scalability, response time vs resilience, among others). Then we deploy the chosen application in Infrastruc-ture as a Service (IaaS) provider, but it could be easily migrated between cloud providers using containers.
24 6.1. JEE Application
Figure 6.1 This figure shows all the proposed process
The figure 6.1 shows the 9 steps involved in the modernization and deploy-ment of an application in a cloud provider process. This process is not completely automatic, some parts require architect’s intervention in order to make the mod-ernization based on his knowledge and decisions.
6.1 JEE Application
The first step in the modernization process is that the architect gives the source code of the JEE monolith application. It is desirable that the project is a maven project, if not, the architect or developer needs to manually add all the libraries or dependencies that the application requires.
6.2 Cartography model
In this step all the JEE project is analyzed and according to pre-defined heuris-tics, a tool [San15] that creates different architectural views, like components diagrams, layers diagrams, among others. This step lets the architect re-organize his JEE monolith application in functional units or an arbitrary pattern decided by him.
After the discovery process the architect will get two artifacts: the architec-tural views and the source code re-organized. This source code is based on all the modifications the architect made in the previous step.
Solution Strategy 25
6.3 Expose EJB as RESTful web service
In the fourth step, it is necessary the architect’s intervention to explicitly write the required annotations to be able to expose all the desired features via RESTful services. Our approach proposes two different types of annotations: a first type to expose services and a second type to tell that a module requires other module. Below it is explained both types of annotations.
The next group of annotations is used to expose functionalities as RESTful services and let inter-operation with other modules via HTTP. In this group of annotations, we have defined 2 sub-groups: class level annotations an method level annotations.
6.3.1 Class level annotations
All the annotations described below are intended to be written above the class definition, this is why they are calledclass level annotations.
@Service_Class:
this annotation is used to create RESTful wrappers with the desired name as parameter of this annotation. @Service_Class annotation receives a name pa-rameter that could be any string except the restricted words in Java. An example of how to use this annotation is shown below.
@Service_Class(name="ItemService") @Stateless
@LocalBean
public class ItemLogicService implements IItemLogicService{ . . .
}
@Service_Path: this annotation is used to configure the base url for all the defined services inside the class annotated with@Service_Path annotation. This annotation receives a string parameter that is going to be translated as a url pattern. An example of how to use this annotation is shown below.
@Service_Class(name="ItemService") @Service_Path("/Item")
@Stateless @LocalBean
public class ItemLogicService implements IItemLogicService{ . . .
}
@Service_Produces & @Service_Consumes : these annotations are used in order to specify the MIME type that the service is going to receive and the response on each request it attends. There are different types of MIME types,
26 6.3. Expose EJB as RESTful web service
our work supports three: JSON, HTML and XML. An example of how to use this annotation with the three MIME types supported is shown below.
@Service_Class(name="ItemService") @Service_Path("/Item")
@Service_Produces(MediaType.JSON) @Stateless
@LocalBean
public class ItemLogicService implements IItemLogicService{ . . .
}
The example shows how to make a HTML MIME type service response:
@Service_Class(name="ItemService") @Service_Path("/Item")
@Service_Produces(MediaType.HTML) @Stateless
@LocalBean
public class ItemLogicService implements IItemLogicService{ . . .
}
The example shows how to make a XML MIME type service response:
@Service_Class(name="ItemService") @Service_Path("/Item")
@Service_Produces(MediaType.XML) @Stateless
@LocalBean
public class ItemLogicService implements IItemLogicService{ . . .
}
6.3.2 Method level annotations
This groups of annotations are intended to be used at a method level. The main purpose of this annotations is to expose functionalities as a RESTful services, enabling inter-operation through HTTP requests.
@Service: this annotation was designed to let the architect or developer define the name of the method that is going to be declared in the RESTful wrapper. An example of how to use this annotation is shown below. In this example we create a method with the namecreateItem in the wrapper class.
@Service_Method(HttpMethod.POST) @Service(name="createItem")
public ItemDTO createItem(ItemDTO item){ . . .
Solution Strategy 27
@Service_Method: this annotation is defined to specify the HTTP method used to access the service that is going to expose the method below the anno-tation. The parameter for this annotation is a custom enumeration defined by us (HttpMethod), the possible value for this parameter are: GET, POST, PUT, DELETE and OPTIONS. An example of how to use this annotation is shown below. This example shows how to declare an HTTP POST service:
@Service(name="createItem") @Service_Method(HttpMethod.POST)
public ItemDTO createItem(ItemDTO item){ . . .
}
This example shows how to declare an HTTP GET service:
@Service(name="getItem")
@Service_Method(HttpMethod.GET)
public ItemDTO getItem(Long id){
return persistance.getItem(id); }
This example shows how to declare a HTTP PUT service:
@Service(name="updateItem") @Service_Method(HttpMethod.PUT)
public void updateItem(ItemDTO item){ . . .
}
This example shows how to declare an HTTP DELETE service:
@Service(name="deleteItem")
@Service_Method(HttpMethod.DELETE)
public void deleteItem(Long id){ . . .
}
This example shows how to declare an HTTP OPTIONS service:
@Service(name="createItemOptions") @Service_Method(HttpMethod.OPTIONS)
public ItemDTO createItem(ItemDTO item){ . . .
}
@Service_Param: this annotation is used to specify when a service requires information from a parameter. In this annotation we have two attributes: type and name. Type is expected to receive a class instance from a simple or complex data type. On the other hand,name corresponds to the name of the parameter, this is a chain of characters with the only restriction that Java words can not be used. An example of how to use this annotation is shown below.
28 6.3. Expose EJB as RESTful web service
@Service_Method(HttpMethod.POST)
@Service_Param(type=ItemDTO.class,name="item")
public ItemDTO createItem(ItemDTO item){ . . .
}
@Service_Return: this annotation represents the type of answer the service is going to return. This annotation value could be any simple or complex data type. An example of how to use this annotation is shown below.
@Service_Method(HttpMethod.GET) @Service_Return(List.class)
public List<ItemDTO> getItems(){
return persistance.getItems(); }
@Service_Path_Param: this annotation is used to specify if a service must receive a parameter from the service url. This annotation is not mandatory. Similar to@Service_Param annotation this one receives two parameters: name and type. An example of how to use this annotation is shown below.
@Service(name="getItem")
@Service_Method(HttpMethod.GET) @Service_Return(ItemDTO.class)
@Service_Path_Param(name="id",type=Long.class)
public ItemDTO getItem(Long id){
return persistance.getItem(id); }
@Service_Path: this annotation was described previously in the class level annotations, at the method level we have the @Service_Path annotations that works in the same way in both cases (class and method level). An example of how to use this annotation is shown below.
@Service(name="getItem")
@Service_Method(HttpMethod.GET) @Service_Return(List.class) @Service_Path("/Item")
public List<ItemDTO> getItems(){
return persistance.getItems(); }
6.3.3 Communication between modules
This group of annotations was defined having in mind a distributed deployment in which every modules is deployed in different instances or machines. In conse-quence, all the communication was made with dependencies injection.
Solution Strategy 29
made through dependency injection, in our distributed architecture, all the com-munication between modules are going to be executed via RESTful requests. To make this process easy to the architect or developer, we have defined the next annotations to let the expert define those HTTP request.
@Require: this annotation was designed to let the developer or architect re-place the injection dependencies calls between modules to an HTTP requests be-tween modules. The parameters this annotation needs are: host, path, method and injection name. The host corresponds to the server name or the ip where the required module is deployed, the path attribute defines the route where the desired function is allocated. The method attribute is used to define the required service HTTP method and the injection name is used to replace the injection dependency with an HTTP request with the previous parameters.
@Requires this annotation is used to describe a list of @Require annotations. This annotation type is very useful when a single method contains different in-jection dependencies to distinct modules.
Example: @Requires and @Require An example of how to use the previous annotations is shown below.
@Requires( {
@Require(host="http://localhost:8080/",path="Cart/webresources/Cart/", method=HttpMethod.GET, injectionName = "Cart"),
@Require(host="http://localhost:8080/",path="Item/webresources/Item/", method=HttpMethod.GET, injectionName = "Item")
})
public void getWithoutReturn(){ cart.getCart();
item.getItem(); }
6.4 Cartography model annotated
The fifth step receives a project with the custom annotations we have defined in the previous section. In this step, the idea is to re-discover the model of the source code. This model we have discovered is conform to a Java meta-model, this discovery process is made usingMoDisco framework.
This framework receives a Java project and then this project is passed to Modisco that is going to generates a model that represents the source code. In this ap-proach we have developed an Eclipse plugin, that uses a package-explorer menu command that uses MoDisco framework in order to generate the .xmi file with the model contents.
30 6.5. Reorganized and annotated code with wrappers
Figure 6.2 Thie figure above shows the java parser and the model to text (M2T) transformation
6.5 Reorganized and annotated code with wrappers
This step is designed to automatize the RESTful wrappers generation according to the annotations defined in the fourth step. This step has two components as shown in the figure 6.2: a Model to Text (M2T) transformation and a Java parser.
6.5.1 Model to text (M2T) transformation
This transformation is intended to work with a model that conforms to a Java metamodel as input, and the output of this transformation is a Java wrapper class. The output is expected to transform all the custom annotations that we already explain in the fourth step. Basically this wrappers let a JEE application that was not designed as a service-oriented application to be able to communicate with other modules via HTTP requests.
This wrapper is generated according to JAX-RS specification. Each generated wrapper contains one attribute annotated with @Inject that references the Ses-sion Bean where the custom annotations were found.
Each desired method annotated by the architect or developer will generate one method in this wrappers that represents the service. Each body method inside the wrapper will have a line that makes the communication via dependencies injection through the service layer with the logic layer (Session Annoted Bean).
The wrapper class created using the model to text transformation is shown ahead:
package src.main.java.logic.ItemLogicService.java;
/**
* Created by . */
@Path("/Item") @Stateless
@Produces(MediaType.APPLICATION_JSON) @Consumes(MediaType.APPLICATION_JSON)
public class ItemService {
@Inject
Solution Strategy 31
@POST
public ItemDTO createItem(ItemDTO item) {
return itemLogicService.createItem(item); }
@GET
public List getItems() {
return itemLogicService.getItems(); }
@GET
public ItemDTO getItem(@PathParam(id) Long id) {
return itemLogicService.getItem(id); }
@DELETE
public void deleteItem(@PathParam(id) Long id) { itemLogicService.deleteItem(id);
}
@PUT
public void updateItem(@PathParam(ItemDTO item) { itemLogicService.updateItem(item);
} }
6.5.2 Java parser
This parser was designed to transform all the communication between modules
annotations like: @Require and @Requires. The parser reads the desired session beans and indentify all the communication between modules through injection annotations: @Inject and @EJB. It also identifies those annotations and keep them in memory in order to start reading line per line if the parser finds a @Re-quires annotation.
Then the process finds the @Require annotation and all its attributes. This at-tributes are going to be translated as HTTP Request.
The parser will add and comment code. If the parser finds a usage of an attribute annotated with@Inject or@EJB, the line where is used this attribute is going to be commented and below this line is going to be added the lines of code needed to call the module that is going to be deployed in other machine. An example of what the parser generates is shown below.
32 6.5. Reorganized and annotated code with wrappers
The original code for this example was:
package co.edu.uniandes.examples;
import javax.ejb.LocalBean;
import javax.ejb.Stateless;
import javax.inject.Inject;
import co.edu.uniandes.annotations.enums.HttpMethod;
import co.edu.uniandes.annotations.require.Require;
import co.edu.uniandes.annotations.require.Requires;
@Stateless @LocalBean
public class Example {
@Inject
private ItemLogicService item;
@Requires( {
@Require(host="http://localhost:8080/",path="Item/webresources/Cart/", method=HttpMethod.GET, injectionName = "ItemLogicService")
})
public void getItems(){ item.getItems(); }
Solution Strategy 33
After processing the Session Beans with the parser the developer or architect could see that all the invocations to other modules inside an annotated methods were commented. In addition, below the commented line of code a few lines are added in order to consume those services through an HTTP requests. The code will looks like this after the parser processing process:
package co.edu.uniandes.examples; import javax.ws.rs.client.Client; import javax.ws.rs.client.ClientBuilder; import javax.ws.rs.client.Entity; import javax.ws.rs.client.WebTarget; import javax.ws.rs.core.MediaType; import javax.ws.rs.core.Response; import javax.ejb.LocalBean; import javax.ejb.Stateless; import javax.inject.Inject; import co.edu.uniandes.annotations.enums.HttpMethod; import co.edu.uniandes.annotations.require.Require; import co.edu.uniandes.annotations.require.Requires; @Stateless @LocalBean
public class Example {
@Inject
private ItemLogicService item;
@Requires( {
@Require(host="http://localhost:8080/",path="Item/webresources/Cart/", method=HttpMethod.GET, injectionName = "ItemLogicService")
})
public void getItems(){ //item.getItems();
Client clientItemLogicService = ClientBuilder.newClient(); WebTarget targetItemLogicService =
clientItemLogicService.target("http://localhost:8080/") .path("Item/webresources/Cart/");
Response returnRestItemLogicService=targetItemLogicService .request(MediaType.APPLICATION_JSON).get();
} }
6.6 Compiled code
As you can see we have made many modifications to the source code. Virtue of in this seventh step, it is necessary that the developer compiles all the source project that contains the different annotations and modifications in order to deploy the application in a public cloud computing environment in the next steps.