Diamond

A Cube Model Proposal based on a Centric Architecture Approach to Enhance

Liquid Software Model Approaches

Clay Palmeira da Silva, Nizar Messai, Yacine Sam and Thomas Devogele

Departement Informatique, Universit

e Franc¸ois Rabelais, 30 Avenue du Monge, Tours, France

Keywords:

RESTful, API, Web Services, HTTP, Liquid Software, CUBE Model.

Abstract:

The adoption of multiple connected devices in our lives is a reality which the available technology is not

able to deal with. The concept of Liquid Software emerged in the end of the 90s, however, its full potential

of a uniﬁed interface which can drift between different connected devices and bring with its behavior and

complexities is still not fully applied. Thus, enhancements of current Web application architecture, in other

words, a new approach able to deal with our technology requirements is required. In this context, we propose

a centric-basic architecture to deal with Liquid Software principles and constraints. The CUBE, once built,

should be able to deal with all these requirements, making use of best practices from different technologies.

1 INTRODUCTION

In the last few years, the concept of RESTful has been

widely adopted, and a large number of APIs or frame-

works have been created and deﬁned as so, although,

several studies indicate that many APIs are not fully

RESTful (Florian Haupt and Pautasso, 2015).

RESTful principles require the use of hypermedia.

Thus, API or Frameworks which apply XML or JSON

on their codes do not make use of hypermedia han-

dling, since these languages are not able to deal with

hypermedia. Furthermore, to be deﬁned as a Level 3

RESTful API means to have the ability to change the

current state of a resource through hypermedia. Thus,

according to (Pautasso, 2014), APIs which do not deal

with hypermedia are not fully mature and cannot be

deﬁned as RESTful.

This leads us to another insight: Is the HTTP pro-

tocol used completely and correctly? (Richardson and

Ruby, 2007) Is the REST architecture respected? In

other words, are the required design constraints de-

ﬁned by (Pautasso, 2014) followed in order to achieve

RESTful principles?

Initially in our research, these unanswered ques-

tions still require more investigation. Meanwhile,

other related issues drive us in different direc-

tions, such as: i) Maturity Software; ii) Instanti-

ation Resources; iii) HTTP Link Header; iv) API

Conversation and v) Liquid Software. (Pautasso,

2014), (Tommi Mikkonen and Pautasso, 2015), (Flo-

rian Haupt and Pautasso, 2015), (Andrea Gallidabino

et al., 2016), (Panziera and Paoli, 2013), (Mahdi Ben-

nara and Amghar, 2014), (Savas Parastatidis and

Robinson, 2010), (Richardson and Ruby, 2007).

These directions lead us to assess how Web Ser-

vices are built. While they exchange representa-

tions of their resources with consumers, they never

provide direct access to the actual state of the un-

derlying resources (Savas Parastatidis and Robinson,

2010). Therefore, the Web does not support pointers

(Savas Parastatidis and Robinson, 2010), and URIs

are used to construct all representations with their re-

sources on the Web, relating, connecting and associ-

ating them.

All these different approaches and techniques are

driven towards a common interest, of attempting to

ﬁnd a way to enhance communications through API,

Web Services and Frameworks, using or not the con-

cepts of Liquid Software, detailed later in this pa-

per. However, an approach or methodology which can

combine these techniques to achieve results is still un-

available.

It is in this scenario that we present our CUBE

model based on a centric architecture approach, in or-

der to support multiple connected devices owned by

the same user. Once the information is acquired from

a Server, it is possible to share data with all the con-

nected devices in the same user-network through a

trigger. This makes the not only a technology inte-

grator, but also a way of saving resources.

382

Silva, C., Messai, N., Sam, Y. and Devogele, T.

Diamond - A Cube Model Proposal based on a Centric Architecture Approach to Enhance Liquid Software Model Approaches.

DOI: 10.5220/0006372803820387

