Reactive Through Services

Opinionated Framework for Developing Reactive Services

Micael Pedrosa, Jorge Miguel and Carlos Costa

Institute of Electronics and Informatics Engineering of Aveiro, Aveiro University,

Campus Universit

ario de Santiago, Aveiro, Portugal

Keywords:

Web Services, Service Speciﬁcation, Reactive.

Abstract:

Front-end development is inherently asynchronous, and for some time there was no correct way on how to

build it in a reactive manner. Reactive Programming is a paradigm of software development centered in

asynchronous data streams. Lately, this paradigm has been getting a lot of visibility due to integrations with

frameworks like Angular and React. However, there is (from the electronic jargon) an impedance mismatch

between the reactive UI and the required server-side services. Since common REST services do not integrate

well with this new paradigm and JSON-RPC lacks some of the communication models described in this

publication, we present a possible alternative for an opinionated framework which ﬁlls the gap between the

reactive front-end and back-end services, maintaining the straightforward way of development that REST and

JSON-RPC provides. This framework offers possibilities for new protocols and models, extending the basic

REST and JSON-RPC models. It also delivers a reference implementation, certifying the viability of the

proposal. Available at https://github.com/shumy/reactive-through-services.

1 INTRODUCTION

Web services have become popular in the early 90s

from the DCE/RPC (Distributed Computing Envi-

ronment/Remote Procedure Call), designed to dis-

tribute computation across different physical devices.

This concept is now reused in the known JSON-RPC.

Alongside also came up the (Representational State

Transfer) REST services, introducing resources that

have an associated set of standardized verbs, being

these the two most used standards for Web Service

Architectures. However sometimes it is difﬁcult to

map certain API concepts to the REST or RPC model.

For example, REST services resolve a particularly

narrow range of communication models, namely the

pull based request/reply model that is fundamentally

blocking and synchronous. As such, REST services

have a limited use on more modern reactive applica-

tions (Mesbah and Van Deursen, 2008). It’s possible

to use asynchronous mode with the 202 HTTP code.

Yet, standardization of asynchronous REST services

in parallel with other web protocols would need to

discard most of the HTTP codes and standardize some

JSON structures for the requests and responses.

A complex service back-end maintains connec-

tions to other services in a chain of dependencies,

propagating state changes as is deﬁned in the Reac-

tive Programming model (Webber, 2014). In this sce-

nario a state change in a downstream service will be

propagated to upstream services without any explicit

request. In this model the application user is always

aware of the status of his data by this constant feed-

back, even when the application is under heavy load

or in a failed status. Reactive applications need to

be responsive, resilient and elastic, as stated in the

Reactive Manifesto (Boner et al., 2014). Message-

driven architectures and push style libraries are the

foundation for such responsive systems. Although

there are some push style libraries available on top

of HTTP, like the APE Project

, none is quite well

integrated with modern reactive libraries. The RP im-

proves the level of abstraction of code and feedback

of your applications, as such, code in RP will likely

be more concise, focused in deﬁning business logic

and less on implementation details. The RP model

yields higher throughput just for one thread imply-

ing lower resource usage, and most importantly, more

predictable behavior under load. This programming

model has become very popular due to the Node.js

platform.

http://ape-project.org/

https://nodejs.org

330

Pedrosa, M., Miguel, J. and Costa, C.

Reactive Through Services.

DOI: 10.5220/0006661403300337

In Proceedings of the 8th International Conference on Cloud Computing and Services Science (CLOSER 2018), pages 330-337

ISBN: 978-989-758-295-0

The RTS (Reactive Through Services) framework

was designed to build services with different commu-

nication models in a declarative way through anno-

tations. Implementations may be provided by con-

tainers similar to JEE, aspect weavers or other similar

mechanisms, or in the case of this reference imple-

mentation with compile time generators. The RTS

platform was born by a necessity of building mod-

ern reactive web user interfaces that needed to con-

