Conference PaperPDF Available

A Simplified Database Pattern for the Microservice Architecture

Authors:

Abstract and Figures

Microservice architectures are used as alternative to monolithic applications because they are simpler to scale and more flexible. Microservices require a careful design because each service component should be simple and easy to develop. In this paper, a new microservice pattern is proposed: a database that can be considered a microservice by itself. We named this new pattern as The Database is the Service. The proposed simplified database pattern has been tested by adding ebXML registry capabilities to a noSQL database.
Content may be subject to copyright.
A Simplified Database Pattern for the
Microservice Architecture
Antonio Messina, Riccardo Rizzo, Pietro Storniolo, Alfonso Urso
ICAR - CNR
Palermo, Italy
Email: {messina, ricrizzo, storniolo, urso}@pa.icar.cnr.it
Abstract—Microservice architectures are used as alternative to
monolithic applications because they are simpler to scale and
more flexible. Microservices require a careful design because each
service component should be simple and easy to develop. In this
paper, a new microservice pattern is proposed: a database that
can be considered a microservice by itself. We named this new
pattern as The Database is the Service. The proposed simplified
database pattern has been tested by adding ebXML registry
capabilities to a noSQL database.
Keywordsmicroservices, scalable applications, continuous de-
livery, microservices patterns, noSQL, database
I. INTRODUCTION
The microservice architectural style [1] is a recent approach
to build applications as suite of services, independently de-
ployable, implementable in different programming languages,
scalable and manageable by different teams.
Microservices architectures are opposed to monolithic ap-
plications. Monolithic applications are simpler to build and to
deploy, but their structure forces the developers to work in
team. Working in team the developers tends to deploy large
applications that are difficult to understand and to modify.
Moreover, if a required service is implemented by a single
application, the transactions volume can be increased only by
running multiple copies of the same application, that has to
access to the same database.
On the other side, developing a system based on microser-
vices requires a special attention because it is a distributed
system. In this case, even the team of developers can be
distributed, it requires a special effort in coordination and
communication.
In microservices based systems, one of the biggest chal-
lenge is the partition into separated services, each of them
should be simple enough to have a small set of responsibilities.
Data management require a special attention, because it can
be one of the bottleneck of the system. So that it is convenient
that only one or few microservices access the data, but this
can affect the responsiveness of the whole system.
When a careful project solves all these issues, microser-
vices became an effective architectural pattern, in fact studies
have shown how this architectural pattern can give benefits
when enterprise applications are deployed in cloud environ-
ments [2] and in containers [3], e.g., Docker [4]. Microservices
are also considered the natural fit for the Machine-to-Machine
(IoT) development [5].
The microservices pattern implies several important auxili-
ary patterns, such as, for example, those which concern how
clients access the services in a microservices architecture, how
clients requests are routed to an available service instance, or
how each service use a database.
In the new microservice pattern proposed in this paper,
a database, under certain circumstances and thanks to the
integration of some business logic, can be considered a mi-
croservice by itself. It will be labeled as The database is the
service pattern.
The remainder of the paper is organized as follows: Section
2 presents a brief overview about the old monolithic style and
its drawbacks. The microservices architectures and the related
pattern are described in Section 3. Section 4 presents the
proposed pattern. In Section 5, we show a proof of concept of
the pattern and its improved performances. Finally, conclusions
are reported.
II. BACKGROU ND
To better understand the microservice style it is useful to
compare it to the monolithic style: a monolithic application
built as a single unit. Modern enterprise applications are
typically built in three main parts: a client-side user interface,
a server-side application, and a relational database. The server-
side application handles the requests, executes domain logic,
retrieves and updates data from the relational database, and
selects and populates the views to be sent to the client-side.
This server-side application can be defined as monolith, a
single logical executable.
Essentially, a monolith application is the one where all
its functionalities are packaged together as a single unit or
application. This unit could be a JAR, WAR, EAR, or some
other archive format, for which is all integrated in a single unit.
This style of application is well known, because this is how
applications have been built so far, it is easy to conceptualize
and all the code is in one place. The most of existing tools,
application servers, frameworks, scripts are able to deal with
such kind of applications. In particular, IDEs are typically
designed to easily develop, deploy, debug, and profile a single
application. Stepping through the code base is easy because
the codebase is all together.
Finally, a monolith is easy to share, to test and to deploy. A
single archive, with all the functionality, can be shared between
teams and across different stages of deployment pipeline.
Once the application is successfully deployed, all the services,
or features, are up and available. This simplifies testing as
35Copyright (c) IARIA, 2016. ISBN: 978-1-61208-486-2
DBKDA 2016 : The Eighth International Conference on Advances in Databases, Knowledge, and Data Applications
there are no additional dependencies to wait for in order to
begin the test phase. Accessing or testing the application is
simplified in either case. It is easy to deploy since, typically,
a single archive needs to be copied to one directory. The
deployment times could vary but the process is pretty straight
forward. However, a monolithic application, no matter how
modular, will eventually start to break down as the team grows,
experienced developers leave and new ones join, application
scope increases, new ways to access the applications are added,
and so on. Moreover, it has a very limited agility, because
every tiny change to the application means full redeployment
of the archive. This means that developers will have to wait
for the entire application to be deployed if they want to see
the impact of quick change made in their workspace. Even if
not intentional, but this may require tight coupling between
different features of the application. This may not be possible
all the time, especially if multiple developers are working
on the application. This reduces agility of the team and the
frequency by which new features can be delivered. If a single
change to the application would require entire application to
be redeployed, then this could become an obstacle to frequent
deployments, and thus an important obstacle for continuous
delivery.
Choice of technology for such applications are evaluated
and decided before their development starts. Everybody in the
team is required to use the same language, persistence stores,
messaging system, and use similar tools to keep the team
aligned. It is typically not possible to change technology stack
mid stream without throwing away or rewriting significant part
of existing application.
Figure 1. Services provided by horizontally scaled monolithic application
Monoliths can only scale in one dimension, i.e., they have
to be entirely duplicated across a set of servers (see Figure 1).
This way, each application instance will access all of the
data. This makes caching less effective, increases memory
consumption and i/o traffic.
Systems based on microservices present many advantages
if compared to monolithic applications. Some of these ad-
vantages came from their distributed architecture and will be
explained in the next section.
III. MIC ROS ERV IC ES ARCHITECTURE AND RE LATE D
PATTERNS
In the last years, several large Internet companies have used
different mechanisms, strategies and technologies to address
the limitations of the monolithic architecture: they can be
referred as the microservices architecture pattern.
Microservices is a software architectural style that require
functional decomposition of an application. A monolithic
application is broken down into multiple smaller services, each
deployed in its own archive, and then composed as a single
application using standard lightweight communication, such as
REST over HTTP (see Figure 2).
Figure 2. Tipical microservice-based application with lightweight frontend
The decomposition into a set of collaborating services is
usually done applying the Y-axis scaling of the three dimension
scalability model named the Scale Cube [6]:
X-axis scaling: it is the simplest commonly used
approach of scaling an application via horizontal du-
plication, namely running multiple cloned copies of
an application behind a load balancer.
Y-axis scaling: it represents an application’s split by
function, service or resource. Each service is responsi-
ble for one or more closely related functions. We can
use a verb-based decomposition and define services
that implement single use cases, or we can decompose
the application by noun and create services responsible
for all operations related to a particular entity.
Z-axis scaling: it is commonly used to scale databases,
because the data is partitioned across a set of servers.
Each server runs an identical copy of the code and
each service request is routed to the appropriate server
according to a routing criteria.
Basically, the service design should be made by applying
the Single Responsibility Principle [7], that defines a respon-
sibility of a class as a reason to change, and states that a class
should only have one reason to change.
There are several patterns [8] related to the microservices
pattern. We mainly focus our attention on the following:
The API Gateway pattern, that defines how clients
access the services in a microservices architecture.
The Client-side Discovery and Server-side Discovery
patterns, used to route requests for a client to an availa-
ble service instance in a microservices architecture.
The Service Registry pattern, a critical component that
tracks the instances and the locations of the services.
The Database per Service pattern, that describes how
each service has its own database.
36Copyright (c) IARIA, 2016. ISBN: 978-1-61208-486-2
DBKDA 2016 : The Eighth International Conference on Advances in Databases, Knowledge, and Data Applications
A. The API Gateway Pattern
Microservices typically provide fine-grained APIs, which
means that clients need to interact with multiple services.
However, different clients need different data and network per-
formance is different for different types of clients. Moreover,
the number of service instances and their locations (host+port)
changes dynamically and partitioning into services can change
over time and should be hidden from clients.
An API gateway is the single entry point for all clients
and handles requests in one of two ways. Some requests are
simply proxied/routed to the appropriate service. It handles
other requests by fanning out to multiple services. Rather than
provide a one-size-fits-all style API, the API gateway can
expose a different API for each client. It might also implement
security, e.g., verify that the client is authorized to perform the
request. There is a couple of obvious drawbacks, at least:
Increased complexity, due to another moving part that
must be developed, deployed and managed.
Increased response time, due to the additional network
hop through the API gateway. However, for most ap-
plications the cost of an extra roundtrip is insignificant.
B. The Discovery Patterns
In a monolithic application, services invoke one another
through language-level method or procedure calls. In a tra-
ditional distributed system deployment, services run at fixed,
well known locations (hosts and ports) and so they can
easily call each using HTTP/REST or some RPC mechanism.
However, a modern microservice-based application typically
runs in a virtualized or containerized environments where the
number of instances of a service and their locations changes
dynamically. Consequently, the service clients must be enabled
to make requests to a dynamically changing set of transient
service instances.
Client-side: The clients obtain the location of a service
instance by querying a Service Registry, which knows
the locations of all service instances. This implies
fewer moving parts and network hops compared to
Server-side Discovery, but clients are coupled to the
Service Registry and you need to implement a client-
side service discovery logic for each programming
language/framework used by the application (see Fig-
ure 3).
Figure 3. Client-side discovery pattern
Server-Side: When making a request to a service,
the client makes a request via a router (a.k.a. load
balancer) that runs at a well known location. The
router queries a service registry, which might be built
into the router, and forwards the request to an available
service instance. Compared to client-side discovery,
the client code is simpler since it does not have to
deal with discovery. Instead, a client simply makes
a request to the router, but more network hops are
required (see Figure 4).
Figure 4. Server-side discovery pattern
C. The Service Registry Pattern
A service registry is a database of services, their instances
and their locations. Service instances are registered with the
service registry on startup and deregistered on shutdown.
Client of the service and/or routers query the service registry
to find the available instances of a service. Unless the service
registry is built in to the infrastructure, it is yet another
infrastructure component that must be setup, configured and
managed. Moreover, the Service Registry is a critical system
component. Although clients should cache data provided by
the service registry, if the service registry fails that data
will eventually become out of date. Consequently, the service
registry must be highly available.
D. The Database per Service Pattern
According to this pattern, we should keep each microser-
vice’s persistent data private to that service and accessible only
via its API. It means that the service’s database is effectively
part of the implementation of that service and it cannot be
accessed directly by other services. There are a few different
ways to keep a service’s persistent data private:
Private-tables-per-service: each service owns a set of
tables that must only be accessed by that service.
Schema-per-service: each service has a database
schema that is private to that service
Database-server-per-service: each service has its own
database server. When the service has to be scaled,
the database can be also scaled in a database cluster,
no matter the service.
Figure 5. The Database per Service pattern applied to
a scaled service using a database cluster
37Copyright (c) IARIA, 2016. ISBN: 978-1-61208-486-2
DBKDA 2016 : The Eighth International Conference on Advances in Databases, Knowledge, and Data Applications
Figure 5 shows a typical architecture of a scaled
service using its own database cluster.
IV. THE Database is the Service PATTERN
The granular nature of the microservice architectures may
bring many benefits, but also comes with the cost of increased
complexity.
Breaking a monolith into microservices simplifies each
individual component, but the original complexity goes to sur-
face when, at some point, someone has to put it all together [9].
Certainly, there is a sort of law of conservation of complexity
in software and, if we break up big things into small pieces,
then we push the complexity to their interactions [10].
Moreover, IT complexity in enterprise today continues
to grow at a dizzying rate. Technology innovation, vendor
heterogeneity, and business demands are major reasons why
organizations are exposed to new risks, based on the gaps
opened between the options and features of each IT element
and product, and how they are implemented to support a well-
defined policy and company strategy. The impact of such risks
increases exponentially by failing to identify the handshakes
and correlations of interrelated elements. Products, vendors,
and IT layers must work together to prevent potential black
holes: risks related to availability, resiliency and data loss.
It is not hard to understand how microservice architectures
may amplify such risks, because their distributed nature. More-
over, in a monolithic application there was a method call acting
as a subsystem boundary, in the microservice architecture we
now introduce lots of remote procedure calls, REST APIs
or messaging to glue components together across different
processes and servers.
Once we have distributed a system, we have to consider
a whole host of concerns that we didn’t before. Network
latency, fault tolerance, message serialisation, unreliable net-
works, asynchronicity, versioning, varying loads within our
application tiers etc.
Starting from the Database-Server per Service Pattern, the
addition of new behaviors and business logic at the database
level may be a possible approach to reduce complexity, and
thus the related risks, and also to gain improvements in terms
of speed and scalability.
Problem: If each scalable service has its own database
(cluster), as shown in Figure 5, is there any way to reduce the
complexity of the architecture and the related risks, while also
gaining more improvements in terms of speed and scalability?
Solution: Whenever the database has an open architecture
and provides the necessary hooks to extend its capabilities,
then it can embed the business logic that implements the
desired service. The service is strictly coupled to the data,
hence this pattern is even stronger than the Database-Server
per Service Pattern, because the database itself acts as a
business service. As shown in Figure 6, clients requests are
routed via a load balancer, following the guidelines of the
Server-side Discovery Pattern.
Some benefits of such approach are immediately clear at
first sight:
a) the traditional service layer disappears, thanks to the whole
removal of related hosts and application servers or contain-
ers;
Figure 6. The Database is the Service pattern: DBMS with business logic
b) services deployed into the database have instant access to
data, accessible at no cost (no third party libraries, no
network issues, and so on);
c) less the involved components, less the complexity, the
interactions and the potential risks.
If the database cluster layer is also available to clients, i.e.,
thanks to a specific library, we may achieve further simplifica-
tion, because clients requests reach directly the service. Unlike
Client-side Discovery Pattern, there’s no need to implement
a discovery logic into clients, there isn’t any balancer, and
the cluster layer supplies, at least, the same Service Registry
capabilities. Figure 7 shows the way that super-simplified
architecture looks.
Figure 7. The Database is the Service pattern with client-side cluster support
Drawbacks are also obvious, first and foremost the depen-
dency on the chosen database, because the service becomes
integral to, and inseparable from, the database engine. Test and
debug activities must also involve the database because of his
primary role. For this reason, the database source code must
be available, an open source product is the obvious choice.
V. PRO OF O F CO NC EP T
As a proof of concept for the proposed pattern, we have
added ebXML registry capabilities to a noSQL database,
starting from EXPO [19], a prototypal extension for OrientDB
derived from eRIC [20], our previous SQL-based ebXML
registry implemented as web service in Java.
An ebXML registry [15][16] is an open infrastructure
based on XML that allows electronic exchange of business
information in a consistent, secure and interoperable way.
The eXtensible Markup Language (ebXML) is a stan-
dard promoted by the Organization for the Advancement of
Structured Information (OASIS) and was designed to create
38Copyright (c) IARIA, 2016. ISBN: 978-1-61208-486-2
DBKDA 2016 : The Eighth International Conference on Advances in Databases, Knowledge, and Data Applications
a global electronic market place where enterprises of any
size, anywhere, can find each other electronically and conduct
business using exchange of XML messages according to stan-
dard business process sequences and mutually agreed trading
partner protocol agreements.
Nowadays, ebXML concepts and specifications are reused
by the Cross-Enterprise Document Sharing (XDS) architectural
model [17], defined by Integrating the Healthcare Enterprise
(IHE) initiative [18], which is promoted by healthcare profes-
sionals and industries to improve the way computer systems
in healthcare share informations.
In the following subsections, we introduce the noSQL
database engine we have chosen and we briefly illustrate what
we have done and some interesting performances results.
A. Brief overview on OrientDB
OrientDB [11] is an open source NoSQL DBMS developed
in Java by Orient Technologies LTD and distributed under
the Apache 2 license [14]. It collects features of document
databases and graph databases, including object orientation. In
graph mode, referenced relationships are like edges, accessible
as first-class objects with a start vertex, end vertex, and
properties. This interesting feature let us represent a relational
model in document-graph model maintaining the relationships.
OrientDB supports an extended version of SQL, to allow
all sort of CRUD (Create, Read, Update and Delete) and
query operations, and ACID (Atomicity, Consistency, Isolation,
Durability) transactions, helpful to recover pending document
at the time of crash. It is easily embeddable and customizable
and it handles HTTP Requests, RESTful protocols and JSON
without any 3rd party libraries or components. It is also fully
compliant with TinkerPop Blueprints [12], the standard of
graph databases. Finally, his feature can be easily customized
and it supports a multi-master distributed architecture, a 2nd
level shared cache and the other features offered by embedded
Hazelcast [13].
B. A multi-model noSQL DBMS as an ebXML Registry
OrientDB is also a customizable platform to build pow-
erful server component and applications: since it contains
an integrated web server, it is possible to create server side
applications without the need to have a J2EE and Servlet
container. The customizations can be obtained by developing
new Handlers, to build plugins that start when OrientDB starts,
or implementing Custom Commands, the suggested best way
to add custom behaviors or business logic at the server side.
The multi-model nature of the OrientDB engine allows
it to support Object data model, too. This model has been
inherited by Object Oriented programming and supports the
inheritance between types (sub-types extends the super-types),
the polymorphism when you refer to a base class, and the direct
binding from/to objects used in programming languages.
The OrientDB Object Interface works on top of the
Document-Database and works like an Object Database: man-
ages Java objects directly. This makes things easier for the
Java developer, since the binding between Objects to Records
is transparent. In that context, the Objects are referred as
POJOs: Plain Old Java Objects. OrientDB uses Java reflection
and Javassist [21] to bound POJOs to Records directly. Those
proxied instances take care about the synchronization between
a POJO and its underlying record. Every time you invoke a
setter method against the POJO, the value is early bound into
the record. Every time you call a getter method, the value is
retrieved from the record if the POJO’s field value is null. Lazy
loading works in this way too.
The ebXML RIM objects are perfect POJOs, because they
are serializable, have a no-argument constructor, and allow
access to properties using getter and setter methods that follow
a simple naming convention. They are also fully described by
the standard set of Java XML annotation tags because they
need to be transferred over the line properly encapsulated using
the Java Architecture for XML Binding (JAXB) [22]. This
means that we can add new custom properties preceded by
the @XMLTransient tag without breaking things. We have used
those new properties and the related getter and setter methods
to add native OrientDB links between objects, which can be
transparently serialized/deserialized by the OrientDB engine in
their enriched form.
This approach has a great impact on the management of
ebXML objects:
a) they are still used in the standard way within the client-
server SOAP interactions;
b) the binding to the database records is transparent;
c) there is no need of extra data class object (DAO) hierarchy
to manage the persistence;
d) we are able to make full use of the OrientDB capabilities.
An extension of the OrientdDB OServerCommandAbstract
class has replaced the old Java servlet in the registry requests
management. In particular, the execute() method is invoked
at every HTTP request and let us to read the input HTTP
stream and to write into the output HTTP stream. This is the
place where we intercept, elaborate and reply to the incoming
requests, by calling the real ebXML registry layer.
Figure 8. EXPO vs eRIC/PostgreSQL
To verify ebXML specifications compliance and to evaluate
the performances, we have run the same ebXML test suite
developed with the JAebXR API [23] and then we have
compared the results in some different configurations. Figure 8
39Copyright (c) IARIA, 2016. ISBN: 978-1-61208-486-2
DBKDA 2016 : The Eighth International Conference on Advances in Databases, Knowledge, and Data Applications
shows the interesting performance improvements obtained with
EXPO service.
VI. CONCLUSIONS
While monoliths have been the norm for some time,
microservices have emerged as an alternative to deal with
certain limitation in monoliths. However, that doesn’t mean
that monoliths are completely obsolete. Just because others
are gravitating to one more than the other, doesn’t mean that
it’s going to be the best decision. Obviously, it’s important
to look at advantages and disadvantages of each and, as much
information as possible, to make the aware decision. Keep also
in mind that, due to the significant architectural differences, a
direct comparative quantitative analysis is actually not easy to
achieve, but we are working on it.
In this paper, we introduced a new microservice pattern
where the database is the service. The proposed pattern has
been tested adding ebXML registry capabilities to a noSQL
database. Experimental tests have shown improved perfor-
mances of the proposed simplified microservice architecture
compared with SQL-based ebXML registry implemented as
traditional Java web service.
REFERENCES
[1] M. Fowler, ”Microservices, a definition of this new architectural
term”, URL: http://martinfowler.com/articles/microservices.html [ac-
cessed: 2016-02-12].
[2] M. Villamizar, et al., ”Evaluating the monolithic and the microservice
architecture pattern to deploy web applications in the cloud”, ”Computing
Colombian Conference (10CCC), 2015 10th”, 2015, pp. 583–590, DOI:
10.1109/ColumbianCC.2015.7333476.
[3] M. Amaral, et al., ”Performance Evaluation of Microservices Architec-
tures Using Containers”, ”2015 IEEE 14th International Symposium on
Network Computing and Applications (NCA)”, 2015, pp. 27–34, DOI:
10.1109/NCA.2015.49.
[4] Docker Inc., ”Docker, An open platform for distributed applications
for developers and sysadmins”, URL: https://www.docker.com [accessed:
2016-02-12].
[5] D. Namiot and M. Sneps-Sneppe, ”On micro-services architecture”,
”International Journal of Open Information Technologies”, 2014, vol.
2, no. 9, pp. 24–27, ISSN: 2307-8162.
[6] M. Abbott, T. Keeven, and M. Fisher, ”Splitting Applications or Services
for Scale”, URL: http://akfpartners.com/techblog/2008/05/08/splitting-
applications-or-services-for-scale/ [accessed: 2016-02-16].
[7] R. C. Martin, ”Agile Software Development: Principles, Patterns, and
Practices”, Pearson Education, Nov. 2009, ISBN: 978-0-13597-444-5
[8] C. Richardson, ”Microservice architecture patterns and best practices”,
URL: http://microservices.io/index.html [accessed: 2016-02-12].
[9] H. Hammer, ”The Fallacy of Tiny Modules”, URL:
http://hueniverse.com/2014/05/30/the-fallacy-of-tiny-modules/ [accessed:
2016-02-28].
[10] M. Feathers, ”Microservices Until Macro Complexity”, URL:
https://michaelfeathers.silvrback.com/microservices-until-macro-
complexity [accessed: 2016-02-28].
[11] Orient Technologies LTD, ”OrientDB”, URL: http://orientdb.com [ac-
cessed: 2016-02-10].
[12] Apache Software Foundation, ”Apache TinkerPop”, URL:
http://tinkerpop.incubator.apache.org [accessed: 2016-02-11].
[13] Hazelcast Inc., ”Hazelcast, the Operational In-Memory Computing
Platform”, URL: http://hazelcast.com [accessed: 2016-02-10].
[14] Apache Software Foundation, ”Apache License v2.0”, Jan. 2004, URL:
http://www.apache.org/licenses/LICENSE-2.0 [accessed: 2016-02-11].
[15] OASIS ebXML Registry Technical Committee, ”Registry
Information Model (RIM) v3.0”, 2005, URL: http://docs.oasis-
open.org/regrep/regrep-rim/v3.0/regrep-rim-3.0-os.pdf [accessed: 2016-
02-10].
[16] OASIS ebXML Registry Technical Committee, ”Registry Services and
Protocols v3.0”, 2005, URL: http://docs.oasis-open.org/regrep/regrep-
rs/v3.0/regrep-rs-3.0-os.pdf [accessed: 2016-02-10].
[17] R. Noumeir, ”Sharing Medical Records: The XDS Architecture and
Communication Infrastructure”, ”IT Professional”, Sep. 2010, Volume:
13, Issue: 4, ISSN: 1520-9202, DOI: 10.1109/MITP.2010.123.
[18] Integrating the Healthcare Enterprise (IHE), 2010, URL: http://ihe.net
[accessed: 2016-02-17].
[19] A. Messina, P. Storniolo, and A. Urso, ”Keep it simple, fast and scal-
able: a Multi-Model NoSQL DBMS as an (eb)XML-over-SOAP service”,
”The 30th IEEE International Conference on Advanced Information
Networking and Applications (AINA-2016)”, IEEE, in press.
[20] A. Messina and P. Storniolo, ”eRIC v3.2: ebXML Registry by
ICAR CNR”, Technical Report: RT-ICAR-PA-13-03, Dec. 2013, DOI:
10.13140/RG.2.1.2108.9124.
[21] JBoss Javassist, ”Javassist (Java Programming Assistant)”, 2015, URL:
http://jboss-javassist.github.io/javassist/ [accessed: 2016-02-29].
[22] Java Community Process, ”JSR 222: Java Architecture for XML
Binding (JAXB) 2.0”, 2009, URL: https://jcp.org/en/jsr/detail?id=222
[accessed: 2016-02-29].
[23] A. Messina, P. Storniolo, and A. Urso, ”JAebXR: a Java API for
ebXML Registries for Federated Health Information Systems”, ”DBKDA
2015: The Seventh International Conference on Advances in Databases,
Knowledge, and Data Applications”, Rome, Italy, May 2015, pp. 33–39,
ISBN: 978-1-61208-408-4.
40Copyright (c) IARIA, 2016. ISBN: 978-1-61208-486-2
DBKDA 2016 : The Eighth International Conference on Advances in Databases, Knowledge, and Data Applications
... A. Messina et al. proposed and tested a simplified database pattern for microservice architecture where a database is a separate microservice itself [52]. The proposed data persistence pattern was based on four patterns: (1) the API gateway pattern; (2) the clientside discovery and server-side discovery patterns; (3) the service registry pattern; and (4) the database per service pattern. ...
... Multi-model polyglot persistence allows us to better utilize the benefits of microservices such as agility and scalability [10,18,38,39]. The encapsulation of a database into a microservice reduces the complexity and increases the performance [52]. After migration, the data are accessible not only to an existing monolith application but also to any microservice within an ecosystem. ...
Article
Full-text available
Migration from a monolithic architecture to a microservice architecture is a complex challenge, which consists of issues such as microservices identification, code decomposition, commination between microservices, independent deployment, etc. One of the key issues is data storage adaptation to a microservice architecture. A monolithic architecture interacts with a single database, while in microservice architecture, data storage is decentralized, each microservice works independently and has its own private data storage. A viable option to fulfil different microservice persistence requirements is polyglot persistence, which is data storage technology selected according to the characteristics of each microservice need. This research aims to propose and evaluate the approach of monolith database migration into multi-model polyglot persistence based on microservice architecture. The novelty and relevance of the proposed approach are double, that is, it provides a general approach of how to conduct database migration from monolith architecture into a microservice architecture and allows the data model to be transformed into multi-model polyglot persistence. Migration from a mainframe monolith database to a multi-model polyglot persistence was performed as a proof-of-concept for the proposed migration approach. Quality attributes defined in the ISO/IEC 25012:2008 standard were used to evaluate and compare the data quality of the microservice with the multi-model polyglot persistence and the existing monolith mainframe database. Results of the research showed that the proposed approach can be used to conduct data storage migration from a monolith to microservice architecture and improve the quality of the consistency, understandability, availability, and portability attributes. Moreover, we expect that our results could inspire researchers and practitioners toward further work aimed to improve and automate the proposed approach.
... • Database-per-microservice. Each service is self-contained and controls its own private data store [66][67][68]. This increases the scalability of services as the database can be easily scaled in a database cluster when the microservice needs to scale with the load. ...
... In the next chapter, we present the data and workflow management layers with the experiments conducted. 68 Chapter 5 ...
Thesis
We live in a new era of Big Data, the era of insights. While our capacity to collect real-time data has grown significantly over the past decade, our ability to analyze that data to turn it into knowledge has not kept pace. With new generations of devices and network technologies, the focus of Big Data is shifting toward the design of tools and applications able to extract information from collected data. The majority of emerging applications present expectations of near-real-time processing to maintain the validity of their results. However, guaranteeing their performance requirements is hampered by the traditional Cloud system designs and management strategies. Current systems for Big Data applications rely on heterogeneous resources distributed across the constrained Edge and the powerful Cloud. In addition, the applications are now created as a set of self-contained microservices, developed by independent teams following the DevOps practices. This evolution of systems designs has introduced extreme heterogeneity and uncertainty into emerging applications, highlighting the limitations of traditional management strategies.In this thesis, we focus on designing a system for Big Data applications that rethinks existing management strategies with a particular emphasis on the heterogeneity of incoming data, applications, and resources. We first study the decoupling of data producers and consumers in emerging microservice-based applications as the entry point to effectively leverage available services, even newly published ones. Accordingly, we propose a data-driven service discovery framework based on data-centric service descriptions and rely on a Peer-to-Peer data-driven architecture. In addition, we present an adaptation scheme that scales deployed microservices to tackle the impact of fluctuating load on real-time performance. Second, we investigate the trade-off between the quality and urgency of the results in Big Data applications as a promising strategy to overcome the limited and heterogeneous capacity of system resources. In particular, we present a data-driven workflow scheduling approach to distribute microservices across the edge of the network, the core, and along the data path. Additionally, we propose a data adaptation strategy that reduces the quality of incoming data when potential quality-latency trade-off optimizations are available. We then apply the proposed approaches in the context of Deep Learning applications.
... According to [29], it describes the performance problems presented by database management services when executing multiple queries that require the review of large numbers of records, this through HTTP requests. As a result, it shows the difference in efficiency between the microservices architecture and the monolithic architecture, by analyzing the time needed to obtain the response with data for operations with different sizes of records. ...
... X 12 [25] X 13 [26] X 14 [27] X 15 [28] X 16 [29] X X 17 [30] X 18 [31] X X 19 [32] X 20 [33] X Total 3 3 3 4 2 1 3 3 % 13.6% 13.6% 13.6% 18% 9% 5% 13.6% 13.6% ...
... Leveraging the power of existing services can help us escape from the hardcoded model used in monolithic application development which leads to dysfunctional and hard to maintain collections of software modules. Messina et al. (2016) describe a dynamic and flexible model to keep track of all the components using a service registry focusing on consistency during the discovery process while having each part isolated from the outside world. ...
Conference Paper
The last decade marked undeniably the leading role of web services and the establishment of service-oriented architectures. Indeed, it is nowadays hard to find a contemporary software application that does not use at least one third-party web service. The main driver for this paradigm shift, lies in the benefits that decoupled, cloud-based services bring to software development, operation and maintenance as well as at the seamless deployment, integration and scalability features those modern public clouds provide.
... Microservice architectures are used as alternative to monolithic applications because they are simpler to scale and more flexible. Microservices require a careful design because each service component should be simple and easy to develop (Messina et al., 2016). ...
Article
Full-text available
Building a learning system using the Learning Management System is already too much but there are many problems that make people think about using it because it is difficult to maintain the system, so to build a system takes a lot of time because the basis for developing the system is monolith-based and difficult to develop if the system development team grows or change. Learning Management System needs to be implemented for easy access to learning because online learning is very important to be a good alternative. From these problems led to the idea to create a Learning Management System in which it can solve services and communicate between services to facilitate efficient development. This study aims to apply the Web Service Implementation Methodology used in building a Learning Management System for an E-Course that facilitates online learning by implementing web services. To perform inter-service solving the methodology used in making this application is the web service method which is implemented on the microservices architecture. Programming languages for differentiating services are PHP and JavaScript. For the user interface, ReactJS is used as the API data manager for each service and the database uses MySQL. This application will later be used as a medium to facilitate online learning, there are members (users) as student actors and admins to manage mentor and course data that will be displayed.
... Another essential point is to consider that each backend service should have its private database or database table [27]. ...
Article
Full-text available
Geospatial data and related technologies have become an increasingly important aspect of data analysis processes, with their prominent role in most of them. Serverless paradigm have become the most popular and frequently used technology within cloud computing. This paper reviews the serverless paradigm and examines how it could be leveraged for geospatial data processes by using open standards in the geospatial community. We propose a system design and architecture to handle complex geospatial data processing jobs with minimum human intervention and resource consumption using serverless technologies. In order to define and execute workflows in the system, we also propose new models for both workflow and task definitions models. Moreover, the proposed system has new Open Geospatial Consortium (OGC) Application Programming Interface (API) Processes specification-based web services to provide interoperability with other geospatial applications with the anticipation that it will be more commonly used in the future. We implemented the proposed system on one of the public cloud providers as a proof of concept and evaluated it with sample geospatial workflows and cloud architecture best practices.
... Peers and external consumers can find their necessary service instances by invoking the Service Registry, a Viseu module in all the peers. The Viseu service registry is a minimal decentralized implementation of the service registry pattern [27] that consists of a Measurements Client for latency-aware scheduling in each peer. It offers unified access to Viseu blockchain and its overlay network that the peers can leverage as service consumers. ...
Article
Full-text available
Small-scale data centers at the edge are becoming prominent in offering various services to the end-users following the cloud model while avoiding the high latency inherent to the classic cloud environments when accessed from remote Internet regions. However, we should address several challenges to facilitate the end-users finding and consuming the relevant services from the edge at the Internet scale. First, the scale and diversity of the edge hinder seamless access. Second, a framework where researchers openly share their services and data in a secured manner among themselves and with external consumers over the Internet does not exist. Third, the lack of a unified interface and trust across the service providers hinder their interchangeability in composing workflows by chaining the services. Thus, creating a workflow from the services deployed on the various edge nodes is presently impractical. This paper designs Viseu, a latency-aware blockchain framework to provide Virtual Internet Services at the Edge. Viseu aims to solve the puzzle of network service discovery at the edge, considering the peers’ reputation and latency when choosing the service instances. Viseu enables peers to share their computational resources, services, and data among each other in an untrusted environment, rather than relying on a set of trusted service providers. By composing workflows from the peers’ services, rather than confining them to the pre-established service provider and consumer roles, Viseu aims to facilitate scientific collaboration across the peers natively. Furthermore, by offering services from multiple peers close to the end-users, Viseu also minimizes end-to-end latency and data loss in the service execution at the Internet scale.
Article
Full-text available
The Goal in this paper is to propose a cultural heritage data model and evolve towards the creation of a framework based on MongoDB that will allow to manage a JSON model representing the cultural heritage of a city ICHC (Intelligent Cultural Heritage of a City). This manuscript per the authors noticed that during the census of cultural heritage, the presence of human resources linked to heritage is not something that is represented in a smart engine of a framework. Which is why the goal is to integrate the human resource and therefore add a relational aspect to the NoSql documents so that the resulting framework can have a smart engine to link data.This model is a set of ICHD (Intelligent Cultural Heritage Document) which are JSON documents that represent of the different types of cultural heritage entities. Those documents will be managed in a MongoDB repository architecture that will allow to them, so that the microservices-based ICHC framework can offer a big data context that can handle a huge variety, volume and velocity of data and be based on distributed operations.
Thesis
Microservices have recently emerged as an architectural style in which applications are composed of small, focused services with a cohesive set of responsibilities, each executing on its own process and communicating with others over the network via lightweight mechanisms. Similar to what had happened with monolithic applications, multiple architectural patterns have been proposed to guide the construction of microservices applications, document knowledge and address recurring situations. As a style that was born in the industry, knowledge exchange, formalization, and validation evolved in tandem with, if not after, having the systems deployed and operational. Microservices architectural patterns are frequently stated in an informal manner which may lead to ambiguity, erroneous application, systems differing from expected behavior and lack of tooling support. In fact, multiple implementations for each pattern were created in this context, ostensibly addressing the same issue but presenting variations in behavior. A broadly utilized strategy to eliminate ambiguity in prose descriptions is the application of formalization techniques. In particular, the Event-B method has been used in the context of large-scale systems to formalize service-oriented architecture patterns and business process models, among others. The outcome of applying the Event-B method is a formal model and a set of proof obligations to be discharged. In turn, model-based testing is an extensively used technique to validate a system under test. A model representing the system is built, from which test cases are automatically derived. UML, BPMN, SysML, finite machine notations and mathematical formalisms such as Z or B, are some common mechanisms to build a model of a system for test generation. This thesis proposes an approach for assessing compliance of microservices architectural patterns implementations based on Event-B specifications and model-based testing. The general idea of the approach is to: (i) formalize natural-language-specified microservices architectural patterns using the Event-B method, (ii) automatically derive abstract test cases from the Event-B specifications by leveraging model-based testing techniques, and (iii) instantiate the abstract test cases in order to assess the compliance of concrete patterns implementations. The proposed approach feasibility was empirically assessed using two of the most cited architectural patterns in microservices: Circuit breaker and Service registry. In particular, these patterns were formalized using Event-B and the resulting models were used to assess the compliance levels of three implementations: Netflix Hystrix, Resilience4j and Eureka. To achieve reproducibility of the evaluations, a mechanism based on Jupyter Notebooks was constructed. The development of this thesis enabled us to confirm the issues raised from natural-language specified microservices architectural patterns, such as implementations of the same pattern having different behaviors. In this line, it also confirms the suitability and technical feasibility of the proposed approach based on Event-B and model-based testing, to assess the compliance levels of a particular pattern implementation with regards to the modeled system-to-be.
Conference Paper
Full-text available
Cloud computing provides new opportunities to deploy scalable application in an efficient way, allowing enterprise applications to dynamically adjust their computing resources on demand. In this paper we analyze and test the microservice architecture pattern, used during the last years by large Internet companies like Amazon, Netflix and LinkedIn to deploy large applications in the cloud as a set of small services that can be developed, tested, deployed, scaled, operated and upgraded independently, allowing these companies to gain agility, reduce complexity and scale their applications in the cloud in a more efficient way. We present a case study where an enterprise application was developed and deployed in the cloud using a monolithic approach and a microservice architecture using the Play web framework. We show the results of performance tests executed on both applications, and we describe the benefits and challenges that existing enterprises can get and face when they implement microservices in their applications.
Conference Paper
Full-text available
IT complexity in enterprise today continues to grow at a dizzying rate. Technology innovation, vendor heterogeneity, and business demands are major reasons why organizations are exposed to new risks, based on the gaps opened between the options and features of each IT element and product, and how they are implemented to support a well-defined policy and company strategy. Moreover, the impact of such risks is exacerbated exponentially by failing to identify the handshakes and correlations of interrelated elements. Products, vendors, and IT layers, must work in tandem to prevent potential ”black holes”: risks related to availability, resiliency and data loss. In this paper, we propose a possible approach to reduce complexity, and thus the related risks, and also to gain improvements in terms of simplicity, speed and scalability. In order to achieve those objectives, we can add new behaviors and a business logic at the database level, if easily obtainable. We did it with OrientDB, a Multi-Model NoSQL database, through the development of native extensions, such as the XML-over-SOAP service study case.
Technical Report
Full-text available
Il modello di e-business ha introdotto l’idea del controllo automatico di tutti i processi aziendali al fine di monitorare ogni tipo di attività grazie alla infrastuttura pervasiva fornita dalla rete Internet. Molte organizzazioni stanno rivedendo i propri processi di business in base ai futuri sviluppi e alle potenzialità offerte da Internet. Il modello di e-business ha portato alla formulazione di un metalinguaggio (eXtensible Markup language, XML) per la definizione di grammatiche sui diversi contesti di business e l’introduzione di framework tecnologici quali “Web Services (WS) e-business using XML (ebXML)" che consentono di esprimere gli aspetti semantici ed operativi del business mascherando il substrato tecnologico ed adoperando il web come supporto. Il sistema informativo di un’azienda dipende dalla organizzazione aziendale. La descrizione accurata dei processi aziendali è alla base per la realizzazione dei sistemi informatici. Un sistema informatico, per essere modellato dai processi aziendali deve essere innanzitutto modulare, estendibile e caratterizzato da altissimo livello di integrazione e di interoperabilità. I processi aziendali sono generalmente scomponibili in attività più elementari, per cui occorre seguire dei pattern di tipo gestionale a cui riferirsi per analizzarli ed identificarli. Il progettista del sistema informatico traduce le attività, modellate come servizi a livello di business, in sottosistemi interagenti secondo pattern di tipo tecnologico. Dal punto di vista degli utenti, le organizzazioni nella filiera necessitano di un metodo standard per definire e registrare processi di business, scambiare messaggi di business, condurre relazioni di commercio, comunicare dati in termini comuni. In tale direzione, ebXML offre un insieme di standard per i processi di business, componenti di business riusabili, protocolli di accordo, messaggistica, registri ed archivi. Dal punto di vista dei progettisti, costruire un sistema di tracciabilità coinvolge tutti gli stadi di produzione, trasformazione e distribuzione. Occorre necessariamente uno stile architetturale che garantisca l’interoperabilità e la portabilità dei componenti software in rete. In questa prospettiva, SOA rappresenta un paradigma che assicura una cooperazione effettiva tra agenti software eterogenei. L'ebXML è in grado di poter gestire un'ampia comunità di partecipanti, amministrare risorse centrali per consentire ai partner di unirsi rapidamente in comunità ed integrare le loro proprie applicazioni in una rete condivisa di servizi. Constatata l'assenza in rete di una implementazione open-source aggiornata, si è ritenuto opportuno mettere a punto una implementazione che mettesse a disposizione della comunità di sviluppatori una versione del registro secondo le specifiche OASIS ebXML Registry 3.0 e che supportasse, per quanto concerne la gestione delle politiche di sicurezza, le modalità definite da SAML 2.0 (Security Assertion Markup Language).
Conference Paper
Full-text available
The traditional Java API for Registries (JAXR) provides a useful way for Java developers to use a single simple abstraction API to access a variety of registries. The unified JAXR information model (Infomodel), which describes content and metadata within registries, provides a simple way to access registries information. However, when a JAXR registry provider implements the OASIS (Organization for the Advancement of Structured Information)/ebXML Registry Services Specification, it internally works with ebXML Registry Information Model (RIM) objects which should be exposed as JAXR Infomodel objects. Furthermore, any application using ebXML RIM objects, before the access to the registry via a JAXR provider, has to convert them to the Infomodel counterpart. To deal with this problem, in this paper we suggest a new tool for the ebXML software development, which focuses on an extension of the traditional JAXR layer, providing the native use of ebXML RIM objects in client side applications with a direct access to the ebXML RIM SOAP service, and avoiding any conversion to/from JAXR Infomodel objects. The proposed approach reduces the developers duty, allowing them to focus exclusively on the ebXML objects use and it considerably speeds up the interactions with every ebXML registries.
Article
Full-text available
This paper provides an overview of micro-services architecture and implementation patterns. It continues our series of publications about M2M systems, existing and upcoming system software platforms for M2M applications. A micro-service is a lightweight and independent service that performs single functions and collaborates with other similar services using a well-defined interface. We would like to discuss the common principles behind this approach, its advantages and disadvantages as well as its possible usage in M2M applications.
Article
From the Publisher:Best selling author and world-renowned software development expert Robert C. Martin shows how to solve the most challenging problems facing software developers, project managers, and software project leaders today. This comprehensive, pragmatic tutorial on Agile Development and eXtreme programming, written by one of the founding father of Agile Development: Teaches software developers and project managers how to get projects done on time, and on budget using the power of Agile Development. Uses real-world case studies to show how to of plan, test, refactor, and pair program using eXtreme programming. Contains a wealth of reusable C++ and Java code. Focuses on solving customer oriented systems problems using UML and Design Patterns. Robert C. Martin is President of Object Mentor Inc. Martin and his team of software consultants use Object-Oriented Design, Patterns, UML, Agile Methodologies, and eXtreme Programming with worldwide clients. He is the author of the best-selling book Designing Object-Oriented C++ Applications Using the Booch Method (Prentice Hall, 1995), Chief Editor of, Pattern Languages of Program Design 3 (Addison Wesley, 1997), Editor of, More C++ Gems (Cambridge, 1999), and co-author of XP in Practice, with James Newkirk (Addison-Wesley, 2001). He was Editor in Chief of the C++ Report from 1996 to 1999. He is a featured speaker at international conferences and trade shows. Author Biography: ROBERT C. MARTIN is President of Object Mentor Inc. Martin and his team of software consultants use Object-Oriented Design, Patterns, UML, Agile Methodologies, and eXtreme Programming with worldwide clients. He is the author of the best-selling book Designing Object-Oriented C++ Applications Using the Booch Method (Prentice Hall, 1995), Chief Editor of, Pattern Languages of Program Design 3 (Addison Wesley, 1997), Editor of, More C++ Gems (Cambridge, 1999), and co-author of XP in Practice, with James Newkirk (Addison-Wesley, 2001). He was Editor in Chief of the C++ Report from 1996 to 1999. He is a featured speaker at international conferences and trade shows.
Article
Learn how the Cross-Enterprise Document Sharing (XDS) integration profile helped provide the interoperability necessary to deploy electronic health records, giving healthcare providers access to medical records regardless of location or institution.
Microservice architecture patterns and best practices
  • C Richardson
C. Richardson, "Microservice architecture patterns and best practices", URL: http://microservices.io/index.html [accessed: 2016-02-12].
Microservices, a definition of this new architectural term
  • M Fowler
M. Fowler, "Microservices, a definition of this new architectural term", URL: http://martinfowler.com/articles/microservices.html [accessed: 2016-02-12].