In Proceedings of the 13th International Conference on Web Information Systems and Technologies (WEBIST 2017), pages 382-387

ISBN: 978-989-758-246-2

This paper describes our CUBE model concept for

the design of Web applications and how and to which

extent current technologies can support its novel re-

quirements. This paper is structured as follows: Sec-

tion 2 provides a background regarding the previously

mentioned main constraints. Section 3 discusses engi-

neering in light of present Web technologies. Section

4 provides extended discussions regarding our ﬁnd-

ings and Section 5 gives concluding remarks high-

lighting future research directions.

2 CUBE MODEL APPROACH

MOTIVATIONS

This section describes how different techniques and

perceptions led us to our proposal, and how we ex-

tracted the best state-of-art practices and built them

into our CUBE model.

2.1 RESTful Principals and Constraints

We can assume that, while service-oriented comput-

ing becomes adopted every day, SOAP-based APIs

is more and more giving place for REST-based ap-

proaches. According to (Mahdi Bennara and Amghar,

2014) in 2014, 2125 SOAP-based APIs were devel-

oped, against 6833 REST-based ones.

To be deﬁned as RESTful, the platform should fol-

low some principles, as described in (Pautasso, 2014),

which, in general, lead to high system performance,

reduced consumption, high interoperability and secu-

rity in all devices, as well as encapsulated legacy sys-

tems.

In addition, RESTful services should also respect

some constraints, such as: i) Stateless interaction, ii)

Resource linking, iii) Identiﬁcation or addressability

of resources, iv) Uniform interface, v) Hypermedia as

a mechanism for decentralized resources and vi) Self-

describing messages (Mahdi Bennara and Amghar,

2014) (Pautasso, 2014) (Panziera and Paoli, 2013).

Thus, when all these principles and constraints

are put together as best practices to create a REST-

based application (API or Framework), another prob-

lem emerges: Which language can be used to support

a level 3 RESTful characteristic? What should be

the choice in order to support hypermedia controls?

These questions lead to the concept of maturity soft-

ware addressed in the next subsection.

2.2 Maturity Software

A level 3 RESTful characteristic relays in the ability

of a service to change the set of links that are given to

a client based on the current state of a resource (Pau-

tasso, 2014) (Lanthaler and Gtl, 2011). In this context

hypermedia support controls XML and JSON (Tuan-

Dat Trinh et al., 2015) are not able to achieve a real

Level 3. On the other hand Atom, XHTML or JSON-

L are able to do so (Pautasso, 2014).

However, what exactly does this mean? An API

to be deﬁned as RESTful should be fully mature,

thus, making use of hypermedia in order to model

the relationship between resources. As put simply by

(Savas Parastatidis and Robinson, 2010) that hyper-

media drives systems to transform their application

state.

Still according to (Savas Parastatidis and Robin-

son, 2010), the hypermedia system is described by

participants as a transferring resource representation

that contains links according to an application proto-

col.

The maturity level of a service also affects the

quality attributes of the architecture in which the ser-

vice is embedded (Pautasso, 2014). That is why a

standardized and uniform interface was applied to

each resource in order to remove unnecessary vari-

ations and to enabling all services to interact with

all resources within the architecture, thus promot-

ing interoperability and serendipitous reuse (Vinoski,

2008), (Pautasso, 2014).

2.3 Instantiation Resources

In a scenario of multiple devices, the instantiation re-

source feature is signiﬁcantly important. This is a

key feature of most RESTful Web Services, which en-

ables clients to create new resource identiﬁers and set

the corresponding state to an initial value (Pautasso,

2014).

Consequently, a resource can either be set by the

service or by the client. Thus, it is possible to as-

sume that the URI created by the service is unique,

while it is possible that multiple clients generate the

same identiﬁer (Pautasso, 2014). This feature can be

used in order to provide a new set of services de-

livered by different servers to the same client. But,

in order to do this, the approach proposal described