nect to reactive back-end services. By deﬁning what

are the data streams, how they are linked together and

what happens when their values change over time, it is

possible to simplify the program ﬂow in a declarative

way. In the web environment there are many client

side libraries that help in this task, one of the most

known is ReactiveX

. Although our purpose is not to

solve entirely the Reactive Manifesto challenges, we

provide communication models and also ideas regard-

ing what could be the future of reactive web services

and similar frameworks.

2 TECHNOLOGY EVALUATION

It is worth mentioning that this framework is not in-

tended to be used as an industrial system for hard or

ﬁrm real time products, or even for power-constrained

devices. The project goals are divided in: the archi-

tecture deﬁnition, the implementation reference and

the RTS protocol. Some of the requirements that the

RTS framework is trying to achieve are:

• Providing a small learning curve and development

time for reactive applications.

• Improving the efﬁcient usage of web services by

providing an asynchronous API and not just an

integration like in Servlets 3.0.

• Providing a good interoperability with common

web technologies, like JSON, REST, WebSockets

and ReactiveX.

• Providing service deﬁnitions compatible with dif-

ferent communication models, adding reactive

models to services.

• Supporting bi-directional services where both

clients and servers can act as endpoints for any

communication model, avoiding additional net-

work conﬁgurations or ﬁrewall and NAT issues.

• Providing endpoints for other protocol integra-

tions.

http://reactivex.io/

2.1 Protocols Comparison

In Table 1 there is a diversiﬁed qualitative comparison

of the RTS protocol with other alternatives. A variety

of scopes were selected, so to identify the exact places

where the RTS ﬁts. These scopes are classiﬁed in:

• Device-To-Device (D2D) - As deﬁned in other

publications, (Asadi et al., 2014) D2D is a di-

rect communication between two systems without

traversing the Base Station or core network.

• Device-To-Service (D2S) - Is the common client

server tier architecture, using a central point for

message relay.

• Service-To-Service (S2S) - Normally used for ser-

vice synchronization in the underlying infrastruc-

ture and also exchanging information to maintain

service availability.

Some qualitative measures are represented with:

excellent, good, nice and bad. These measures con-

sider message payload sizes, library availability and

browser integration, that will serve as baselines to

compare between protocols. For instance, CoAP and

DDS are considered incompatible with web clients

due to the underlying protocol used, not aligned with

TCP/IP and thus it is not a good ﬁt for our require-

ments. The RTS protocol was initially targeting the

D2S scope, yet because of the framework symmetry

between the client and server implementation, it can

be easily extended to a S2S context. Protocols are

also classiﬁed based on their communication models,

with detailed descriptions in section 3.1. The RTS

protocol can implement services on all the described

models. In contrast, most other protocols just provide

messaging and framing and are limited in describing

the service semantics.

2.2 State of the Art

There are other projects that pursue some of the same

RTS principles. Following is a small representation

list:

• Spark Java

is lightweight Java web framework

that despite not using annotations it follows a

straight forward approach to deﬁne services. It is

primarily oriented for REST and web interfaces.

There is no clear separation from the service def-

initions and the implementations, making it difﬁ-

cult to integrate with other protocols and commu-

nication models. This is the norm in most REST

frameworks.

http://sparkjava.com/

Reactive Through Services

331

Table 1: Qualitative comparison of some common used protocols. Purposely chosen in a wide range of contexts. Scope

descriptions: S2S (Service To Service), D2S (Device To Service), D2D (Device To Device).

Web friendly Model Net boundary

Network

efﬁciency

QoS Scope

RTS excellent

request/reply

ﬁre-and-forget

request/stream

none nice reliable D2S, S2S

REST excellent req/reply none bad reliable D2S

JSON-RPC excellent

request/reply

pub/sub

none nice reliable D2S

STOMP good pub/sub none nice reliable D2S

XMPP nice

request/reply

pub/sub

none bad reliable D2S, S2S

MQTT nice pub/sub none good

minimal

