This work has been supported by the Project AAL4ALL (QREN 13852), co-financed by the Fund through “COMPETE - Programa Operacional Factores de Competitividade”, and by FCT – Fundação para a Ciência e Tecnologia within the Project Scope: PEst-OE/EEI/UI0319/2014.
Architectures
António Pereira
1, Ricardo J. Machado
2, Juliana Teixeira
2, Nuno
Santos
1, Ana Lima
1,José Eduardo Fernandes
31CCG - Centro de Computação Gráfica, Guimarães, Portugal
mpereira@ccg.pt, juliana.teixeira@research.ccg.pt, nuno.santos@ccg.pt, ana.lima@ccg.pt 2
Centro ALGORITMI, Engineering School of University of Minho, Guimarães, Portugal
rmac@dsi.uminho.pt
3Polytechnic Institute of Bragança, School of Technology and Management Dept. of
Informatics and Communications, Bragança, Portugal
jef@ipb.pt
Abstract. The emergence of the Internet as a ubiquitous means of communication fostered the growth of new business and service models based on Cloud Computing. Information and Communication Technology companies use reference models to define their Cloud Computing strategies. NIST Cloud Computing Reference Architecture is one of these reference models that assist in the design of business, services, and architecture models. This paper aims to present the use of NIST reference architecture in the design of Cloud Computing architectures by employing a method that enables the application of the reference architecture to the refinement of logical architectures.
Keywords. Cloud Computing; Logical Architectures; Reference Model; NIST;
Model; Requirements.
1
Introduction
The evolution and the increasing availability of Internet enabled the growth of new business and service models for ICT Industry, including models for Cloud Computing
business and service architectures. Reference models enable the specification of the main activities and functions for Cloud Computing contexts. They address the concerns of the key stakeholders by defining the architecture capabilities and roadmap aligned with the business goals and architecture vision [3].
ICT Industry uses the NIST (U.S. National Institute of Standards) Cloud
Computing Reference Architecture (CCRA) [4, 5] to support the decision making
process of the design and specification of Cloud Computing architectures, models, solutions, and services.
At the same time as the concept of Cloud Computing is known, it appears, at the application level, the Ambient Assisted Living (AAL) domain with opportunities for developing new products and services that can be available on the Internet [6]. AAL technologies allow enhancing the lives of elderly and dependent people by offering them the ability to carry out routine tasks by themselves. Such technologies use ICT as a core component to generate highly dynamic systems and applications [7]. These systems and applications must assist ubiquitously and adapt to an individual’s daily context-aware needs.
Cloud Computing promotes the seamless integration of systems and devices in the
users daily lives through device and location autonomy [7]. It is necessary to adopt new strategies, new models, and mechanisms that enable the development of consistent, interoperable, and standardized solutions across the Cloud Computing
ecosystem. This will increase the interest and the penetration rate of new products and services into the Cloud Computing market.
The purpose of this paper is to present the application of the NIST CCRA in refining and supporting the design of the Cloud Computing architecture for a demonstration case in the AAL domain. The demonstration case is in the context of the AAL4ALL project [8], which aims the development of an ecosystem of AAL products and services. In this context we apply the NIST CCRA to the AAL4ALL
Logical Architecture [9]. We use a method to verify, identify, and elicit requirements
related with Cloud Computing functions and activities that must be assured by the AAL4ALL Central Platform, in order to enable the availability of AAL cloud-based services.
The remainder of this paper is organized as follows: section 2, provides an overview of main concepts about reference models, logical architectures, process architectures and Cloud Computing, NIST CCRA and some related projects; section 3, describes a method to apply the NIST CCRA to logical architectures; section 4, presents the application of the method to a real case in the AAL domain, namely in the AAL4ALL [8] project; section 5, presents the conclusions of the work and future developments.
2
Background and Related Work
Nowadays, the size and complexity of information systems, together with critical time-to-market needs, demand new software engineering approaches to the design of software architectures. One of these approaches, is the use of reference models that allows to systematically reuse knowledge and components when developing a concrete reference architecture [10]. As defined by [2], a reference architecture is an abstract framework for understanding significant relationships among entities of some environment and for the development of consistent standards or specifications supporting that environment. A reference model is not directly tied to any standards, technologies, or other concrete implementation details, but it does seek to provide common semantics that can be unambiguously used across and between different implementations.
A logical architecture can be considered a view of a system composed of a set of problem-specific abstractions supporting functional requirements [11, 12]. The logical architecture acts as a common abstraction of the system, providing a representation to facilitate its comprehension by all stakeholders regardless their background. The requirements for process-level can be also represented in a logical architecture [11]. The process-level architecture represents the fundamental organization of service development, service creation, and service distribution in the relevant enterprise context. Process architecture is an arrangement of the activities and their interfaces in the process. It takes into account some non-functional requirements, such as performance and availability, and it can be represented with components, connectors, systems, components and connectors, ports, roles, representations and rep-maps, as well as Architectural Elements (AEs) [11].
Taking into account the scope of this work, we focus on the NIST CCRA (Fig.1) [5], which is the most known and used Cloud reference architecture by the ICT industry.
NIST defines Cloud as a computing model that allows ubiquitous and on-demand access to a set of configurable computing resources (i.e., communications networks, servers, storage, applications or services), available on the network, and that can be rapidly provisioned and updated with minimal management effort or service provider interaction. Five main features characterize a Cloud [1]: (1) on-demand self-service; (2) broad network access; (3) resource pooling and rapid elasticity; (4) three possible service models (Software-as-a-Service - SaaS, Platform-as-a-Service - PaaS, and
Infrastructure-as-a-Service - IaaS); (5) four possible deployment models (Private,
Public Cloud, Hybrid Cloud, Community Cloud).
NIST developed a logical extension of their Cloud definition by the development of the NIST CCRA (Fig.1). NIST CCRA is a generic high-level conceptual model that constitutes an effective tool for discussing the requirements, structure, and operation of the Cloud. It defines a set of actors, activities, and functions that support the development of Cloud architectures. It also enables the analysis of standards for security, interoperability, and portability.
Our analysis identified some approaches that use the NIST CCRA to define Cloud
functions and activities for other contexts. Other researches use NIST CCRA to analyse, improve, and design Cloud architectures. Few works [11, 12, 13] apply this model to define cloud-based infrastructures and services.
Research [13, 14] performed at University of Amsterdam developed the
InterCloud [15] Architecture Framework (ICAF) [13, 14]. ICAF intends to address
problems with multi-domain heterogeneous applications, integration, and interoperability, including the integration with legacy ICT infrastructures services. It also facilitates the interoperability and management of inter-provider Cloud
infrastructures federation. ICAF uses NIST CCRA and defines additional functionalities that are required by heterogeneous multi-provider InterCloud services for integration and interoperability. In [16], it is presented the application of NIST and IBM [17] CCRAs in order to design another Cloud reference architecture. The resulting architecture has a more comprehensive explanation that includes more actors and components that are involved in a Cloud context. The proposed Cloud
architecture uses the same method used by NIST [4] to explains the main components and activities.
3
Using the CCRA to Refine Logical Architectures
The main goal of our approach is to specify cloud-based architectures by the application of a CCRA to refine logical architectures. This approach enables us to analyse which logical architecture AEs comply with the reference model, to discover requirements for supporting Cloud, and to design Cloud architectures to support Cloud-based solutions and services for specific contexts. Our approach uses the NIST CCRA as reference model [11]. The use of the NIST CCRA enables the identification and correction of semantic incoherencies, and the identification and definition of
Cloud requirements. NIST CCRA also allows the design of architectures, definition of
services, and the systematization of candidate standards and protocols for Cloud
Fig.2 depicts the method of how to use the NIST CCRA in conjunction with logical architectures in order to analyse the suitability of the logical architecture with the reference model.
Fig.2. Method to refine logical architectures according to NIST CCRA
The following steps synthesize the application of the method:
•Step 1: Select the NIST CCRA Architectural Components (ACs) to analyse in
logical architecture. Fill the table with their NIST CCRA descriptions (column labelled with NIST CCRA Architectural Components) and respective AEs (column labelled with NIST CCRA Architectural Elements);
•Step 2: Analyse all logical architecture AEs and identify similar semantics with
NIST CCRA AEs selected in step 1. Through analysis and comparison of logical architecture AEs descriptions with NIST CCRA AEs descriptions, fill the table with logical architecture AEs related to NIST CCRA AEs. This analysis enables to complement the requirements elicitation efforts related with Cloud contexts;
•Step 3: Refine and develop a new iteration of the logical architecture. This
implies the redefinition of requirements and logical architecture AEs descriptions according to information in the table. Table information represents the matching of logical architecture AEs descriptions with NIST CCRA AEs descriptions. The alignment of logical architecture with NIST CCRA is assured by the development of a new iteration of the logical architecture, which results in a cloud-based logical architecture;
NIST CCRA Logical Architecture
Table to relate AEs
Fill table with NIST AEs Descriptions
Fill table with Logical Architecture AEs Descriptions
Refinement and development of new iteration of the Logical Architecture
Fill table with new Logical Architecture AEs descriptions
NIST CCRA Architectural Components (ACs)
NIST CCRA Architectural Elements (AEs)
LOGICAL ARCHITECTURE Architectural Elements (AEs)
Table to relate AEs
NIST CCRA Architectural Components (ACs)
NIST CCRA Architectural Elements (AEs)
LOGICAL ARCHITECTURE Architectural Elements (AEs)
Mapping Logical Architecture AEs to NIST CCRA according to table information
CCRA NIST-Based (for Specific-Domain)
•Step 4: Fill the table with the new logical architecture AEs descriptions
(resulting from the refinement of the first logical architecture) and associate with NIST CCRA AEs and ACs in the respective columns;
•Step 5: Map the logical architecture AEs to NIST CCRA AEs according to the
information in the table resulting from step 4. The correct assignment of the logical architecture AEs to NIST CCRA AEs allows to realize the application of the CCRA model in the context of the considered logical architecture. The result is an architectural model organized and contextualized with Cloud functions and activities according to NIST CCRA.
4
The AAL4ALL Demonstration Case
We demonstrate the applicability of the proposed approach by using a case study in a real project, namely the AAL4ALL project [8]. The AA4ALL project is a mobilizing project that aims to enable the penetration of AAL products and services in the Portuguese market. This project includes the development of an interoperable ecosystem of AAL products and services supported by ICT systems. AAL4ALL consists of a system that allows the aggregation and integration of a broad range of systems of different suppliers and services, in order to ensure the availability and composition of AAL services provided to end-users.
4.1
Project Overview
The AAL4ALL system comprises a central platform and a local platform. The central platform aggregates, orchestrates, and processes the AAL services, making them available for use on a Cloud model. The local platform aggregates the local systems that support the local services. Fig.3depicts the elements of the AAL4ALL system. 1. AAL4ALL Central Platform: This platform ensures central integration of external
systems (i.e., healthcare systems from hospitals, transport management systems, social networking systems, etc.) and local systems (systems installed in the user environment). The composition, processing, and availability of AAL services are performed in a Cloud system that provides AAL4ALL services.
2. AAL4ALL Local Platform: This platform, viewed as a local gateway, interconnects the local systems (i.e., sensors, actuators, desktops, cameras, etc.) that capture information from the user environment and user health information. This platform is interconnects with the AAL4ALL Central Platform and provides the AAL local services.
Fig.3. AAL4ALL Cloud-based Ecosystem
4.2
AAL4ALL Logical Architecture
The AAL4ALL requirements are represented by use cases that describe the AAL4ALL functionalities that monitor the users routines and installed systems. The initial request for the AAL4ALL project requirements resulted in mixed and confusing sets of misaligned information. The discussions inside the project consortium relative to (1) the multi-domains to be covered, (2) the technologies, solutions and devices to be adopted, as well as (3) the uncertainty relative to interoperability issues (among others), resulted in a lack of consensus for the product-level requirements definition. Adopting a process-product-level perspective allows eliciting requirements in multi-domain ecosystems, as well as dealing with interoperability issues [9].
The rationale for the design of the models proposed in our approach, in the case of the AAL4ALL project, is based on specifying processes that intent to: (1) execute in a Cloud-based software solution; (2) deal with several AAL multi-domains; (3) support interoperability between solutions and devices. Since the AAL4ALL project aims at developing a unified AAL ecosystem by using a single platform for integrating and orchestrating the products, services, and devices. Therefore, the product-level requirements should reflect the integration of legacy systems, instead of a typical approach that elicits product-level requirements reflecting applications to be developed and their functionalities.
AAL4ALL Local Platforms
Environment User 1
1 Local Platform 1
2 N
Environment User 2
1 Local Platform
2
2 N
Environment User N
1 Local Platform
N
2 N
AAL devices/systems
External Platforms
External Cloud 1
External Cloud 2
External Cloud N
AAL4ALL Central Platform
(cloud-based)
The process-level requirements include all activities performed in the ecosystem and lead to the development of the process-level ALL4ALL logical architecture (Fig.4) by following the method presented in [11]. In opposition, the product-level requirements only regard interoperability needs.
Fig.4. Subset of the AAL4ALL process-level logical architecture
Non-functional requirements, such as systems integration, services interoperability, services performance, data security, and privacy, should be considered critical in AAL solutions, mainly when solutions are implemented in a Cloud-based architecture. The AAL4ALL platforms need to comply with those requirements as recommended by reference architectures.
Reference architectures and standards deal with non-functional requirements and provide best practices oriented to specific domains. A reference architecture can be also used to support non-functional requirements, since it is a framework that organizes system concepts taking into account the application domain characteristics or cross-cutting concerns [9]. Requirements elicitation should take into account domain reference architectures and standards.
4.3
Using the CCRA to Refine the AAL4ALL Architecture
The NIST CCRA does not represent the system architecture for a specific Cloud system. Rather, it is a tool for describing, discussing, and supporting the development of a system-specific architecture using a common reference framework for Cloud. Our approach uses the NIST CCRA to analyse and to elicit Cloud requirements, and to adapt the AAL4ALL Logical Architecture to a Cloud environment. It enables us to evaluate, identify, and include specific Cloud requirements for the AAL4ALL architecture. For simplicity of writing, the remainder of this document simply uses only the term AAL4ALL AE to express AAL4ALL Logical Architecture AE.The following paragraphs detail the application of the method explained in section 3.
Step 1: Select NIST CCRA AEs
We selected the components from the NIST CCRA for which we want to analyse the respective covering in the logical architecture. The selected components, depicted by Fig.5, are: (1) Software-as-a-Service (SaaS) Component, from Service Layer; (2)
{ P3 } M edic a l Ass i st a nc e { P3 .1 } M edic a ti on As s is t anc e {P1 } Ac tiv i ty Monitor ing {P2 } Non- Medi ca l As si s ta nc e
<<i nter face>> { AE0b. 1.1. i} Set M onit ori ng Confi gur at ions <<contr ol>> { AE0b.1. 2. c} Healt h M onit ori ng Deci sions <<cont r ol>>{AE0b. 1.3. c} Equi pment Mon it ori ng D eci sions <<contr ol>> {A E0b.1.4. c} Routi nes Moni tor i ng Decisi ons
<< co n tro l> > { AE 0 b. 3.2 .2 .c } Med ic at io n P re sc ri pt ion D ec is io ns < <c on tr ol> > { A E0 b. 3.2 .1 .c } R e mi nd S ch e du le s
{ P4 } H e al th y Li fe s ty le < <in te rf ac e> >{ AE 0 b.4 .2 .i} S et a H ea lt hy L ife st yle P lan < < co nt ro l> > { AE 0 b.4 .2 .c } L if es tyl e S er vic e Se le cti on D ec is io n << co n tro l> >
{ A E0 b. 2.1 .c 1} V ali da te Us er In d oo r Po si tio n << in te rfa ce > >{A E0 b. 2. 1.i } R e tu rn U se r P os it ion << co n tro l> > { AE 0 b.2 .3 .c 1} Va lid a te
U s er Ou td o or Po si tio n
« bla c k bo x»
{ A1 } Use r Tr a ck in g
{P6 } Human Dec is i ons < <d at a> >{ AE 0 b.4 .3 .1 .d } U se r´ s R eq u ire men ts D ec is io n
< <d at a> >{ AE 0 b.4 .3 .2 .d} D ef in e R es er va tio n s I nf or mat ion < <d at a> >{A E 0b .4 .3 .4. d} D e lin ea te a Vi sit P lan In fo rmat io n << da ta >>{ AE 0 b.4 .5 .d } D e fin e E du ca tio n al Se rv ice s In fo rma tio n
< < da ta >>{A E 0b .4 .4. 2. 3.d } D e fin e Vi de os In fo rma tio n < <d a ta> >{A E 0b .4. 4. 2.1 .d } De fin e N ews In fo rma tio n << da ta >>{ AE 0b .4 .4 .2. 2. d} De fin e Imag e s In fo rma tio n
< <d a ta> >{A E0 b .4. 4. 2.4 .d } D e fin e Me ss ag e s In fo rmat io n
< <d a ta> >{A E0 b .4. 4.3 .1 .d } D ef in e So ci al Ne two rk In fo rmat io n < < da ta >>{A E 0b .4 .2. d} H ea lth y Li fes ty le R e qu ir emen ts D e fin it ion
<< d ata > >{ AE 0b .4 .4 .1 .2. d} De fi ne E ve nt s S ch e du lin g In fo rma ti on { P6 .1 } U s e r D ec is i on s
<< da ta >>{A E 0b .3. 2. 1.d } De fi ne Me di ca tio n Sc he d uli ng In fo rma tio n << d ata > >{A E 0b .3 .2 .2. d} D efi ne Me dic at io n Pr es cr ipt io n In fo rma tio n < <d a ta> >{A E0 b. 3.3 .2 .d } U s er 's C ur re nt H ea lth C on d itio n D ec isi on < <d at a> >{ AE 0 b.3 .3 .3 .d} D ef in e Co n su lt Sc he du li ng I nf or mati on < <d at a> >{ A E0 b. 3.4 .d } R ec ov er y P la n R eq ui re men ts D ef in itio n {P 6 .3 } D o ct or D e c is io n s
<< da ta >>{A E 0b .3 .1 .1. d} H ome Eme rg en c y A le rt D e cis io ns < <d at a> >{A E 0b .3 .1. 2. d} Ou td o or Eme rg en cy Al er t D ec is io ns << da ta > > {A E 0b .4 .3 .3. d} U se r´s Mob ili ty Re qu ir eme nt s D ec isi on {P 6 .4 } C al l- C en te r D e c is io n s
<< da ta >>{A E0 b .1. 1.d 1 } Mo nit o rin g C o nf ig ur at io n D e cis io ns
<< da ta >>{ A E0 b. 1.1 .d 2} U se r Mo ni to rin g Co n fig ur at io n D e cis io ns
{P 6 .5 } Eq u ip me n t Pr o vi d er D ec i si o ns
{ P 3. 2 } R e ha b il ita t io n A ss is t an c e << in te rfa c e> > { AE 0 b.3 .4 .i} S et R ec ov ey P lan < <c on tr ol >>{ AE 0 b.3 .4 .c } R eh ab il ita tio n Se rv ic e S e lec tio n D ec is ion s
<< co nt ro l>>
{ AE 0b .4 .5. c} Ed uca ti on al Se rv ice s D e cis ion s
< <c on tro l> >
{ AE 0b .4. 4.3 .2 .c1 } Re gi ste r in we bs ite
{P 2 .2 } S oc i al iz a tio n
< <i nt erf ac e> >{A E0 b .1. 2.i } R e ce ive Cu rr en t In fo rmat io n < <i nt erf ac e> >{A E 0b .3 .1. 1.i } S en d E mer ge n cy A ler t
< <in te rf ac e> >{A E 0b .3 .2 .2. i} Ex ec ut e Me di ca tio n P res cr ip tio n << in te rfa ce >>{A E 0b .5. 1. i} S e nd A bn o rma l D et ec tio n
< < int er fa ce >>{A E 0b .5 .2. i} Co n fir m Ab n or mali ty < < int er fa ce >> { A E0 b. 2.2 .i} S ho w R o ut s < <in te rf ac e> >{ A E0 b. 4.3 .5 .i} Imp or t A L L Sy st em C on fig u ra tio n s
<< in te rfa ce >>{A E 0b .4 .4. 2. 1.i } S en d Co n te nt s
<< in te rfa ce >>{ AE 0 b.4 .4 .3 .5. i} In te ra ct io n o f Ga me < <in te rf ac e> >{A E0 b .4. 4. 3.3 .i} I nt era ct io n of mai lin g lis t i nf or mati on < < int er fa ce >>{A E 0b .4 .4 .3. 4.i } I nt era ct io n of C ha t in fo rma tio n < <i nt er fac e >>{A E 0b .4 .5. i} Ex ec ut e Ed uc at io na l S e rvi ce s < <i nt er fac e> >{A E 0b .4 .4. 3.2 .i } In ter ac tio n o f F or um in fo rmat io n << in te rfa ce > >{ AE 0 b. 4.4 .3 .1 .i} C o mmun ic at e wit h s o cia l n e twor k
< < int er fa ce >>{A E0 b. 3.3 .2 .i} C o mmun ic ate D ia gn o sis << in te rfa ce > >{A E0 b .4. 3.2 .i } E xe cu te R es erv a tio ns { P8 } S ys te ms Int er op er ab ili ty
{ P 5} A b n o rma li ty C omm un i ca ti o n < <c on tr ol >>{A E 0b .5 .2 .c} A bn o rmal ity D e tec ti on D ec is ion s << in ter fa ce >>{A E0 b .4. 1.2 .i } R ec ei ve H ea lth y Ca re
< < int er fa ce >>{A E0 b .4. 1.1 .i } A s sis ta n ce U se r´s So c ial C on d itio n
< <in te rf ac e> >{A E 0b .4 .1. 4. i} E x ec ut e Ho u se ke ep in g
< <in te rf ac e> >{A E 0b .4 .1 .5. i} Se t e rr an ds li st { P 2 .1 } H o me C a r e
< <c on tr ol >>{A E0 b .4. 3. 4.c } Va lid a te Vi sit P la n De ci sio n s
< < int er fa ce >> { AE 0 b.4 .3 .6 .i} R ed ef in e Vi sit In fo rma tio n < < co nt ro l> >{A E 0b .2. 2. c} D ef ine D is pla c emen t Su p po rt C on fig u ra tio n s < <c on tr ol> >{ A E0 b. 4.3 .2 .c } Re se rv at io ns D e cis io n s << co n tro l> >{ AE 0b .4 .3 .5. c} A AL S ys te m Impo rt D ec is io ns
< <c on tr ol >>{A E0 b. 4. 3.6 .c } V is it P lan R e de fin it io n De ci sio n s
<< co nt ro l>>
{A E0 b. 4.4 .1 .3. c} So cia l E ve nt S up po rt De cis ion s
<< in te rfa ce >>
{A E0 b. 4.4 .1 .3. i} S up po rt S oc ial Ev en t
< <c on tr ol> >{A E 0b .4 .3. 2.c 1} V er ify Sy st ems I nt ero p er ab ilit y
{P 2 .3 } Mo b ili ty << d at a> >{A E 0b .4 .1 .1. d} U se r´ s S oc ia l C o nd it ion Re q uir eme nt s
<< da ta >>{A E 0b .4 .1. 4.d } De fi ne H ou s e C le an in g De ci sio n
Business Support Component; (3) Provisioning and Configuration Component; (4)
Portability and Interoperability Component, from Cloud Service Management Layer;
(5) Security and Privacy Component.
Fig.5. Selection of NIST Components for Analysis
Step 2: Analyse AAL4ALL AEs
We use AAL4ALL architecture (Fig.4) artifacts to analyse its consistency with NIST CCRA and to adapt it to Cloud environment. The analysis look for the intersection of AAL4ALL AEs with NIST CCRA AEs in order to find similar semantics in their AEs descriptions. It uses a tabular representation to relate similar AEs.
Table 1 depicts an example of the way how similar AAL4ALL AEs, and NIST AEs are related. This table contain information about NIST CCRA ACs, NIST CCRA AEs, and AAL4ALL AEs. It illustrates the result of the matching between the AAL4ALL AE with reference {AE0b.1.2.c} Health Monitoring Decisions and the NIST CCRA AE with reference Monitoring and Reporting.
Table.1. AAL4ALL AEs and NIST CCRA AEs related
NIST CCRA Architectural Components
NIST CCRA Architectural Elements (AE)
AAL4ALL Architectural Elements (AE)
Provision and Configuration
Monitoring and Reporting
Discovering and monitoring virtual resources, monitoring cloud operations and events and generating performance reports.
{AE0b.1.2.c} Health Monitoring Decisions
According to the NIST CCRA AE Monitoring and Reporting description, the AAL4ALL AE with reference {AE0b.1.2.c} Health Monitoring Decisions
corresponds to monitoring operations, event monitoring, reporting activities, and service performance. The AAL4ALL Central Platform uses the monitored information (i.e., vital signs) to identify abnormal situations related with the health of the users. If an event occurs, the AAL4ALL Central Platform triggers a set of alerts and actions in order to provide the necessary support to the respective user, depending on the user health state. This is a typical scenario of a monitoring activity. Therefore, the AAL4ALL AE with reference {AE0b.1.2.c} Health Monitoring Decisions has similarities with the NIST CCRA AE that has the reference Monitoring and
Reporting. This justifies their relation in Table 1.
The analysis performed for all AAL4ALL AEs allows the construction of the architectural model represented by Fig.6. It results from the mapping of AAL4ALL AEs to the NIST CCRA AEs, according to the relationships established in Table 1.
The mapping task affected each AAL4ALL AE to the NIST layer that best complied with its functionality.
Fig.6. AAL4ALL AEs mapped to NIST CCRA AEs
The results of the analysis enabled us to evaluate and to identify specific Cloud
requirements for the elicitation phase. The mapping task allowed to find some limitations [9] on the AAL4ALL architecture relative to the NIST CCRA, such as: (1) the lack of AEs related to business support; (2) the lack of AEs related to security and privacy; (3) AEs with semantics that are not fully compatible with the NIST CCRA.
The analysis performed enabled to complement the requirements elicitation efforts and to redefine the AAL4ALL architecture, giving rise to a new version of the cloud-based AAL4ALL architecture (Fig.7). These results justified the execution of a new iteration on the definition of the AAL4ALL architecture [9].
Fig.7. NIST based AAL4ALL Logical Architecture
Step 4: Fill the table with new logical architecture AE descriptions
In this step we filled the table (similar to the example in Table 1) with AE descriptions of the new AAL4ALL cloud-based, and associated the NIST CCRA AEs and ACs in the respective columns; this facilitated the mapping of AAL4ALL AEs to NIST CCRA AEs.
Step 5: Mapping AAL4ALL AEs to NIST CCRA AEs
The correct assignment of AAL4ALL AEs to NIST CCRA AEs results in the CCRA model for the AAL4ALL project, viewed as a conceptual architecture. AAL4ALL CCRA is organized and contextualized with Cloud functions and activities according to the NIST CCRA. Fig.8 depicts the cloud-based AAL4ALL conceptual architecture.
AAl4ALL Logical Architecture NIST Reference Architecture
Fig.8. AAL4ALL Cloud Conceptual Architecture derived from NIST CCRA
The resulting architecture presents the logical separation of the features of the three main Cloud services layers for AAL4ALL, derived from NIST CCRA, namely
the AAL4ALL Services Layer, Resource Abstraction and Control Layer, and Physical
Layer.
AAL4ALL Services Layer consists of the main services that are available to
AAL4ALL ecosystem, namely:
1. Presentation Services - expose to the users the AAL services from
AAL4ALL Central Platform, providing access to application functionalities organized in an intuitive way and made available to end users; they cover the main AAL services areas, namely: (1) Independent Living Services; (2)
Health and Care Services; and (3) Recreation in Life Services.
2. AAL4ALL Cloud Services: present the specific domain AAL services
divided by the categories: (1) Assistance and Emergency Medical Services; (2) Home Assistance Services; (3) Mobility Assistance Services; (4) Social
Assistance Web Services.
3. AAL4ALL Cloud Services Management: includes all functionalities related
to services provided by AAL4ALL Central Platform at management and operations of AAL services subscribed by AAL4ALL services consumers. This sub-layer is structured in the following service categories:
• Business Support Services: Composed by services that support the
services payment, and contract management). These services ensure the customer life-cycle management in the AAL4ALL ecosystem.
• Operations Support Services: Composed by services that support the
AAL4ALL service operations related to customer services provisioning and operation, services and equipment setup and maintenance, software and firmware upgrades, and service and equipment monitoring, among others.
• Interoperability Services: composed by services that ensure the
services interoperability and systems integration.
4. Security and Privacy Layers are important aspects in cloud-based solutions
that must address security requirements in their architectures across all layers of architecture, from the application layer to the physical layer. AAL4ALL security services include non-functional requirements such as authentication, authorization, availability, confidentiality, integrity, incident management, and information security monitoring. Privacy services ensure the mechanisms for collecting user information securely, properly, and consistently.
Resource Abstraction and Control Layer ensures the union of the underlying
physical resources and software resources, allowing the resource pooling and dynamic resource allocation as well the access control to Cloud services.
Physical Layer includes all the features of the physical layer (hardware), such as
computing (CPU and memory), network (routers, firewall, network interfaces, data storage components (hard disks), among other elements at the physical infrastructure. It also includes resources at the installation level (facility), such as cooling systems, and communications, among others.
5
Conclusions and Future Work
This paper demonstrates how to use the NIST CCRA to support the design of Cloud
architectures that enable the design of cloud-based solutions and services for specific contexts, through the refinement of logical architectures.
We present a demonstration case that shows the use of NIST CCRA to refine the design of the AAL4ALL architecture to support the specification of cloud-based services, through the association of the AAL4ALL AEs to corresponding NIST CCRA AEs with similar semantics. The comparison of AEs descriptions enables the identification of compatible AEs. A tabular representation associates each AAL4ALL AE to a related NIST CCRA AE. The result of the analysis allowed complementing the efforts of requirements elicitation and the alignment of AAL4ALL architecture with Cloud requirements according to NIST CCRA.
The association of the AAL4ALL AEs into NIST CCRA AEs enabled to apply the CCRA to the AAL4ALL project and to specify the main layers of AAL4ALL services derived from NIST CCRA, more specifically: (1) AAL4ALL Services Layer; (2) Resource Abstraction Layer and Control Layer; (3) Physical Layer.
References
1. Mell, P., Grance, T.: The NIST Definition of Cloud Computing. NIST Special Publication 800-145, NIST (2011)
2. OASIS: Reference Model for Service Oriented Architecture 1.0. MacKenzie, C., Laskey, K., Brown, P, Metz, K. (eds.). OASIS Open (2006)
3. Anbarasu, A.: Cloud Reference Architecture. White paper, Oracle (2012) 4. Bohn, R., Messina, J., Liu ,F., Tong, J., Mao, J.: NIST Cloud Computing
Reference Architecture. In: 2011 IEEE World Congress on Services (SERVICES), pp.594,596. IEEE Computer Society (2011)
5. Liu, F., Tong, J.; Mao, J.; Bohn, R.; Messina, J.; Badger, M.; Leaf, D.: NIST Cloud Computing Reference Architecture. NIST Special Publication 500-292, NIST (2011)
6. Van Den Broek, G., Cavallo, F., Wehrmann, C.(eds.): AALIANCE Ambient Assisted Living Roadmap. IOS Press, Amsterdam, The Netherlands (2010)
7. Lee, K., Lunney, T., Curran, K., Santos, J.: Proactive Context-Awareness in Ambient Assisted Living,
http://scisweb.ulster.ac.uk/~kevin/ICADIpap.pdf
8. AL4ALL Project - Ambient Assisted Living for All, http://www.aal4all.org/
9. Santos, N., Teixeira, J., Pereira, A., Ferreira, N., Lima, A., Simões, R.,Machado, R.J.: A Demonstration Case on the Derivation of Process-Level Logical Architectures for Ambient Assisted Living Ecosystems. In Garcia, N., Rodrigues, J., Dias, M.S., & Elias, D. (eds.) Ambient Assisted Living Book. Taylor and Francis / CRC Press (USA) (Accepted for publication)
10. Martínez-Fernández, S., Ayala, C., Franch, X., Marques, H., Ameller, D.: A Framework for Software Reference Architecture Analysis and Review,
http://www.essi.upc.edu/~dameller/wp-content/papercite-data/pdf/martinez-fernandez2013.pdf
11. Ferreira, N., Santos, N., Machado, R., Gaševic, D.: Derivation of Process-Oriented Logical Architectures: An Elicitation Approach for Cloud Design. In: Oscar Dieste, Andreas Jedlitschka, Natalia Juristo (eds.), Product-Focused Software Process Improvement. LNCS, vol. 7343, pp. 45-58. Springer-Verlag, Berlin Heidelberg, Germany (2012) 12. Kang, S., Choi, Y.: Designing Logical Architectures of Software
Systems. Sixth Int. Conf. Softw. Eng. Artif. Intell. Netw. Parallel/Distributed Comput. First ACIS Int. Work. Self-Assembling Wirel. Networks. 330–337 (2005)
13. Demchenko, Y., Makkes, M.X., Strijkers, R., De Laat, C.:"Intercloud Architecture for interoperability and integration.. In: IEEE 4th International Conference on Cloud Computing Technology and Science (CloudCom), pp.666-674, IEEE Computer Society (2012)
W. Zimmermann, Y.W. Lee & Y. Demchenko (eds.), Third International Conference on Cloud Computing, GRIDs, and Virtualization, pp. 174-180, IARIA, Wilmington (2012)
15. Jrad, F., Tao, J., Streit, A.: SLA based Service Brokering in Intercloud Environment. In:Proceedings of 2nd International Conference on Cloud Computing (CLOSER 2012), SciTePress (2012)
16. Amanatullah, Y., Lim, C., Ipung, H.; Juliandri, A.: Toward cloud computing reference architecture: Cloud service management perspective. In: 2013 International Conference on ICT for Smart Society (ICISS), pp.1-4 (2013)