by (Tommi Mikkonen and Pautasso, 2015) should be

modiﬁed for an inside perspective, where the services

are shared by the connected devices.

In this aspect, we allow for the use of POST, GET,

SET and DELETE to be managed by the API in or-

der to achieve the result expected by the client. Thus,

it seems necessary to establish a better appliance of

semantics concepts, not only in the Instantiation Re-

sources but also in the Link Header, which changes

signiﬁcantly according to client behavior.

Diamond - A Cube Model Proposal based on a Centric Architecture Approach to Enhance Liquid Software Model Approaches

383

However, when accessing a social-media platform

such as Linkedln through Facebook or Google, au-

thorization from the client is required, and these plat-

forms often accuse a security error when attempt-

ing integration. It is noteworthy that the certiﬁcate

to access the different resources is not provided by

the Servers/Services, but by the client through an en-

crypted password.

2.4 Link Header

A Link header is a powerful HTML resource, al-

though not usually correctly applied. It gains signif-

icant value in REST-based approaches. Some inter-

esting research has been conducted in this regard, as

seen in (John and M.S., ), who propose to discover

REST resources as the user navigates. Their work

seems promising, but depends too much on perfect

assumptions in order to obtain results.

Another similar approach is composed of

RESTful-linked services on the Web, as proposed

by (Mahdi Bennara and Amghar, 2014). Despite

their effort and interesting proposal, there is a lack of

concern with the use of Semantics in order to achieve

better results.

In fact, when the link header is used correctly it

is possible to include one or more hyper-links. Thus,

multiple targets are shown to be selected by the client.

This gives rise to other issues, e.g. which URI should

the client follow and does its selection imply the ex-

pected result by the client? If so, how should the con-

sumer’s choice of the URI be conducted in order to

obtain the expected outcome?

These issues still require attention in order to en-

hance the Link Header. It is important not only to

ﬂood the consumer with all URIs, but also to give a

well-deﬁned set of useful URIs.

2.5 API Conversation

We can deﬁne an API Conversation as a set of com-

munication activities between two or more partici-

pants (Florian Haupt and Pautasso, 2015). Thus, the

focus is on communication between a consumer and

a RESTful Web API. From the client’s perspective,

this means an interaction with a certain API to fulﬁll

a goal. Thus, the resources are the building blocks of

each RESTful Web API (Florian Haupt and Pautasso,

2015).

When a consumer requires multiple re-

quest/response interactions, she/he wishes to

exchange published resources with one or more

consumers. Therefore, it is possible to have multiple

RESTful APIs emerging from the navigation within

a Web through hypermedia relationships sponsors

by consumers (Florian Haupt and Pautasso, 2015),

(Tommi Mikkonen and Pautasso, 2015), (Pautasso,

2014),(Mahdi Bennara and Amghar, 2014). Figure 1

demonstrates how multiple requests can occur at the

same time.

Figure 1: How a client can use data from different services.

Font (Florian Haupt and Pautasso, 2015).

However, in this scenario, still according to (Flo-

rian Haupt and Pautasso, 2015), four examples of

RESTful conversation types were collected: i) Redi-

rect, ii) Accessing Resources Collections iii) Try-

Conﬁrm-Cancel, and iv) Long Running Requests.

Each example has a different way to deal with the

RESTful conversation.

In this context, another issue was identiﬁed: A

model API which combines multiple basic conversa-

tion types. This means, in our perspective, how se-

mantics can be used as a mediation support (reposi-

tory) for multiple REST API conversations. Further-

more, this includes how semantics can be used to: i)

Build, ii) Read, iii) Evaluate, iv) Compare and v) En-

hance multiple REST APIs conversations.

2.6 Liquid Software

Despite being a technology mentioned at the end of

the 90s (Hartman J.H et al., 1999), over two decades

ago, we have seen no signiﬁcantly enhancements in

this method. However, one thing has changed, our

behavior, since most of the time, we use at least two