conﬁg

D2S

CoAP bad request/reply NAT issues excellent

minimal

conﬁg

D2S

AMQP nice pub/sub none excellent

transaction

reliable

S2S

DDS/RTPS bad

request/reply

pub/sub

LAN excellent high conﬁg D2D

• Project Reactor

is an initiative to implement the

new Reactive Streams standard (Streams, 2016)

for several languages in an asynchronous founda-

tion. It adds many additional functionalities to the

standard, yet it is still just a stream library, not

deﬁning service interface semantics for the web.

This can be a good project to integrate with some

RTS asynchronous modules.

• Akka

is a serious competition, a very established

framework providing reactive streams. There is a

distinct list of options for endpoint interfaces with

Akka-Camel (Lightbend, 2016b), cluster manage-

ment, load balancing and other features. It is

based in a simple message-driven architecture, not

presenting any service descriptors or high level in-

terfaces, diverging from a SOA viewpoint. When

multiple actors need to be orchestrated in order

to provide a speciﬁc application function, proper

intertwined messaging can become demanding.

There is a need for providing a higher-level ab-

straction. Akka is good candidate to explore in

some of the RTS integrations, essentially extend-

ing endpoints.

• Lagom

is the most similar with RTS. Declared

as a Reactive Microservice architecture (Boner,

2016) it handles service requests in a similar way

and it has analogous communication models. Ser-

vice descriptors are declared in Java interfaces and

can be also conﬁgured for distinct transport proto-

cols. Still there is no clear concept of communica-

https://projectreactor.io/

http://akka.io/

https://www.lagomframework.com/

tion models, and the service descriptors are bound

to one kind of endpoint, e.g. when using REST

identiﬁers (Lightbend, 2016a), not being reusable

with other service interfaces. RTS is also more

direct when constructing services, using a straight

forward way of deﬁning services.

2.3 Xtend and Typescript Language

Choice

For the reference implementation Xtend and Type-

script languages were selected. Xtend is a language

that is compiled to Java (similar to a pre-processor)

specially useful when using lambda functions and

asynchronous programming. Also the use of fea-

tures like AA (Active Annotations)

aid in the imple-

mentation of declarative instructions in compile time.

Avoids complex code injectors similar to the ones

used in JEE containers, likewise the use of the Java

reﬂection framework. Typescript

is another emerg-

ing language in the web development, introducing op-

tional static types and other facilities that are boost-

ing productivity for medium to large projects. Yet not

very productive for small ones due to the complexi-

ties in project setup compared to JavaScript. It was

also selected because it is the preferred choice when

developing in Angular 2

. Despite the RTS having

no dependencies on the framework, the client library

uses RxJS 5 from ReactiveX that is also extensively

used in Angular 2.

https://eclipse.org/xtend/documentation/204

activeannotations.html

https://www.typescriptlang.org/

https://angular.io/

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

332

3 RTS ARCHITECTURE

OVERVIEW

Even thought current web architectures apply almost

the same protocols as the ﬁrst web servers did, inter-

nals parts have changed considerably. Notably, the

rise of dynamic web contents and constant demand of

feedback produced reasonable impact, pushing those

architectures to a more asynchronous model. The

RTS service interfaces should be considered an ex-

tension of REST services from a client point of view,

it adds the push model to the existent pull network

style. However from the architecture view it is quite

different. The whole architecture in Fig. 1 is designed

from ground to be compatible with asynchronous ap-

plication servers like Vertx

and message-driven ar-

chitectures. These are required features to fulﬁll the

reactive manifesto (Boner et al., 2014). But there are

also other points to mention in the RTS architecture:

• As presented in Fig. 1, network endpoints and

protocols are detached from the service endpoints,

this is a similar attempt from what was done in the

SOAP architecture. In other words, the same com-

patible service can be accessed from a REST end-

point or from an RTS endpoint, by providing just

some conﬁgurations. Endpoints are conﬁgured in

