IAETSD JOURNAL FOR ADVANCED RESEARCH IN APPLIED SCIENCES, VOLUME 4, ISSUE 1, JAN-JUNE /2017

ISSN (ONLINE): 2394-8442

TOWARDS THE COMPREHENSION AND DEVELOPMENT OF

MONOLITHIC APPLICATIONS AS MICROSERVICES
Mr. Shivarajakumar N Madar [1], Mrs. Priya D [2]
[1, 2]
Department of Information Science & Engg., RVCE, VTU, Bengaluru, India
1
shivaraj.kademani35@gmail.com, 2priyad@rvce.edu.in

ABSTRACT.

These days, software advancement teams confront the challenge of support and
advancement of huge applications. This is called as modernization and involves a procedure of comprehension
the existing approach, and a procedure of changing from the existing monolithic approach to micro service
approach. The micro service approach is another framework to develop applications by functional
decomposition of large application into small applications with bounded context and gathering of all small
applications that commune with each to other. It is winding up plainly progressively famous in light of the fact
that it can quicken deployment, the agile software development, operational practices. For this reason, many
cloud product providers are relied upon to have an expanding number of micro services that can create critical
resource load on the cloud framework. This article presents a way to deal with modernize inheritance
applications as micro services.

Keywords Microservices, Modernization, Monoliths, JEE, REST API

I. INTRODUCTION
This Software will be in steady change, not exclusively to bolster the ever-changing prerequisites of clients additionally to adjust to the changes
in innovation. This kind of adaptation is Modernization; this comprises of two stages:

1) Understanding the current and existing framework

2) Transforming from existing state to current state

The method for comprehension and changing relies on upon the source technology and target technology. For our situation, the source given
as monolithic application, and target is a system that offers a similar business esteem that the monolithic system but utilizing a microservice
approach [1]. A monolithic application does numerous things and has numerous responsibilities. In Monolithic, approach entire functionality of
application has been comprised in a single jar file or war file or ear file [2]. Because of this Applications of monolithic approach are commonly
difficult for frequent deployment, difficult to maintain and upgrade, and hard to understand. In spite of the fact that not every application of the
monolithic approach has these issues, the reasons applications have a tendency to be connected to quick changes in technology. This monolithic
approach has an impediment in size and complexity.

Application of monolithic approach is large and it is complex to completely comprehend and rolled out changes quick and correctly. The
application of monolithic approach may slow down start-up time. We should redeploy the completely comprised application on each update.
Impact of a change is normally not comprehended which prompts do broad manual testing. Frequent deployment is difficult. Another issue with
applications of monolithic approach is reliability [3]. The thought is to splitting up of large application into set of small applications,
interconnected services as opposed to building a single large monolithic application. Every microservice is a small application that is responsible
for doing one thing independently. Some microservices expose a REST API, RPC or message-based API and most of the services expend APIs
given by different services. Microservice approach handles the issue of complexity by splitting large application into small of reasonable
services which are considerably quicker to develop, and substantially simpler to comprehend and maintain [4]. It empowers each microservice
developed autonomously by team that is centred on that service. It decreases hindrance of adopting new technologies since the designers are
allowed to pick whatever technologies bode well for their applications and not limited to the decisions made toward the begin of the project.
Micro service architecture empowers every Microservice to be deployed autonomously. Hence, Microservice makes continuous deployment
feasible for complex applications. Microservice architecture empowers each Microservice to be scaled autonomously.

To Cite This Article: Mr. Shivarajakumar N Madar and Mrs. Priya D,.Towards The Comprehension
And Development Of Monolithic Applications As Micro services. Journal for Advanced Research
in Applied Sciences ;Pages: 377-380
378. Mr. Shivarajakumar N Madar and Mrs. Priya D,.Towards The Comprehension And Development Of Monolithic
Applications As Micro services. Journal for Advanced Research in Applied Sciences; Pages: 377-380

II. PROBLEM STATEMENT

JEE is usually utilized as a part of enterprise applications. JEE, architecture has the accompanying three layers: Presentation layer, business
logic layer, and persistence or database layer.

The Presentation layer represents front-end of the framework. It exchanges the client request to the Business logic layer for processing
and it retrieves the outcome from Business logic layer and shows the result on the screen. Usually this presentation layer is developed
utilizing Java Server Pages (JSP) [5], Java Server Faces (JSF) or plain servlets.
The business logic layer houses all the significant data processing functionality of the framework. This Layer interconnects the UI or
Presentation layer with the Database or Persistence layer. The Business logic layer fetches the outcomes and sends them to the client.
This Layer contains the application logic encapsulated in various Enterprise Java Beans (EJB): session [6], message, oversaw, and
substance beans. In this approach, we will concentrate just in the utilization of session beans and entity beans. Session beans constitute
the business logic layer and offers service while entity beans represent table in database and are the extension to the database or
persistence layer.

The Persistence layer gives the abstraction for database access and thus isolates it from other layers [7]. This assignment is typically
done by a Java Persistence API (JPA) execution

Consider a scenario as if we have Built an application using monolithic approach and deployed the application in system and everything is
working fine. If slight tiny change in business logic, then everything is packaged up all over again. If slight tiny change in database or
Persistence layer [7], then everything is packaged up all over again. If slight tiny change in Presentation layer, then everything is packaged up all
over again. Application of monolithic architecture is complex, scalability is difficult, difficult to maintain, and minor change will affect the
entire system. The application of monolith architecture tied with one technology and change of technology is very difficult in monolithic
architectural style.