Internet-connected devices at same time.

When we expand this perspective for the available

possibilities, such as laptops, smart-phones, tablets,

phablets, game consoles, smart TVs, car display,

watches, augmented reality glasses, digital cameras

and photo frames, home appliances and so on (An-

drea Gallidabino et al., 2016), we obtain a perspec-

tive of insufﬁcient resources to deal with this amount

of devices at the same time.

WEBIST 2017 - 13th International Conference on Web Information Systems and Technologies

384

Despite the huge amount of connected devices,

there is another constraint concerning the user-device

experience. According to (Tommi Mikkonen and

Pautasso, 2015), there are 3 main categories: 1) Se-

quential Screening, 2) Simultaneous Screening and 3)

Collaboration Scenario.

Until today, despite all the available technologies,

we are not able to obtain a simple data-ﬂow without

starting from zero each time. An example is while

a person leaves a certain place, she/he decides to be-

gin writing a message on a mobile device, but enters

the car, so continues the action using speech resources

through the car, then, when arriving at the ﬁnal desti-

nation ﬁnishes the message on a laptop, desktop or a

smart TV.

Currently, there is no ﬂuid exchange of informa-

tion through all platforms, connected devices and so

forth. Protocols, messages and certiﬁcate standard-

ization in order to achieve full data-ﬂow through con-

nected devices are still lacking.

3 ENGINEERING OF PRESENT

IN WEB TECHNOLOGIES

The Web promises to change signiﬁcantly in the next

years regarding all the connected devices at our dis-

posal. This requires not only changing the way how

softwares will be built, but also how the Internet itself

and its resources will deal with these great numbers

of devices connecting with same or different behav-

iors (Pautasso, 2014).

On this subject, one point should be clariﬁed: con-

nected devices require an Internet connection to work,

while IoT devices,do not need any Internet connection

in some cases. Regarding the future of connected de-

vices without an Internet connection, no assumptions

can be made for now.

3.1 Layers Model

The architecture of current Web applications is cur-

rently not living up to the expectation of multiple

devices with content, lacking new perspectives. It

is known how the evolution brought us from OSI to

TCP/IP, as displayed in the Figure 2. Therefore, a

platform to deal with all connected devices and their

behavior is necessary.

4 DISCUSSION

It is a fact that multiple devices are a growing trend.

However, despite all efforts in the last years, much

Figure 2: These structures could be enhanced in or-

der to support multiple connected devices. Image

source (http://www.whatisnetworking.net/tag/advantages-

and-disadvantages-of-osi model/, 2017).

must still be developed to deal with this issue in a

synchronized way.

The Internet was built to allow for caching infor-

mation across its infrastructure, which can be helpful

in many aspects. For example, a subsequent request

for the same page along the same network path may

be satisﬁed by a cached representation (Savas Parasta-

tidis and Robinson, 2010). However, when we think

of 1 or N connected devices to a user which needs

to access her/his personal email, all this caching be-

comes useless.

When we think about computer-to-computer sys-

tems, a cost in terms of transactional atomicity and

also scalability is present (Savas Parastatidis and

Robinson, 2010) (Florian Haupt and Pautasso, 2015).

Despite the efforts to build a system using Liq-

uid Software principles (Hartman J.H et al., 1999)

(Tommi Mikkonen and Pautasso, 2015) (Andrea Gal-

lidabino et al., 2016), there is a lack of an architec-

ture or framework able to deal with all the involved

requirements, principles and constraints. Thus, its

in this scenario where we propose our centric-based

CUBE model, Figure 3.

Figure 3: The user is in the center surrounded by devices

(inner CUBE) and services (outer CUBE).

The model description follows this sequence: A

Server (S1) requests an ordinary service (So). It needs

to wait for the sum of the response time (t). The time

can be inﬂuenced by the sum of the distance to each

service (d), which can change according to the avail-

ability of routers. Once the Server (S1) has received