designated routers for a particular protocol. It is

possible to use other protocols, if they are compat-

ible with the same communication model, men-

tioned in section 3.1. This improves SoC (Separa-

tion of Concerns) (Hursch and Lopes, 1995) and

contribute to clean service deﬁnitions.

• Endpoint requests and replies are transformed in

a Message based processing scheme. After going

through the network endpoint, the created mes-

sage enters the processing Pipeline where it can

be intercepted by any custom user code. At this

point the message can be forwarded to the next in-

terceptor, delivered to the service or rejected, e.g

by some Access Control component. Again the

SoC principle is applied for these horizontal as-

pects of the services, by implementing common

interceptors.

• Messages at the end of the Pipeline go through a

decision process based on some message ﬁelds,

e.g. the message type will decide if is to be de-

livered to a request or to a reply service handler,

and if there should be a response or it’s just only a

notiﬁcation. Some message ﬁelds reﬂect the used

communication model avoiding the need of ser-

vice descriptors to build client proxy implementa-

tions.

http://vertx.io/

• There are some architecture symmetries on the

client side. This means the client also has the

Pipeline and the MessageBus components. It is

possible to install the same services on the client

Pipeline and invert the request/reply ﬂux from

server to client. However the network connec-

tion is always made in the client-server direction,

avoiding network issues.

Figure 1: RTS Architecture essential blocks. From top to

bottom: network endpoints, message pipeline, message bus

and services.

3.1 RTS Communication Models

A message-driven architecture beneﬁts from com-

ponent decoupling, providing isolation through a

message-bus and it’s easy to add functionalities to the

system over time. However messages are lazy struc-

tures when deﬁning semantics, requiring more code

to wire and construct complex service scenarios. We

can verify this when trying to construct a request/re-

ply service solely based on the pub/sub model. We

need to link messages through the same identiﬁca-

tion, handle timeouts and sessions for state-full ser-

vices. The RTS architecture is trying to achieve a bal-

ance between message ﬂexibility and service seman-

tics, by deﬁning different feasible models in the router

Reactive Through Services

333

endpoints. RTS endpoints are build on top of Web-

Socket frames with JSON formatted messages. The

use of JSON-RPC was initial proposed for these mes-

sages, unfortunately JSON-RPC is also bound to the

request/reply and ﬁre-and-forget models. The model

we want to extend needs at least a way to send pro-

visional responses and a correct way to identify these

message types.

RTS existing models are represented in the sim-

pliﬁed sequence diagrams on Fig. 2. Here we re-

fer to clients and endpoints distinctly from network

clients and servers. These distinctions are needed be-

cause RTS endpoints are not necessarily in the net-

work servers, due to the already mentioned client-

server symmetry. Services can be installed in the net-

work clients or servers, however the connection is al-

ways established from client to server, avoiding net-

work and ﬁrewall issues. We should look at the dia-

grams independently from who is the network client

or the server.

The typical request/reply model that is used in

REST services is enlarged by the JSON-RPC ﬁre-

and-forget model with the use of notiﬁcations. RTS

extends this with the concept of requesting streams

instead of getting all the data as a single response,

each element is streamed back in order. Streams have

a life cycle that can end with a complete or error sig-

nal from the server, a cancel signal from the client or

with a session disconnect. Stream requests are auto-

matically bound to the Pipeline ﬂow that can be in-

tercepted and controlled by any implemented Access

Control mechanism without further coding.

Specifying communication models adds some ad-

vantages in terms of service compatibility. We can

clearly deﬁne that REST endpoints are only compat-

ible with the request/reply model, excluding any re-

quest/stream services to be linked to the REST end-

point. These deﬁnitions are not a common procedure

when describing services. We propose that, commu-

nication models should be part of any service descrip-

tion and should be included in specs like RAML

Swagger

. Although further studies should be car-

ried out to conclude that the models described here

can completely deﬁne all case scenarios.

3.2 Component Interactions