III. SOLUTION
All EAR file has multiple WAR files and WAR file is bunch of rest endpoints. We extract WAR file and put it outside as independent
microservie. In addition, each microservice has its own cache and database and each microservice can scale independently. The Below figure
depicts about towards microservices.

Figure 1: Transformation of monolith to microservice

Consider a monolithic application like Java EE application that is ordinarily defined as an EAR or a WAR archive. The whole functionality of the
application is comprised in a single archive file. For instance, web based shopping cart may comprise of User [8], Catalog, and Order
functionalities. All the website pages are in root of the application, all the corresponding java classes are in web-inf/classes directory, and all
resources are in the web-inf/classes/ metainf directory.

Figure 2: Monolithic architecture

379. Mr. Shivarajakumar N Madar and Mrs. Priya D,.Towards The Comprehension And Development Of Monolithic
Applications As Micro services. Journal for Advanced Research in Applied Sciences; Pages: 377-380

Such an application can be refactored into microservices, which would make an architecture that would resemble the accompanying:

Figure 3: Refactoring of monolith to microservices

The functional decomposition of an application into User, Order, and Catalog components are bundled as partitioned WAR files. Each WAR
archive file has the relevant website pages, classes, and configuration files required for that component. Java EE is utilized to execute each
component, but there is no long haul sense of commitment to the stack, as various components talk with each other utilizing API. Distinctive
classes in this component belongs to a same domain, so the code is simpler to write and easier to maintain. Each archive file has its own
database. This enables each microservice to develop and pick whatever kind of data store- NoSQL, relational, in-memory, flat file, or something
else is most appropriate.

Every component registers with a Service Registry. This is required in light of the fact that multiple stateless instances of each microservice
may keep running at a given time, and their exact endpoint locations will be known only at the runtime. Netflix Eureka, Kubernetes, Zookeeper
and etcd are a few options to implement a service registry/discovery. If all components need to talk with each other, then they would do as such
utilizing a predefined API. REST for synchronous or Pub/Sub for asynchronous communication is the most widely recognized intends to
accomplish this. For this situation, the Order component finds User and Catalog service and talks with them utilizing a REST API.

Client interactions for the Application are defined in another Application (for this situation, the Shopping Cart UI). Application finds the
services from the Service Registry and forms them together. A run of the mill look and feel can be proficient by giving standard JavaScript/CSS
resources.

There are various Design patterns in order to make the application with micro service.

A. Aggregator pattern:

Functional decomposition of entire application into three services service A, service B and service C. Each service has its own cache and
database layer and each service can scale independently on its own. Client talks to an aggregator and aggregator internally calling to three
microservices separately, composing the result, and then returning the result back to the client. Aggregator can scale by itself.

Figure 4: Aggregator pattern

380. Mr. Shivarajakumar N Madar and Mrs. Priya D,.Towards The Comprehension And Development Of Monolithic
Applications As Micro services. Journal for Advanced Research in Applied Sciences; Pages: 377-380

B. Proxy pattern:

Functional decomposition of entire application into three services service A, service B and service C. Each service has its own cache and
database layer and each service can scale independently on its own. Proxy can scale by itself. When the Proxy receives the request from client,
proxy does some internal data transformation and proxy internally calling to three microservices separately, composing the result, and then
returning the result back to the client.

Figure 5: Proxy pattern

C. Chained Pattern:

Functional decomposition of entire application into three services service A service B and service C. Each service has its own cache and
database layer and Each service can scale independently on its own. Client will make a call to service A, service A calls to service B and service
B calls to service C. And Response will come from service C to service B, service B to service A and service A to Client.

Figure 6: Chained pattern

IV. CONCLUSIONS
In this article we have presented an approach to handle the Challenges of modernization of legacy JEE applications using a microservice
approach. Such challenges refer to the partition of the application into microservices. The microservice approach has well known benefits and
can positively help business evolve faster. Consider the operational requirements of microservices in addition to the advantages before
refactoring application of monolith to micro services.

REFERENCES

[1] J. Thones, Microservices. Software IEEE, vol. 24, no. 3, pp. 116-116, 2015.
[2] L. Krause, Microservices: Patterns and Applications: Designing fine-grained services by applying patterns., 1st ed., June 2015.
[3] S. Newman, Building Microservices, 1st ed., M. Loukides and B. Mac-Donald, Eds. OReilly Media, Inc., February 2015.
[4] J. I. Fernndez-Villamor, C. Iglesias, and M. Garijo, "Microservices:Lightweight service descriptions for REST architectural style," in
Proc. 2nd Int. Conf. Agents Artif Intell, 2010, pp.186-189.
[5] R. C. Martin. (2009, November) The single responsibility principle. [Online]. Available:
http://programmer.97things.oreilly.com/wiki/index.php/The Single Responsibility Principle.
[6] Microservices Patterns, [online] Available: http://microservices.io/patterns/.
[7] M. Fowler, Microservices. ThoughtWorks. http://martinfowler.com/articles/microservices.html
[8] S. Tonse, Microservices at Netflix, [online] Available: http://www.slideshare.net/stonse/microservices-at-netflix.