Diamond - A Cube Model Proposal based on a Centric Architecture Approach to Enhance Liquid Software Model Approaches

385

the service (So), it keeps all data as cache. A sec-

ond Server (S2), which needs the same data once re-

quested by (S1), does not need to follow the entire

path that (S1) followed, since all that (S2) requires is

the data.

After the ﬁrst request from (S2), if other Servers

receive on-line requests of the same data from (S1),

all resources used in the initial (S1) search are saved.

This means lower energy consumption and through-

put, among others. A comparison with a TCP-IP

model, as displayed in the Figure 4, can project how

CUBE would act.

Figure 4: All devices could use the same data after acquir-

ing.

It is important to realize that each Server (S1,

S2,...Sn) is in fact a connected device owned by the

same user. Since all the credentials, certiﬁers, head-

ers and data in each layer of the TCP is already owned

by the ﬁrst Server (S1) there is no need to perform all

these steps again, since the owner is the same.

In order to activate any new device in its own net-

work, the user will need a trigger, such as a ﬁnger-

print or an encrypted password. To add this device,

two methods can be used, combined. First, the graph

methodology (Bulitko et al., 2008) of level search,

which can begin at any arbitrary node to all adjacent

nodes. Second, using the Dijkstra algorithm (Bran-

des, 2001) to search for the minimal distance from a

node to another.

As for choosing a CUBE as the adequate model

for the approach, a quadtree is applied (Samet, 1988),

generally used to describe a class of hierarchical data

structures whose common property, is thus based on

the principle of recursive decomposition of space.

According to (Samet, 1988), they can be differenti-

ated by the following: 1) The type of data that they

represent, 2) The guiding principle of the decomposi-

tion process, and 3) The resolution (variable or not).

Regarding the geometrical limitation of the

CUBE, as an example, 8 different devices using 8

servers at the same time, two ways of dealing with

this type of organization are available. The ﬁrst is

in the inner CUBE (devices), as the connection be-

tween vertices can provide a new device - volume

approach, while the same principal can be applied to

the outer CUBE (services). If technology limitations

are present, another way to manage too many devices

in the same user-network is duplicating the CUBE,

which is possible using the Tridimensional approach

of Architas of Tarento (Boyer, 1996) and (O’Connor

and Robertson, ).

We understand that the CUBE can be a model

which could share restrictions or also act as a proxy

in order to ﬁlter all Internet requests in the same net-

work. This brings forward the concept of domestic

networks and their proﬁles sharing the same services

but at different levels of request.

As discussed, there are many current constraints

which require attention, such as increasingly con-

nected devices attempt to gain our attention. How-

ever, following the data-ﬂow of these devices still re-

quires a signiﬁcant effort in order to bring forward a

unique platform.

However, in order to use the best practices, a

perspective of business process is required. While

this approach deals with produced and consumed

resources, a limited and linear vision of multi-

connected systems is still prevalent. This scenario

brings us to an edge which requires not depleting our

resources, while, at the same time, providing all tech-

nology features.

5 CONCLUSIONS

Working with the same data-ﬂow independently of the

connected device and platforms is still an issue which

must combine different technologies. It is under this

concept that lie some principles of Liquid Software,

which should be a tendency in a world which is more

and more connected every day.

Thus, an effort is required in dealing with all the

challenges of the Internet platform. In this context, a

model able to converge multiple and heterogeneous

environments with different behavior and complex

systems is necessary.

This position paper has presented our CUBE

model, applying the best practices of different tech-

nologies described herein. Once the concept is ma-

ture enough in our perspective, future steps will allow

us to evaluate the enhancement of each technology in

the cube vertices’s and edges.

To the best of our knowledge, the main challenge

is to assess whether the CUBE will be a model to a

framework, an API or a new protocol able to deal with

the increasing requests of connected devices.

WEBIST 2017 - 13th International Conference on Web Information Systems and Technologies