Looking at the architecture in Fig.1 we have identiﬁed

some Pipeline components that will be used in the se-

quence diagrams Fig. 3. This is a detailed descrip-

tion for the interaction of the request/stream model.

Two new components are presented, C-Observable

https://raml.org/

https://swagger.io/

and S-Observable, but actually can be considered

the Stub (C)lient-Observable and Skeleton (S)ervice-

Observable sides of the same component. In the Type-

script client module, the C-Observable is in truth a

ReactiveX Observable. Part of the initial ﬂow is iden-

tical to a basic request/reply, but returning an Observ-

able ﬂag, detected by the client framework as a mes-

sage reply with the ﬁeld cmd=“obs“ instead of the

typical cmd=“ok“. The result value is an UUID for

the Observable. The client requests a response stream

in step (1) and waits for the asynchronous response

using the well know Promise pattern in step (2), sig-

naling that a background process is running. A typical

use case for this, is requesting a long task in the server

and receiving intermediate feedbacks (3) for the on-

going process, until it ends or fails (4). When the

message is delivered to the Service, it is translated to

a method invocation, as also the method return to a

translated reply message. The PipeContext life-cycle

is also extended until the stream is completed or an

error is thrown. We will not describe here all the de-

tails of all models, since the others already fall in the

common knowledge. The messages are processed by

the following Pipeline components:

• PipeResource is an abstraction for any connec-

tion or session (using TCP or any other protocol).

Is also a placeholder for the connection resources,

hence the chosen name. Any resources or sub-

scriptions are state-full until the connection is re-

leased.

• PipeContext is an abstraction for a request con-

text. In a REST endpoint this has the same life-

cycle of a PipeResource, but in RTS with keep

alive WebSockets, PipeResource’s can live much

longer than any PipeContext. The context is

available to services via Dependency Injection to

the method parameters, e.g providing the context

User to the service.

• Service is a user class extension of an available

interface IComponent (more on this later). Ser-

vices expose methods as public endpoints and de-

pending on the declared returned value it maps to

a deﬁned communication model.

3.3 Service Meta-Data and Descriptors

Service Descriptors are useful for integrations, ser-

vice discover and Proxy Stub generators, effec-

tively removing the guesswork in calling the ser-

vice. In RTS, descriptors are decoupled from the

service meta-data similar to how service endpoints

are from the deﬁnitions. The meta-data is gener-

ated from Xtend Active Annotations and from ser-

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

334

Figure 2: Available communication models in RTS endpoints. From left to right, ﬁre-and-forget - no reply needed, re-

quest/reply - mostly used in web services, request/stream and request/stream + ﬂow control - with or without ﬂow control,

requesting multiple asynchronous responses until completion.

Figure 3: Request/stream model, details for message ﬂow

and component interactions.

vice DTO’s (Data Transfer Objects) (Pantaleev and

Rountev, 2007). It is possible to generate different

descriptors for the same service e.g. both RAML and

Swagger speciﬁcations. However, the problem found

in most speciﬁcations is that these are frequently ori-

ented to REST services, not describing communica-

tion models beyond the request/reply. RTS architec-

ture is paving the way for the reactive models to be

included in the service descriptors, not committing to

a predeﬁned format.

4 RTS DEMONSTRATION

Asynchronous programming is notoriously tricky, but

it doesn’t have to be, at least when providing service

interfaces. In this section we will show some straight

forward examples on how to use the framework to de-

liver REST and RTS services in a declarative way, us-

ing features of the Xtend language and Active Anno-

tations. This will just demonstrate the easy of use,

not covering many other optional features. In List. 1

we set a default server implementation where inter-

ceptors and services can be added. A common used

interceptor is the JwtAuthInterceptor for JSON Web

Token validations, and it’s available in the rts-service-

utils module. Also, there is a FolderManagerService

service exposing a server folder for ﬁle download, up-

load and listing. In the service conﬁguration, the ﬁrst