386

REFERENCES

Andrea Gallidabino, C. P., Ilvonen, V., Mikkonen, T., Syst,

K., Voutilainen, J.-P., and Taivalsaari, A. (2016). On

the architecture of liquid software: Technology alter-

natives and design space. In 13th Working IEEE/IFIP

Conference on Software Architecture (WICSA). IEEE.

Boyer, C. B. (1996). History of Mathematics. Edgard

Blcher ltda, So Paulo.

Brandes, U. (2001). A faster algorithm for betweenness

centrality. The Journal of Mathematical Sociology,

25(2):163–177.

Bulitko, V., Lustrek, M., Schaeffer, J., Bjornsson, Y., and

Sigmundarson, S. (2008). Dynamic control in real-

time heuristic search. Journal of Artiﬁcial Intelligence

Research, 32:419–452.

Florian Haupt, F. L. and Pautasso, C. (2015). A conversa-

tion based approach for modeling rest apis. In 12th

Working IEEE/IFIP Conference on Sotware Architec-

ture. IEEE.

Hartman J.H, B. P., P.G., B., A.B., M., R., P., O., S., T.A.,

P., L.L., P., and A.C, B. (1999). Joust: A platform for

liquid software. In IEEE Computer 32. IEEE.

http://www.whatisnetworking.net/tag/advantages-

and-disadvantages-of-osi model/

(2017). Accessed 26-01-2017. In

advantages-and-disadvantages-of-osi-model.

http://www.whatisnetworking.net/tag/advantages-

and-disadvantages-of-osi-model/.

John, D. and M.S., R. Restdoc: Describe, discover and

compose restful semantic web services using anno-

tated documentations. In International Journal of Web

and Semantic Technology Vol 4, N 1, January, pages

37 to 49.

Lanthaler, M. and Gtl, C. (2011). A semantic description

language for restfull data services to combat semapho-

bia. In 5th IEEE International Conference on Digital

Ecossystems and Technologies. IEEE.

Mahdi Bennara, M. M. and Amghar, Y. (2014). Composing

restful linked services on the web. In WS-REST 2014.

Companion.

O’Connor, J. and Robertson, E. F. Archytas of tar-

entum. In The MacTutor History of Math-

ematics archive. http://www-history.mcs.st-

andrews.ac.uk/Biographies/Archytas.html.

Panziera, L. and Paoli, F. D. (2013). A framework for self-

descriptive restful services. In International World

Wide Web Conference IW3C2. Companion.

Pautasso, C. (2014). Restful web services: Principles, pat-

terns, emerging technologies. In Web Services Foun-

dation. Springer Science+Business Media.

Richardson, L. and Ruby, S. (2007). RESTful Web Services.

OReilly media and Associates, Sebastopol, 1nd edi-

tion.

Samet, H. (1988). Theoretical Foundations of Computer

Graphics and CAD - An overview of Quadtrees,

Octreess and Related Hierarchical Data Structures.

Springer-Verlag Berlin Heidelberg.

Savas Parastatidis, Jim Webber, G. S. and Robinson, I. S.

(2010). The role of hypermedia in distributed system

development. In WS-REST - Proceedings of the First

International Workshop on RESTful Design Pages 16-

22. ACM New York.

Tommi Mikkonen, K. S. and Pautasso, C. (2015). Towards

liquid web applications. In ICWE. Springer Interna-

tional Publishing Switzerland.

Tuan-Dat Trinh, P. W., Do, B.-L., Kiesling, E., and Tjoa,

A. M. (2015). Semantic mashup composition from

natural language expressions: Preliminary results. In

iiWAS, Brussels, Belgium. ACM.

Vinoski, S. (2008). Serendipitous reuse. In IEEE Internet

Comput. 12(1), 8487. IEEE.

Diamond - A Cube Model Proposal based on a Centric Architecture Approach to Enhance Liquid Software Model Approaches

387