two parameters (service name and implementation)

are mandatory. The third parameter (a similar JSON

type structure) for group Access Control is optional.

We will not explain the Access Control mechanisms

in this document, but the code should be self explana-

tory.

Listing 1: Pipeline conﬁguration example.

val server =

new DefaultVertxServer(vertx, ’/clt’, ’’)

//services

val folderManagerSrv =

FolderManagerService => [

folder = ’./downloads’

]

...

server.pipeline => [

addInterceptor(...)

addService(...)

addService(

’folder-manager’,

folderManagerSrv,

’list’ -> ’all’,

’download’ -> ’all’,

’upload’ -> ’admin’

}

)

...

failHandler = [

println(’PIPELINE-FAIL: ’ + message)

Reactive Through Services

335

]

In the default server implementation (Default-

VertxServer) there are 2 routers for deploying REST

and RTS endpoints, available with the properties we-

bRouter and wsRouter respectively. The provided

conﬁguration example in List. 2 for a REST end-

point and GET action at the path “/ﬁle-list/:path“ will

redirect to the service name “folder-manager“ and the

provided “list“ method previously deﬁned. The REST

path is deﬁning an input variable “:path“ that, in this

case is automatically mapped to the ﬁrst parameter of

the service method. RTS endpoints don’t need addi-

tional conﬁgurations, the wsRouter is only available

to intercept some type of messages and actions e.g:

on opening a connection.

Listing 2: Web Router endpoint conﬁguration example.

server => [

webRouter => [

route(...)

...

get(

’/file-list/:path’,

’folder-manager’ -> ’list’

)

]

A simple service declaration example is provided

in List. 3. We only need to declare the class as a

Service and mark the methods as Public available for

endpoints. In the hello method the return type is syn-

chronous, but it is always processed by the internal

asynchronous engine. The streamExample method

returns an Observable that is recognized by the RTS

as a stream response and is processed accordingly.

Other options that are provided but not explained here

are: service meta-data generation, interface mapping

and other asynchronous options.

Listing 3: Service declaration example.

@Service

class TestService {

@Public

def hello(String firstName, String lastName)

’’’Hello <<firstName>> <<lastName>>!’’’

def streamExample() {

val ObservableResult<String> pResult = [

sub |

...

sub.next(’string-value-1’)

...

sub.next(’string-value-2’)

...

sub.complete

]

return pResult.observe

}

To access the RTS endpoints there are client li-

braries in Xtend and Typescript. The way proxy stubs

are created is by deﬁning an interface and get the im-

plementation from a router component, described in

Listing 4. The “test“ name reference is just the service

name provided in the Pipeline conﬁguration. How to

create a router is not described here, but it’s normally

a step in the client initialization.

Listing 4: Service proxy stub interface deﬁnition and use

example for Typescript.

//service proxy for TestService

interface TestProxy {

hello(

firstName: string,

lastName: string

): Promise<string>

}

//use the proxy implementation

let testProxy =

router.createProxy(’test’) as TestProxy

testProxy.hello(’Johnny’, ’English’)

.then(_ => { ... })

5 CONCLUSIONS

The myriad of emerging technologies is huge in the

ﬁeld that RTS is trying to innovate. To defend our-

selves from redoing work from other projects, the

RTS architecture was carefully constructed to achieve

maximum decoupling of any implementations. It is

possible to verify such claims looking at the project

code, where even a simple asynchronous instruction

is abstracted, like a “while“ in the rt.async.AsyncUtils

class. These are not supported natively by the lan-

guage and are dissociated from the reference imple-

mentation, implemented in Vertx. The RTS archi-

tecture is abstracting several concepts in a form that

should be easy to plug other different technologies, to

create routers and endpoints and integrate them in the

same Pipeline and MessageBus. Even if the RTS pro-

tocol is proven not to be adequate for a particular use

case, there are several other useful modules that can

be reused to declare services and service meta-data

for other implementations. We envision the use of

other projects to build a micro-service oriented archi-

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

336

tecture. e.g. Eclipse Aether

is already integrated to

build simple plugins, Apache Spark

is a nice target

for providing processing clusters, and Akka-Camel

for constructing different endpoints in several proto-

cols. Performance tests were not included since the

main goal was to present the communication models,

and the reference implementation that is still in an ex-

perimental stage.

6 FUTURE WORK

Although we thought that was a good idea to expose

the service API’s using the JavaScript Proxy, essen-

tially reﬂecting the API design to the client. The main

fact is that the JS Proxy is a relatively new spec, and

there are no good polyﬁlls that can be used for old

browsers. This can be solved by generating the client

API with the service description, instead of the dy-

namic construction.

The reactive-streams standard will be part of the

Java 9, exposed by the Flow class. We should look

at this and adapt, so that the RTS service API’s could

more compliant with those specs.

One of the key principles governing the Reactive

Manifesto stands for quick responsiveness of the sys-

tem, no matter if the response is positive or not. In

a chain of asynchronous service calls, multiple fail-

ures can put the client in a long waiting due to service

timeouts. There are some proposed solutions to min-

imize this problem, one is adding a Circuit Breaker

(Fowler, 2014) between service calls for a fail fast re-

sponse.

Further integration tests with stream engines are

needed, e.g: Apache Spark or Akka. The implemen-

tations of meta-data and service description genera-

tions are still immature.

We recognize that breaking changes could be in-

serted due to advanced requirements in this future

work, and that’s why we are not committing to release

1.0.

7 ACKNOWLEDGMENTS

This work is ﬁnanced by the ERDF European Re-

gional Development Fund through the Operational

Programme for Competitiveness and International-

ization - COMPETE 2020 Programme, and by Na-

tional Funds through the FCT Fundac¸

ao para a

https://projects.eclipse.org/projects/technology.aether

https://spark.apache.org/

http://doc.akka.io/docs/akka/snapshot/scala/camel.html

encia e a Tecnologia (Portuguese Foundation for

Science and Technology) within project CMUP-

ERI/TIC/0028/2014.

REFERENCES

Asadi, A., Wang, Q., and Mancuso, V. (2014). A survey

on device-to-device communication in cellular net-

works. IEEE Communications Surveys & Tutorials,

16(4):1801–1819.

Boner, J. (2016). Design Principles for Distributed Sys-

tems: Reactive Microservices Architecture. O’Reilly.

Boner, J., Farley, D., Kuhn, R., and Thomp-

son, M. (2014). The reactive manifesto.

http://www.reactivemanifesto.org/. Accessed

September 20, 2016.

Fowler, M. (2014). Circuit breaker pattern.

http://martinfowler.com/bliki/CircuitBreaker.html.

Accessed October 24, 2016.

Hursch, W. L. and Lopes, C. V. (1995). Separation of con-

cerns.

Lightbend, I. (2016a). Lagom service descriptors: about

rest identiﬁers. http://www.lagomframework.com/

documentation/1.1.x/java/ServiceDescriptors.html#REST-

identiﬁers. Accessed October 24, 2016.

Lightbend, I. (2016b). Untyped actors to receive and send

messages over a great variety of protocols and apis.

Mesbah, A. and Van Deursen, A. (2008). A component-and

push-based architectural style for ajax applications.

Journal of Systems and Software, 81(12):2194–2209.

Pantaleev, A. and Rountev, A. (2007). Identifying data

transfer objects in ejb applications. In Proceedings of

the 5th international Workshop on Dynamic Analysis,

page 5. IEEE Computer Society.

Streams, R. (2016). Standard for asynchronous stream pro-

cessing with non-blocking back pressure.

Webber, K. (2014). What is reactive programming?

https://medium.com/reactive-programming/what-

is-reactive-programming-bc9fa7f4a7fc#.wr20gleev.

Accessed October 16, 2016.

Reactive Through Services

337