NESSI Open Framework Reference Architecture€¦ · NEXOF-RA • FP7-216446 • D1.1c Appendix A...

NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • of 105

NEXOF-RA

NESSI Open Framework – Reference Architecture

IST- FP7-216446

Deliverable D1.1c Appendix A

Contribution to other WPs

N. Tsouroulas (TID) Jose M. Cantera (TID)

José L. Díaz (TID)

Due date of deliverable: 15/06/2010

Actual submission date: 15/06/2010

This work is licensed under the Creative Commons Attribution 3.0 License.

To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.

This work is partially funded by EU under the grant of IST-FP7-216446.


Change History

Version Date Status Author (Partner) Description

1.0 15/06/2010 draft TID Initial Version


EXECUTIVE SUMMARY

This document captures the contributions made from WP1 (Advanced User-Service Interactions) to the rest of WPs, particularly to WP7 (Reference Architecture). This contribution has been divided into:

Contribution to guidelines and principles. Including the detailed set of terms that WP1 has contributed to the glossary of WP6 on the presentation area.

Contribution to the reference specification. This chapter reports on the high level requirements and functionalities identified for the presentation concern of NEXOF-RA. It includes the identified use cases to put together the main concepts, a description of system requirements and functionalities that should offered by NEXOF-RA.

Patterns. It contains the patterns elaborated by WP1, related to the presentation concern:

Front-End in E-SOA. This pattern is a refinement of the ―Designer and Runtime Tools for E-SOA‖ one. Concretely, it focuses on the functionalities provided by software components that are responsible for the design and execution of artefacts devoted to the NEXOF presentation

Mashup as a service. In the context of the Internet of Services, this pattern suggests an architecture intended to enable end-user composition of heterogeneous Service Front-End Resources, yielding to Service Front-End Mashups.

Context of Use Management. This pattern describes the architecture of a component able to detect, represent and provide the information about the Context of Use (User, Platform and Environment) for SFEs.


Document Information

IST Project Number

FP7 – 216446 Acronym NEXOF-RA

Full title NESSI Open Framework – Reference Architecture

Project URL http://www.nexof-ra.eu

EU Project officer Arian Zwegers

Deliverable Number D1.1c Appendix A

Title Advanced User-Service Interactions contributions to Model and Specifications

Work package Number WP1 Title Advanced User-Service Interactions

Date of delivery Contractual 15/06/2010 Actual 15/06/2010

Status Versión 1, dated 15/06/2010 final

Nature Report Demonstrator Other

Abstract (for dissemination)

Keywords Internet of Services, User Interface, Service Front-End, Model-Based, Composition, Context-Awareness

Internal reviewers Reviewer1 (Organization)

Reviewer2 (Organization)

Authors (Partner) Jose M. Cantera (TID), José L. Díaz (TID)

RESPONSIBLE

AUTHOR José M. Cantera (TID) Email [email protected]

Partner Phone

http://www.nexof-ra.eu/


TABLE OF CONTENTS

EXECUTIVE SUMMARY ........................................................................................... 3

TABLE OF CONTENTS ............................................................................................ 5

1 CONTRIBUTION TO GUIDELINES AND PRINCIPLES .................................................. 7

2 CONTRIBUTION TO THE REFERENCE SPECIFICATION ........................................... 10

2.1.1 Introduction ...................................................................................... 10

2.1.2 Analysis of System Requirements .................................................... 10

2.1.3 Usage Scenarios .............................................................................. 12

2.1.4 System Requirements for the Presentation Concern ....................... 15

2.1.5 Presentation Functionalities ............................................................. 18

3 PATTERNS ....................................................................................................... 27

3.1 Front-End in E-SOA Pattern ................................................................... 27

3.1.1 Pattern ID-Card ................................................................................ 27

3.1.2 Problem Description ......................................................................... 27

3.1.3 Functional Requirements ................................................................. 30

3.1.4 Non-Functional Qualities (Quality Attributes) ................................... 33

3.1.5 Assumptions ..................................................................................... 35

3.1.6 Solution ............................................................................................ 36

3.1.7 Relationships to other patterns ......................................................... 53

3.1.8 Relationships to Components Catalogue ......................................... 54

3.1.9 Relationships to Standards Catalogue ............................................. 55

3.1.10 Application Examples ..................................................................... 56

3.2 Mashup as a Service Pattern .................................................................. 57

3.2.1 Pattern ID-Card ................................................................................ 57




3.2.5 Assumptions ..................................................................................... 62

3.2.6 Solution ............................................................................................ 62

3.2.7 Relationships to other patterns ......................................................... 76

3.2.8 Relationships to Components Catalogue ......................................... 76

3.2.9 Relationships to Standards Catalogue ............................................. 76

3.2.10 Application Examples ..................................................................... 77

3.3 Context of Use Management Pattern ...................................................... 78

3.3.1 Pattern ID-Card ................................................................................ 78





3.3.5 Assumptions ..................................................................................... 83

3.3.6 Solution ............................................................................................ 84

3.3.7 Relationships to other patterns ....................................................... 101

3.3.8 Relationships to Components Catalogue ....................................... 102

3.3.9 Relationships to Standards Catalogue ........................................... 102

3.3.10 Application examples ................................................................... 103

REFERENCES ................................................................................................... 104


1 CONTRIBUTION TO GUIDELINES AND PRINCIPLES

WP1 has contributed a set of terms to the glossary of WP6 on the presentation area:

Service Front-End Component: a SFE Component is a UI Component that makes it possible the interaction between a human user and one or several software services. SFE Components can be registered in a SFE Catalogue, making them available to other potentially interested users.

Service Front-End Component Description: This concept represents all the metadata that allows to describe a SFE Component, thus enabling its registration in a SFE Catalogue.

Service Front-End Catalogue: a registry that holds descriptions about different SFE Components. Such components can be used and composed by different users. A SFE Catalogue enables the selection and discovery of SFE Components within a SFE Mashup Platform.

Service Front-End Resource: this concept represents a kind of SFE Component that plays also the role of a Software Component within the NCI (UI Component). SFE Resources can be standalone, full applications or gadgets (according to the terminology introduced by EzWeb) ready to be composed with other SFE Resources, yielding to SFE Mashups.

Service Front-End Mashup: A SFE Mashup is a SFE Component which is the result of the composition of two or more SFE Resources. In this context composition means that the different SFE Resources are capable to interchange data between them and to react accordingly to such data interchange.

Service Front-End Workspace: A SFE Workspace acts as the container of a SFE Mashup. A SFE Workspace is created and owned by a user. Mash-up Designers create new SFE Mashups within a SFE Workspace. End users interact with SFE Mashups through a SFE Workspace.

The Abstract User Interface (AUI) is an expression of the UI in terms of interaction spaces (or presentation units), independently of which interactors are available and even independently of the modality of interaction (graphical, vocal, haptic …). An interaction space is a grouping unit that supports the execution of a set of logically connected tasks.

The Concrete User Interface (CUI) is an expression of the UI in terms of ―concrete interactors‖, which are, in fact, an abstraction of actual UI components (a.k.a widgets) generally included in toolkits. The placement of these concrete interactors is also specified.

The Final User Interface (FUI) consists of source code, in any programming language or mark-up language (e.g. Java or XHTML). It can then be interpreted or compiled. A given piece of code will not always be rendered on the same manner depending on the software environment (virtual machine, browser …). For this reason, we consider two sublevels of the FUI: the source code and the running interface.


Domain Model, a description of the information entities (and their relationships) viewed or manipulated by the user. It includes objects storing data that will be displayed or that will be modified by the user, or objects with methods that can be called from the UI or that can modify some aspect of the UI.

Task Model, a formal description of the tasks carried out by a user in interaction with the system. This model can be understood as a generic representation of the envisioned scenarios that were elicited during the requirements analysis. It has generally a hierarchical structure and additional constraints and information about the tasks (such as ordering, launching conditions, associated objects and functions) can be added.

Aui Model (Abstract User Interface) which describes canonically a user interface in terms of abstract interactors, containers and their relationships, in a way that is independent from the concrete interactors available on the targets. In practical terms this means that an abstract user interface model is platform and modality-independent.

Cui Model (Concrete User Interface) is a detailed specification of the appearance and behaviour of the UI elements for a concrete platform (desktop, PDA, mobile, etc.) and / or modality (visual, aural …). Although a Concrete UI Model makes explicit the final look and feel of the user interface, it is still a description independent of the toolkit or the execution environment (Java-Swing, Web, VoiceXML …) on which the UI will be finally executed.

Behaviour Model which describes the set of reactions of the user interface to events, such as user interactions, changes in the system state, period of time elapsed, and the like. These events trigger actions, such as method call or a transition to a target container, provided that certain conditions are met.

Mapping Model serves to establish relationships between models or elements of models (for example, between a task belonging to the task model and the widget of the CUI that permits the execution of this task).

Context is any information that can be used to characterize the situation of entities (i.e. whether a person, place or object) that are considered relevant to the interaction between a user and an application, including the user and the application themselves. Context is typically the location, identity and state of people, groups and computational and physical objects

Context-Awareness the ability of applications and services to adapt their behaviour, interface or contents to the target Context, providing a more consistent and effective interaction.

“Context of Use” a dynamic, structured information space that includes a model of the user, U, (who is intended to use or is actually using the system), the hardware-software platform (delivery context), P, (which includes the set of computing, sensing, communication, and interaction resources that bind together the physical environment with the digital world), and the social and physical environment, E, (where the interaction is actually taking place). Thus, a context of use is a triple composed by (U, P, E).

“Context Of Use Meta-model”, which captures the ―Context of Use of an interactive system‖.


The “Platform (Delivery Context) Model” provides a formal model of the characteristics (and situation) of the hardware, software and network platform(s), that is, the computational, interaction and communication Components that are used for perceiving and interacting with a NEXOF-RA-compliant system.

The “Environment Model” describes any property of interest of the global environment where the interaction takes place. The properties might be physical (e.g. lighting or noise condition) or psychological (e.g. level of stress)

The “User Model” captures all the variables and characteristics that have to do with the human being (or a human stereotype) which it is interacting with the application. The characteristics modelled or relevant can be very dependant on the application domain. Specific examples are age, level of experience, the permissions, preferences, tastes, disabilities, short term interests, long term interests, etc.


2 CONTRIBUTION TO THE REFERENCE SPECIFICATION

2.1.1 Introduction

This chapter reports on the high level requirements and functionalities identified for the presentation concern of NEXOF-RA (service front-end). It includes the identified use cases to put together the main concepts, a description of system requirements and functionalities that should offered by NEXOF-RA.

2.1.2 Analysis of System Requirements

To determine system requirements, a preliminary analysis was conducted. The rationale for such analysis has been discussed on the previous chapter. We followed a simple method (participated by NSPs, NCPs and contributing projects) based on questions and answers, which it is summarized below:

UI_ACC - How SOA-based systems can be accessed by users?

SOA-based systems should provide an access layer which will be in charge of both rendering the user interface as per the Context characteristics and supporting the interaction between humans and the system.

UI_COMP - How users can compose their own, personalized interface?

It is necessary to devise a new SOA front-end capable to provide an environment which empowers end-users to easily use, customize, contribute, enhance and compose services coming from different providers.

UI_COMP_DES - How users can design their own operating environments?

There should be browsing and selection facilities that will allow end-users to browse and select the resources of their interest, putting them in their operating environment, thus enabling further interactions.

UI_COMP_PUB - How users can publish new service front end resources?

There should be upload functionalities that will allow service front-ends creators to add new service front-end resources to the SFE catalogue, making them available to the community. A Service Front-End Resource (SFER) is a resource (or a collection of them) that implements the user interface and application logic necessary to interact with one or more underlying services. To upload a new SFER it will be necessary to provide a descriptor (template) with all the metadata and deployment information.

UI_COMP_FIND - How users can find service front end resources?

There should be a search and recommendation capabilities that will make it possible to locate and discover those service front-end resources that satisfy the necessities of end-users at a given moment. This search application should be intelligent, recommending the most suitable resources in a given Context. For example, the set of pieces found in a SFE catalogue should be different when the end-user is at work than when is at home or on vacation.


UI_COMP_CON - How users can connect service front end resources?

Users should be able to connect, graphically for example, the different service front end resources present in an operating environment. Such connections are normally aimed to share data.

UI_KNOW - How user’s knowledge can be captured and exploited?

New generation SOA front-ends should embrace the Web 2.0 principles, exploiting user’s collective intelligence and domain knowledge. Service front-ends should be in charge of knowledge capture and further exploitation, as they are the architectural components that deal with user interaction. Thus, new challenges appear with respect to user’s knowledge gathering, representation and integration with formal knowledge.

UI_CTX - How service front ends can adapt to the target Context?

Service front-ends should adapt seamlessly to the target environment, providing a harmonized user experience in every device, network or situation.

UI_DEV - How users can develop their own service front end resources?

Users should be able to create their own applications by combining different pieces without any help from IT experts or deep knowledge about the underlying infrastructure.


2.1.3 Usage Scenarios

After the preliminary analysis of high level requirements, usage scenarios where analysed in order to identify additional functional and to refine system requirements.

2.1.3.1 Service Front End Resource Creation

This scenario describes the creation of a new Service Front End Resource. The SFER is created by the user using a SFER Authoring tool, such as the one provided by the FP7 FAST project [FAST]. Once the service is developed and tested it is deployed and finally published.

Creation SFER

SFER Design

SFER Implementation

SFER Publication

[Requirements]

[SFE Resource]

Figure 1: Service Front End creation scenario

2.1.3.2 Service Front End Composition and publication

This scenario, contributed by the EzWeb project, describes the creation of a new Service Front End, and the publication of its workspace. The user creates one or more workspaces composed by several SFER found in an SFE Catalogue. To design each workspace the user need to select the resources of his interest (by means of searching, browsing or automatic recommendation). Once a SFER has been placed on the workspace they can be connected in order to share data. The user can publish the workspace to make it available to other users.


Mashup Creation

SFER Search

SFER Selection

SFE Workspace Design

SFER Connection

[SFE Component (Mashup)]

SFE Publication

Figure 2: Service Front End composition and publication scenario

2.1.3.3 Service Front End Access

This scenario, contributed by the EzWeb project, describes how a user gets access to and interacts with Service Front Ends. First a user connects to a SFE access point and selects one SFE Workspace of his interest. Then this SFEW is presented as per the Context characteristics. At the same time, each resource or application that takes part in such workspace is rendered and adapted to the Context characteristics. The next step consists of the SFEW delivery along with its composing SFER. Finally, end-users will interact with the SFEW and SFER. Such interaction might be monitored, in order to capture and extract user knowledge.


SFE Execution

SFE Acesss

SFE Rendering

SFE Delivery

SFE Connection Management

Contextual Adaptation

[Delivery Format]

Figure 3: Service Front End access scenario


2.1.4 System Requirements for the Presentation Concern

The figure below outlines different system requirements for the Presentation concern of NEXOF-RA. They have been contributed by EzWeb and MyMobileWeb. Such requirements have been divided into specific functionalities described on the next section.

System

User

SFE Access

SFE Composition SFE Workspace Design

SFER Connection

SFER Search

Contextual Adaptation

Knowledge Capture

SFER Creation

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

SFER Recommendation

<<extend>>

SFER Publication

<<include>>

SFE Workspace Publication

<<include>>

Figure 4 User and Client Interactions concern use cases

SR name: End-User access to Services (Service Front-End)

SR description: SOA-based systems should provide an access layer which will be in charge of both rendering the user interface as per the Context characteristics and supporting the interaction between human beings and the system.

Related Business Requirement(s):

R36 Execution of Human-Based Process Steps

R2 Uniform service representation


SR name: Context Management

SR description: The system should be capable of sensing, representing, manipulating and reasoning over contextual information, enabling context-awareness. The following Context facets are under scope:

User Profile: global preferences, long-term and short-term interests, skills and social network

Delivery Context: device, network, user agent and local settings (font size, volume, brightness …)

Environment: location and moment in time Related Business Requirement(s):

L7.8 Environmental Data Collection

L1.10 Mobile Users

L7.13 Adaptability

SR name: Service Front-End Contextual Adaptation

SR description: Service front-ends should be context-sensitive. A context-sensitive service front-end is a service front-end that exhibits some capability to be aware of the context (context awareness) and to react to changes of this context immediately. As a result users will be supported in a more effective, personalized and consistent way. Related Business Requirement(s):

L1.10 Mobile Users

L7.13 Adaptability

R15 Adaptive Deployment

R20 Device Integration / Vertical Integration

R35 Information as a Service

SR name: End-User Composition of Personalized User Interfaces

SR description: The system should provide an environment which empowers end-users to easily find, select and combine application user interfaces coming from different providers. As a result, users will be able to design their own personalized operating environment aimed at solving their daily life problems.


R11 Services integration by semantic mash-up

R17 Aided Configuration

R18 Modelling Capabilities

R37 Information Integration

R30 Integration of Services


SR name: User-Generated Service Front-Ends

SR description: Users should be able to create their own application user interfaces by combining different ―high level pieces‖ without any help from IT experts or deep knowledge about the underlying infrastructure.



R18 Aided Configuration

R36 Execution of human-based process steps

SR name: Model-Based Engineering of Multi-Target, Context-Aware User Interfaces

SR description: NEXOF should provide model-based advanced authoring tools that allow engineers to create context-aware application user interfaces with a minimum effort.



R36 Execution of human-based process steps

R18 Modelling Capabilities

SR name: Service Front-End Publication

SR description: There should be publication functionalities that will allow service front-ends creators to deploy, add and share new resources through a public catalogue, making them available to the community.


L1.2 Publication APIs

L1.4 Push mode publication mechanisms

L1.5 Pull mode publication mechanisms

R6 Service deployment

SR name: User’s Knowledge Exploitation

SR description: User behaviour (in terms of interaction patterns with services) should be monitored. As result, new knowledge will be automatically acquired enabling the inference of new processes suitable to be later automated. In addition new information about the User Context will be known (and ready to be exploited) by the system.



L7.3 History based monitoring

L7.5 Environmental Monitoring

L7.8 Environmental Data Collection

L7.14 Monitoring process

2.1.5 Presentation Functionalities

The presentation concern should support the functionalities described below:

Functionality name: Creation of User Interface Components

Description: This functionality will allow the design and implementation of the user interface components, including the creation of individual SFER and the composition of them creating a Mashup.

Further Decomposition: Creation of SFER, Mashup Creation.

Related system requirements:

End-User Composition of Personalized User Interfaces

Service Front-End Publication

User-Generated Service Front-Ends

Source: EzWeb NSP

Functionality name: Creation of SFER

Description: This functionality will allow the creation of a SFE Resource, which includes the design and implementation of the SFER as well as the SFER publication.

Further Decomposition: SFER Design, SFER Implementation, SFER Publication




Source: EzWeb NSP

Functionality name: Mashup Creation

Description: This functionality will allow the creation of a Mashup, which includes the search and selection of individual SFER, the design of the workspace, including the connection of SFER as well as the publication of the result (Mashup).

Further Decomposition: SFER Search, SFER Selection, SFE Workspace Design, SFER Connection, SFE Publication






Source: EzWeb NSP

Functionality name: Execution of User Interface Components

Description: This functionality is aimed at rendering service front-end (SFE) resources and providing the results of the execution of the services invoked by that SFEs. It also deals with the connections between the SFEs that allows information exchange at the level of Interface Components.

Further Decomposition: Service Front-End Rendering, SFE Delivery, SFE connection management


End-User Access to Services

Service Front-End Contextual Adaptation

Source: EzWeb NSP

Functionality name: Context-Aware Resource Discovery

Description: There should be browse / search / recommendation capabilities that will make it possible to browse, locate and discover (in a context-aware manner) those service front-end resources that satisfy the necessities of end-users at a given moment.

Related functionalities:

Workspace Design

Related requirements:

Context Management



Source: EzWeb Strategic Project Contribution

Functionality name: Resource Publication

Description: This functionality will allow users to publish their resources in a Catalogue thus making them available to other communities.


Resource Creation


Resource Sharing

Resource Deployment





Functionality name: Resource Deployment

Description: This functionality will allow to deploy service front-ends in a Service Oriented Infrastructure.


Resource Sharing

Resource Publication

Resource Creation





Functionality name: Resource Sharing

Description: This functionality will allow users to share service front-end resources with other members of the Community, thus promoting reuse through collaboration.


Resource Publication

Resource Deployment

Resource Creation

Workspace Design

Resource Creation





Functionality name: Workspace Design and Personalization


Description: This functionality will allow the design of the user operating environment(s) by selecting, connecting and composing different service front end resources. An operating environment will be devoted to solve a specific user problem and will involve several Service Front-End Resources that will give access to different Services.


Context-Aware Resource Discovery

Resource Publication and Sharing




Functionality name: User-Oriented Resource Authoring Tool

Description: An advanced authoring tool should assist non-technical users in the generation of new front-end resources.


Resource Publication and Sharing

Model-Based Engineering



Source: FAST Project Contribution

Functionality name: Model-Based Engineering Tools and Formalisms

Description: This functionality will offer a set of tools that will make it easier the engineering and development of multi-target, context-aware application user interfaces. An important formalism to be supported will be a declarative language for the description of context-aware, multi-target user interfaces at different levels of abstraction.


User-Oriented Resource Authoring Tool


Model-Based Engineering of Context-Aware User Interfaces

Source: UsiXML Project Contribution

Functionality name: Service Front-End Rendering

Description: This functionality is aimed at rendering service front-end resources. Rendering is the act of converting a user interface model into a


delivery format that can be directly interpreted by a client platform, such as a Web Browser or similar.


Query Contextual Information

Automatic Resource Transcoding

Content & Application Adaptation




Source: Defined in the Declarative UI Authoring Investigation Team

Functionality name: Query Contextual Information

Description: It will be possible to query the Context Framework in order to know the values of Context properties (which may come from different Content Providers).


Subscription to Contextual Information

Connection to Context Providers


Context Management

Source: Standards (DDR Simple API [DDR Simple API] & DCCI [Delivery Context: Client Interfaces])

Functionality name: Subscription to Contextual Information

Description: This functionality allows front-end resources to be informed of Context Value changes.






Context Management

Source: Standard (DCCI [Delivery Context: Client Interfaces])

Functionality name: Identification of the target Context of Use

Description: This functionality enables the recognition of the target Context of Use at runtime.








Context Management

Source: Standard (DDR Simple API [DDR Simple API])

Functionality name: Context Reasoning

Description: NEXOF should provide a reasoning module capable of inferring new facts (or even new abstract contexts) from existing contextual information or knowledge.




Context Management

Source: NEXOF-RA WP1

Functionality name: Connection to Context Providers

Description: The system will provide the functionality to connect to a DDR (Device Description Repository) or other Context Providers.





Context Management

Source: Defined in the Context Models Investigation Team

Functionality name: Automatic Resource Transcoding

Description: Transcoding is the act of transforming a resource changing some of its properties to satisfy the restrictions imposed by the target Context of Use. For example, a change in the width and format of an image



Service Front-End Rendering




Source: Standard (OMA-STI [OMA05])

Functionality name: Content Adaptation and Personalization

Description: This functionality is aimed at performing all the contextual adaptations (guided by the adaptation policies expressed by authors or by semantics) at the pure presentation (content) level, taking into account the restrictions imposed by the Context of Use. The adaptations implemented by this module will include, but not limited to: paginations, font enlargement (for disabled users), graceful degradations, content / data reordering (to meet the contextual restrictions), extraction of the most important parts of a resource, and selecting the best content from a set of variants.



Application Adaptation and Personalization





Context Management

Source: Standard (DIAL [W3C04]) with contributions coming from the MyMobileWeb project

Functionality name: Application Adaptation and Personalization

Description: This functionality is aimed at performing all the contextual adaptations of a user interface at the application and presentation logic (behaviour) level. Adaptation policies expressed by authors or by semantics will guide the process which will be constrained by the characteristics of the Context of Use (including the user). The transformations implemented by this module will include, among others, modality variations, changes in interaction flows, variations on the usage of toolkits or frameworks, etc.


Content Adaptation and Personalization





Context Management


Source: Contribution from the MyMobileWeb project

Functionality name: Service Front-End Persistence

Description: This functionality will allow front-end resources to persist their state beyond the user session, thus being able to retrieve and restore it later.


Domain Model Management




Context Management

Source: Contribution coming from the EzWeb NESSI Strategic Project

Functionality name: Domain Model Management

Description: This functionality has to do with obtaining, maintaining and validating (as per the restrictions imposed by the domain model) the information managed by the user interface in a given moment.


Service Front-End Persistence


Domain Model and User Interface binding



Source: Standard (XForms 1.1 [XFORMS])

Functionality name: Domain Model and User Interface binding

Description: This functionality enables the connection between the user interface components (interactors) with the information present in the domain model.


Domain Model Management



Source: Standard (XForms 1.1 [XFORMS])

Functionality name: Interaction Management


Description: This functionality supports the interaction between the human and the front-end by means of event handling and action execution (guided by the presentation logic of each application user interface).


Domain Model and User Interface binding



Source: Standard (SCXML [SCXML] & XForms 1.1 [XFORMS])

Functionality name: Monitor user behaviour and knowledge extraction

Description: This functionality will enable the monitoring of the user behaviour to extract user models and interaction patterns. An important point which it is still open is how to model the interaction patterns and how they will be stored.


Interaction Management


User’s Knowledge Exploitation

Source: Contribution coming from the EzWeb NESSI Strategic Project and FAST Project


3 PATTERNS

3.1 Front-End in E-SOA Pattern

3.1.1 Pattern ID-Card

3.1.2 Problem Description

The evolution of web-based interfaces is a testimony of the progress achieved to improve service usability. However, existing, web-based service front-ends, are far from completely meeting end-user expectations. Most applications and information portals nowadays are still based on monolithic, inflexible, non-context-aware, non-customizable and unfriendly UIs. As a consequence end-users do not really benefit from the advantages promoted by service orientation in terms of modularity, flexibility and composition. In addition service front-ends are constructed in an ad-hoc manner and with the absence of formal engineering methods and tools that could accelerate the time to market.

In recent years business IT systems and information portals on the Internet have increased their complexity to adapt to the demanding, and at the same time volatile, business and end-user requirements. This complexity has derived in an enormous effort to integrate, adapt and evolve applications and contents in order to satisfy user needs and expectations. The final results are severe penalizations in time to market with a subsequent big business impact.

Name Front-End in E-SOA

Abstract This pattern is a refinement of the “Designer and Runtime Tools for E-SOA” one. Concretely, it focuses on the functionalities provided by software components that are responsible for the design and execution of artefacts devoted to the NEXOF presentation (front-end) concern All the architectural choices made by this pattern are related to the decomposition into three functional aspects: accessing to and adapting SFERs, composing SFERs and engineering SFERs. In addition, the “Context of Use Manager” component, covers the cross-cutting aspect that has to do with the provision of contextual information (what is the device, browser, network, location, etc.) needed to adapt automatically the interaction to different computing platforms, users or environments.

Level Abstract

Type Functional

Key Concerns Presentation

Credits EzWeb

MyMobileWeb

FAST

Contact JOSE MANUEL CANTERA FONSECA ([email protected])


Service Oriented Architectures (SOAs), which enable a ―loose coupling‖ between applications, business logic and contents are starting to be used to alleviate these problems. Nonetheless, SOAs remain focused on service to service communications and automating service composition (using BPM technologies) on the backend layer.

SOA front-ends are still based on monolithic and non-customizable user interfaces and portals that invoke, when needed and in ad-hoc manner, backend services and processes. In this scenario services do not feature a ―face‖ to human users, as they reside on a merely technical layer.

Existing approaches such as Internet mash-ups are valid in the short term, but unsustainable in the long term. The main issue is the restricted functionality of the UI which is limited to the combination of simple content rather than application functionality. High dependency on the underlying computing infrastructure is also a limiting factor. Changes in the original wrapped applications, in the back-end services, or in the portal infrastructure may cause a failure in the UI and render user service interaction unusable.

The reality is that nowadays users cannot actually benefit from the potential advantages provided by SOA in terms of composition, flexibility, customization and adaptability in a contextual manner. We advocate a next generation SOA front-end technology where users should be able to create their own applications by combining different pieces without any help from IT experts or deep knowledge about the underlying infrastructure. There are very good reasons to do so:

IT systems and Internet applications nowadays are still designed and implemented taking as a reference the most common use cases and situations. Catering for more specific needs is, in many cases, commercially not viable. When it is, it almost always leads to increased complexity of the application and the interface, leaving less proficient users out.

The traditional specify, design, implement, test and deploy lifecycle is no longer sufficient to capture the rapidly changing user needs and requirements. Users are increasingly dependent on IT systems and, at the same time, more knowledgeable about the problems they want to solve and how to tackle them. They hold a very valuable knowledge and some of them are willing to devise new solutions if they are given the means to do so. Traditional tools and methods raise the bar too high for non-IT-aware users in order to be able to contribute new solutions.

These are well recognised Web 2.0 principles that are still not adequately supported by current service front-ends and engineering tools. Providing solutions tailored to users needs and allowing them to contribute their knowledge and creativity represents a huge potential yet to be unleashed. Service front-end is the best place to do so, since it is the layer that imposes the least IT knowledge requirements on the user and is the one closest to the user and the problem to be solved.

Therefore, it is necessary to devise a new SOA front-end capable to provide an environment which empowers end-users to easily use, customize, contribute,


enhance and compose services coming from different providers. Furthermore, users should be able to create their own applications by combining different pieces without any help from IT experts or deep knowledge about the underlying infrastructure.

In addition the new generation SOA front-end should embrace the Web 2.0 principles, exploiting user’s collective intelligence and domain knowledge. Service front-ends should be in charge of knowledge capture and further exploitation, as they are the architectural components that deal with user interaction. Thus, new challenges appear with respect to user’s knowledge gathering, representation and integration with formal knowledge. At this respect an important research topic is the seamless integration between ontologies (formal semantics) and folksonomies (light semantics).

Once the user knowledge has been properly extracted it should be exploited to enrich context-awareness, to personalize the user-service interaction and to improve existing processes or derive new ones.

From the engineering point of view, the development of context-aware service front-ends is insufficiently supported by existing methodologies and tools. Instead, user interfaces are designed manually for service interfaces and business processes. This fact calls for the need to develop new technologies and tools that simplify and accelerate the development of context-aware service front-ends. Such front-ends will adapt seamlessly to the target environment, providing a harmonized user experience in every device, network or situation.

From the business and enterprise applications perspective, the adoption of new generation service front-ends is also challenging. Traditional monolithic user interfaces will be phased out by advanced environments based on services front-end composition and customization. In addition employees will start to be seen as an essential piece of systems. Tools and technologies for exploiting collective knowledge will start to appear. Last but not least, engineering departments will need to incorporate new paradigms supporting the development of applications that adapt seamlessly to each environment and situation.

From our point of view, the challenges explained in the previous section call for the need to user-centric SOAs based on a new generation of service front-end technologies. Such technologies will enable the massive deployment of services on the Internet, driven by the following guiding principles:

End-Users Empowerment, enhancing traditional user-service interaction by facilitating the selection, creation, composition, customization, re-use and sharing of applications in a personalized operating environment.

Seamless Context-Aware User–Service Interaction. New generation service front-ends should have the capability to detect contextual information, to represent it, to manipulate it, and to use it to adapt seamlessly to each situation, supporting human users in a more effective, personalized and consistent way. Novel engineering tools and methods should be devised in order to support context-aware service front-ends.


Universal Collaborative Business Ecosystems. Enterprise systems should incorporate advanced user-centric, context-aware front-ends to enable their employees and other stakeholders to exploit, and share their extensive domain expertise, and their thorough business knowledge. Employees, customers, developers and providers will collaborate to create and improve enterprise applications, sharing, reusing, changing and combining existing context-aware components (services, contents, things...).

3.1.3 Functional Requirements

Here after a subset of the conceptual model is reported. The defined concepts are necessary for the description of the functional requirements. These are here reported for completeness reasons.

The following diagrams are used to introduce the basics concepts and their relationships before providing their textual definition.

SFE Resource<<hosted>>

SFE Mashup<<hosted>>

UI Component<<hosted>>

0..*1..*

SFE Component<<hosted>>

SFE Workspace

+containerOf

User

interacts 1..*

0..*

1..*

owns 0..*1

0..*

0..*

SFE Catalogue<<component>>

SFE Mashup Platform<<component>>

SFE Component Description

1

1

1..*

0..*

Figure 5 Front-End in E-SOA Conceptual Model

Service Front-End Component: a SFE Component is a UI Component that makes it possible the interaction between a human user and one or several software services. SFE Components can be registered in a SFE Catalogue, making them available to other potentially interested users.

Service Front-End Component Description: This concept represents all the metadata that allows to describe a SFE Component, thus enabling its registration in a SFE Catalogue.


Service Front-End Catalogue: a registry that holds descriptions about different SFE Components. Such components can be used and composed by different users. A SFE Catalogue enables the selection and discovery of SFE Components within a SFE Mashup Platform.

Service Front-End Resource: this concept represents a kind of SFE Component that plays also the role of a Software Component within the NCI (UI Component).

SFE Resources can be standalone, full applications or gadgets (according to the terminology introduced by EzWeb) ready to be composed with other SFE Resources, yielding to SFE Mashups.

Service Front-End Mashup: A SFE Mashup is a SFE Component which is the result of the composition of two or more SFE Resources. In this context composition means that the different SFE Resources are capable to interchange data between them and to react accordingly to such data interchange.

Service Front-End Workspace: A SFE Workspace acts as the container of a SFE Mashup. A SFE Workspace is created and owned by a user. Mash-up Designers create new SFE Mashups within a SFE Workspace. End users interact with SFE Mashups through a SFE Workspace.

Service Front-End Mashup Platform: A SFE Mashup Platform allows users to compose, share and to access to SFE Mashups registered in one or more SFE Catalogues and contained in one or more SFE Workspaces.

The following use-case diagram shows the functional requirements that this pattern meets.


System

SFER Designer

Administrator

External Agent

createSFER

End User

createSFEMashup

accessSFER

accessSFEMashup

<<include>>

Mashup Designer

deploySFER

undeploySFER

stopAgentSFER

startAgentForSFER

sendMessage

subscribeEvent

publishSFEComponent

getLoggedData

unpublishSFEComponent

SFE Publisher

Des&Runtime::createUI Des&Runtime::deploy

Des&Runtime::stopAgent

Des&Runtime::startAgent

Des&Runtime::subscribeEvent Des&Runtime::getLoggedData Des&Runtime::sendMessage

Des&Runtime::undeploy

configureMonitoringPolicy

DesRuntime::configureMonitoringPolicy

Figure 6 Functionalities provided by the Front End in ESOA

createSFER: this functionality enables the creation of SFE Resources. It is a refinement of the generic functionality createUIComponent provided by the Designer and Runtime Tools (DRT) pattern.

accessSFER: this functionality allows users to interact with SFE Resources. This is a specific functionality introduced by E-SOA Front-End pattern and hence it is not related to any functionality of the DRT pattern.

deploySFER allocates computational resources for the SFER which refines the deploy functionality provided by the DRT pattern. For example, consider a SFE Resource which it is a Java-based Web Application. The deploySFER functionality would be achieved by copying a WAR file and the addition of a new application context in the container configuration files.

startAgentForSFER starts an agent that realizes the SFER which refines the startAgent functionality offered by the DRT pattern. In fact this functionality puts into execution a SFE Resource. Once this operation has finished the SFE Resource is ready to be accessed.

For example, consider a SFE Resource which it is a Java Servlet-based web application. Provided that such a SFE Resource has been formerly deployed, the startAgentForSFER functionality would be achieved by starting the container (Tomcat) (if not formerly running) and enabling the corresponding web application.


undeploySFER frees the computational resources of the NCI needed for its execution. This functionality refines the undeploy functionality provided by the DRT pattern. In the Java-based Web Application example this operation would correspond to the deletion of the war file.

stopAgentSFER that stops the corresponding agent that realizes the SFER. It refines stopAgent from the DRT pattern. In the Java-based Web Application example this operation would correspond to the disablement of the application context within the Java container.

createSFEMashup: this functionality makes it possible the creation of SFE Mashups. It includes two other functionalities (createWorkspace and composeSFERs) which are part of the solution described on Section 5. This is an specific functionality introduced by this pattern and hence it is not related to any functionality of the DRT pattern.

accessSFEMashup: this functionality allows users to interact with SFE Mashups . It includes two other functionalities (selectWorkspace and wireSFERs) which are part of the solution described on Section 5. This is an specific functionality introduced by this pattern and hence it is not related to any functionality of the DRT pattern.

publishSFEComponent: this functionality allows a user to publish a SFE Component in a SFE Catalogue. From the point of view of this pattern, publishing a SFE Component means that the SFE Component is registered in the SFE Catalogue, and hence it is ready to be used by users of the SFE Mashup Platform. This is an specific functionality introduced by this pattern and hence it is not related to any functionality of the DRT pattern.

unpublishSFEComponent: this functionality allows a user to unpublish a SFE Component in a SFE Catalogue. From the point of view of this pattern, unpublishing a SFE Component means that the SFE Component is unregistered in the SFE Catalogue, and hence it is no longer available to be used by users of the SFE Mashup Platform. This is an specific functionality introduced by this pattern and hence it is not related to any functionality of the DRT pattern.

getLoggedData: this functionality corresponds to the generic functionality of the same name described by the DRT pattern, applied to the specific case of Service Front-Ends.

sendMessage: this functionality corresponds to the generic functionality of the same name described by the DRT pattern, applied to the specific case of Service Front-Ends.

subscribeEvent: this functionality corresponds to the generic functionality of the same name described by the DRT pattern, applied to the specific case of Service Front-Ends.

3.1.4 Non-Functional Qualities (Quality Attributes)


Availability +

Integrability +

Modifiability (Adaptation to new operating environments)

+

Modifiability (Extension of capability)

+

Reusability +

Usability +

Security (Isolation) -

Resource Efficiency -

3.1.4.1 Rational

This pattern is a refinement of the ―Designer and Runtime Tools for E-SOA‖ one. Concretely, it focuses on the functionalities provided by software components that are responsible for the design and execution of artefacts devoted to the NEXOF presentation (front-end) concern. Particularly, it refines the ―UI Designer‖ and the ―UI Runtime‖ components.

The architectural choices that have been made by this pattern describe a part of the SOA front-end infrastructure at a very high level of abstraction and can be specialized to realize more specific architectural solutions.

All the architectural choices made by this pattern are related to the decomposition into three functional aspects: accessing to and adapting SFERs, composing SFERs and engineering SFERs:

the ―SFER Access Platform‖ provides the runtime infrastructure that allows to access to and to adapt SFERs.

the ―SFE Mashup Platform‖ enables the design and runtime execution of composite applications (front-end mash-ups) made from different and connected SFERs supplied and adapted by the SFER Access Platform.

the ―SFER Authoring Tool‖ facilitates the engineering, authoring, designing and testing of SFERs.

It is noteworthy to note that, in the proposed architecture, composite front-ends (mash-ups) are optional. This means that SFERs can be potentially accessed in the context of a mash-up or on an individual basis. This decision has been taken to consider independent, stand-alone front-end applications that would not benefit so much from being mashed-up.

In addition, the ―Context of Use Manager‖ component, covers the cross-cutting aspect that has to do with the provision of contextual information (what is the device, browser, network, location, etc.) needed to adapt automatically the interaction to different computing platforms, users or environments.

The proposed pattern aims to improve the integrability of service front-ends. Indeed, front-end mash-ups are an enabler to make separately developed


SFERs work correctly together. Likewise, for the same reasons, ―Extension of Capacity‖ and reusability are also improved.

The ―Front-End in E-SOA‖ pattern enables the development of user interfaces capable to adapt to different computing platforms, users or environments, thus ―Adaptation to new operating environments‖ is positively affected. Additionally, the usability of the system is increased as the adaptation processes will be aimed to provide a harmonized user experience across multiple devices or modes of interaction.

Nonetheless, the front-end mash-up approach has security issues, particularly with respect to the isolation of components. As the different SFERs within a mash-up are typically executed under the same client platform (for example a web browser), sensitive information can be exposed between SFERs or denial-of-service attacks can be performed by malign SFERs.

Additionally, the proposed pattern (if mash-up is used) impacts negatively on the ―resource efficiency‖. Indeed, each SFER is not aware of the operative status of the other SFERs and this can jeopardize the application of ad hoc resource allocation policies that allows the optimization of the resources usage.

Final, the architectural choice that separates the mash-up layer from SFER access layer improves the availability of the system, as SFERs can be accessed even if mash-ups are not available for any reason.

3.1.5 Assumptions

This section describes the context where the proposed pattern is applicable.

Front End<<subsystem>>

IR_FrontEnd

+sendMessage(a: Agent, m: Message)+notifyEvent(e: Event)+isAuthorized()+assignCR()

Figure 7 Functionalities required by the Front End Subsystem

At the level of abstraction that this pattern is specified assumptions can not be made explicit. Assumptions will be made explicit in the patterns that describe how to realize the main components introduced by the present pattern. Thus, the only assumptions that can be mentioned are the required interfaces needed by the pattern which are those concerned with messaging, security, virtualization and monitoring (see the IR_FrontEnd interface).

Below it is summarized the description of the functional assumptions (in terms of high level functionalities) of the pattern and their rationale:

sendMessage: this functionality is needed to allow Service Front-Ends to communicate with other components with the NCI. For example, a SFE Resource that needs to send a message to a backend service in order to perform an operation or to get some data or information.


notifyEvent: this functionality needs to be present and implemented by those components interested in receiving events of interest coming from the Service Front-End NEXOF infrastructure.

isAuthorized: The Service Front-End infrastructure needs this functionality in order to perform user authentication and authorization.

assignCR: The Service Front-End infrastructure needs this functionality in order for the assignment of the computational resources need to support SFE Components.

At the level of abstraction addressed by this pattern we have not identified any functional assumptions.

3.1.6 Solution

The diagram below shows the architectural choices made by the pattern to design an ―Enterprise SOA Front-End‖. It introduces the components and their provided and required interfaces.

Front End<<subsystem>>

IR_FrontEnd

+sendMessage(a: Agent, m: Message)+notifyEvent(e: Event)+isAuthorized()+assignCR()

IP_FrontEnd

+accessSFER(sfer: SFE Resource)+accessSFEMashup(sfem: SFE Mashup, sfew: SFE Workspace)+createSFER(): SFE Resource+createSFEMashup(): SFE Mashup+deploySFER(sfer: SFE Resource)+undeploySFER(sfer: SFE Resource)+startAgentForSFER(sfer: SFE Resource): Agent+stopAgentSFER(a: Agent)+unpusblishSFEC(sfecd: SFE Component Description)+publishSFEC(sfecd: SFE Component Description)+sendMessage(a: Agent, m: Message)+getLoggedData()+subscribeEvent(et: EventType)+configureMonitoringPolicy()

Figure 8 The Front-End subsystem (provided and required interfaces)

ContextOfUse Manager

SFE Mashup Platform

SFER Authoring Tool

SFER Access Platform

Figure 9 Components of the Front-End subsystem and their dependencies


E-SOA Front-End



IP_SFE_ContextOfUse

+getContextOfUse()

SFER Authoring Tool

SFE Mashup Platform

IP_SFEC_Publication

+publishSFEC()+unpublishSFEC()

IP_SFER_Management

+undeploySFER(sfer: SFE Resource)+startAgentForSFER(sfer: SFE Resource): Agent+stopAgentSFER(a: Agent)+deploySFER(sfer: SFE Resource)

IP_SFER_AuthoringTool

+createSFER(): SFE Resource

IP_SFER_AccessPlatform

+accessSFER()

IP_Messaging

+sendMessage(a: UI Agent, m: Message)

IR_Security

+isAuthorized()

IR_Security

+isAuthorized()

IR_Security

IP_Monitoring

+getLoggedData()+subscribeEvent(et: EventType)+configureMonitoringPolicy()

IR_FrontEnd

+sendMessage()+notifyEvent()+isAuthorized()+assignCR()

IR_Resource

IP_SFE_MashupPlatform

+createSFEMashup(): SFE Mashup+accessSFEMashup(sfem: SFE Mashup)+createWorkspace(): SFE Workspace+selectWorkspace(sfew: SFE Workspace)+composeSFERs()+wireSFERs()

IP_FrontEnd

+accessSFER()+accessSFEMashup()+createSFER()+createSFEMashup()+deploySFER()+undeploySFER()+startAgentForSFER()+stopAgentSFER()+unpusblishSFEC()+publishSFEC()+sendMessage()+getLoggedData()+subscribeEvent()+configureMonitoringPolicy()

IP_Monitoring

IR_Resource

+assignCR()

IP_Messaging

IR_Notify

+notifyEvent(e: Event)

IR_Messaging

+sendMessage(a: Agent, m: Message)

IR_NotifyIR_Messaging

IP_UIRuntime

IR_UIDesignerTool

IR_UIRuntime

IP_UIDesignerTool

IP_Management

IP_UIDesignerTool

Figure 10 Front-End in E-SOA Pattern


3.1.6.1 Component Descriptions

The components of the architecture are described as follows:

SFER Authoring Tool

SFER Authoring Tool

IP_SFER_AuthoringTool

+createSFER(): SFE Resource

IR_SFER_AuthoringTool

+isAuthorized()+deploySFER(sfer: SFE Resource)+undeploySFER(sfer: SFE Resource)+startAgentForSFER(sfer: SFE Resource): Agent+stopAgentSFER(a: Agent)+publishSFEC(sfecd: SFE Component Description)+unpublishSFEC(sfecd: SFE Component Description)

Figure 11 SFER Authoring Tool component (provided and required interfaces)

This component enables a developer to create Service Front-End Resources.

The exposed operations are:

Provided Operations

− createSFER(): SFE Resource

This operation represents the functionality that allows the development of new SFE Resources.

Required Operations

− isAuthorized()

This operation is required to check if the user has permissions for creating a new SFE Resource.

− deploySFER(sfer: SFE Resource)

The component requires this operation from the SFER Access Platform in order to ask for the deployment of a recently created SFE Resource.

− startAgentForSFER(sfer: SFE Resource): Agent

The component requires this operation from the SFER Access Platform in order to ask for the execution of a recently created and deployed SFE Resource, for example for testing purposes.

− stopAgentSFER(a: Agent)

This operation is required to stop the execution of a SFE Resource. For instance, this operation can be used to stop an old version of a SFE Resource that it is going to be replaced by a new one that needs to be tested.

− undeploySFER(sfer: SFE Resource)

This operation is required to undeploy a SFE Resource. For instance, this operation can be used to remove an old version of a SFE Resource that it is going to be replaced by a new one that is about to be tested to be tested.


− publishSFEC(sfecd: SFE Component Description)

The component requires this operation from the SFE Mashup Platform in order to register new SFE Resources within the SFE Catalogue, making them available to the users of mash-ups.

− unpublishSFEC(sfecd: SFE Component Description)

The component requires this operation from the SFE Mashup Platform in order to unregister a SFE Resource.

SFE Mashup Platform

SFE Mashup Platform

IP_SFE_MashupPlatform_All

+createSFEMashup(): SFE Mashup+accessSFEMashup(sfem: SFE Mashup)+createWorkspace(): SFE Workspace+selectWorkspace(sfew: SFE Workspace)+composeSFERs()+wireSFERs()+configureMonitoringPolicy()+getLoggedData()+subscribeEvent(et: EventType)+publishSFEC(sfecd: SFE Component Description)+unpublishSFEC(sfecd: SFE Component Description)+sendMessage(a: Agent, m: Message)

IR_SFE_Mashup_Platform

+accessSFER(sfer: SFE Resource)+getContextOfUse(e: Evidence): Context Of Use+sendMessage(a: Agent, m: Message)+assignCR()+isAuthorized()+notifyEvent(e: Event)

Figure 12 SFE Mashup Platform component (provided and required interfaces)

It is the component which implements the runtime infrastructure that allows users to compose SFE Resources to yield to SFE Mashups.


Provided Operations

− publishSFEC(sfecd: SFE Component Description)

It allows to publish a new SFE Component which metadata are those provided by the SFE Component Description passed as parameter.

− unpublishSFEC(sfecd: SFE Component Description)

This operation is intended to unpublish a SFE Component which metadata are those provided by the SFE Component Description passed as parameter.

− createSFEMashup(): SFE Mashup

This operation is concerned with the creation of a new SFE Mashup by the user.

− accessSFEMashup(sfem: SFE Mashup,sfew:SFE Workspace)

This operation represents the functionality that allows a user to access and to interact with a SFE Mashup within a SFE Workspace.

− createWorkspace(): SFE Workspace


This functionality allows the creation of SFE Workspaces that will serve as containers for SFE Mashups.

− selectWorkspace(sfew: SFE Workspace)

It allows the user to select a workspace that will be used to access to a SFE Mashup.

− composeSFERs()

This functionality, which it is part of the createSFEMashup functionality,

allows users to discover, to select and to (graphically) connect different SFE Resources during the mashup creation process.

− wireSFERs()

This functionality, which it is part of the accessSFEMashup functionality,

is responsible for implementing a communication channel that will make it possible to wire the different SFE Resources that are within a SFE Mashup.

− subscribeEvent(et: EventType)

It allows a client to subscribe its interests to a type of Event. The client will be notified every time an Event of that type occurs.

− getLoggedData()

This functionality returns the data logged by this component (monitoring).

− configureMonitoringPolicy()

It allows the monitoring tool to configure the monitoring policy for this component.

− sendMessage(m: Message, a: UI Agent)

This functionality allows to receive messages coming from other agents in the system.

Required Operations

− accessSFER(sfer: SFE Resource)

The component requires this functionality to access to the different SFE Resources that compose a SFE Mashup.

− getContextOfUse(e: Evidence): ContextOfUse

This functionality is required to obtain the characteristics of the Context of Use in order to adapt accordingly the user interface offered by the SFE Mashup Platform.

− sendMessage(m: Message, a: Agent)

The component requires this functionality to send a message to other agents in the system.

− notifyEvent(e: Event)


This component requires this functionality to notify events to the clients

that have subscribed their interest though the subscribeEvent

method.

− assignCR()

This function is needed to assign computational resources to support the execution of SFE Mashups. It must be provided from the manager of the computational resources.

− isAutorized()

The component requires this operation from the tool that manages the security of the system to check if the client has the rights to access provided functionalities of this component.



IP_SFER_AccessPlatform_All

+accessSFER(sfer: SFE Resource)+deploySFER(sfer: SFE Resource)+undeploySFER(sfer: SFE Resource)+startAgentForSFER(sfer: SFE Resource): Agent+stopAgentSFER(a: Agent)+configureMonitoringPolicy()+getLoggedData()+subscribeEvent(et: EventType)+sendMessage(a: UI Agent, m: Message)

IR_SFER_AccessPlatform

+isAuthorized()+assignCR()+sendMessage(a: Agent, m: Message)+notifyEvent(e: Event)+getContextOfUse(e: Evidence): Context Of Use

Figure 13 SFER Access Platform component (provided and required interfaces)

It is the component which implements the runtime infrastructure that allows to access to SFE Resources.


Provided Operations

− deploySFER(sfer: SFE Resource)

It allows to deploy a new SFE Resource within the SFER Access Platform. The deployment may include the assignment of the computational resources required for the SFER.

− undeploySFER(sfer: SFE Resource)

This operation is intended to undeploy a SFE Resource.

− startAgentForSFER(sfer: SFE Resource): Agent

This operation starts an Agent that will realize the

SFE Resource.

− stopAgentSFER(a: Agent)

This operation stops the agent that is realizing a SFE Resource.

− accessSFER(sfer: SFE Resource)

This operation represents the functionality that allows to access and to interact with a SFE Resource.




− getLoggedData()




− sendMessage(m: Message, a: UI Agent)

This functionality allows to receive messages coming from other agents in the system.

Required Operations


This functionality is required to obtain the characteristics of the Context of Use to adapt accordingly the user interface offered by a SFE Resource.






method.

− assignCR()

This function is needed to assign computational resources to support the execution of SFE Resources. It must be provided from the manager of the computational resources.

− isAutorized()





IR_ContextOfUse_Manager

+isAuthorized()+notifyEvent(e: Event)

IP_SFE_ContextOfUse_All

+getContextOfUse(e: Evidence): Context Of Use+configureMonitoringPolicy()+getLoggedData()+subscribeEvent(et: EventType)

Figure 14 Context of Use component (provided and required interfaces)

It is the component which implements the runtime infrastructure that allows to access to the information about the Context of Use.


Provided Operations


This is the main functionality provided by the component. It returns the information about the Context of Use taking as input parameter a set of evidences that are known. For example, in a Web environment the evidences correspond to the HTTP headers sent by the web browser used.



− getLoggedData()




Required Operations




method.

− isAutorized()



3.1.6.2 Functionality Descriptions

In this section is described how the different components collaborate to realize the provided functionalities of the overall system. The realization of some internal functionalities is described as well, to clarify the behaviours of the system when they can raise some ambiguity or they can be useful for the refinement of this pattern.

createSFER

The figure below shows the sequence diagram for the ―createSFER‖ functionality.

: IP_FrontEnd

: SFER Designer

: IP_SFER_AuthoringTool : IR_Security : SFER Access Platform

1 : createSFER()

2 : createSFER()

3 : isAuthorized()

4 : true5

6 : SFER Ready

7 : deploySFER()

<<test>>

8 : deploySFER()<<test>>

9 : deployed

10 : startAgentForSFER()

<<test>>

11 : startAgentForSFER()<<test>>

12 : started

13 : accessSFER()

<<test>>

14 : accessSFER()<<test>>

15 : ready To Be Tested

Figure 15 Sequence diagram for creating a SFER

A SFER Designer wants to create a SFER. The SFER Authoring Tool is the responsible of implementing such a functionality. Before, granting access, an authorization check has to be done. Once the SFER creation process is finished, it can be deployed, started and accessed for testing purposes.

The last testing steps (stereotype ―test‖) are not mandatory, but are very likely to occur in a real life scenario, where a designer has to perform, at least, unitary tests for her component. For simplicity reasons, it has not been described the sub-steps needed to perform deployment, agent start-up or SFER access. Such detailed descriptions can be found on the corresponding detailed functionality descriptions on the following sections.


accessSFER The figure below shows the sequence diagram for the ―accessSFER‖ functionality.

: IR_Security : IP_FrontEnd : IP_SFER_AccessPlatform

: End User

: IP_SFE_ContextOfUse

1 : accessSFER()

2 : accessSFER()

3 : isAuthorized()

4 : true

5 : getContextOfUse()

6

7

8 : SFER Ready to Interact

Figure 16 Sequence diagram for accessing a SFER

An end-user wants to access to a SFER. The SFER Access Platform is in charge of implementing such a functionality. The first step is to check for authorization. Then, the Context of Use must be obtained. When the Context of Use is known the SFER can be adapted to the target computing platform, user or environment. Finally, the SFER will be ready to be interacted with. Further user interactions will re-issue the same sequence of collaborations between the components.


createSFEMashup

The figure below shows the sequence diagram for the ―createSFEMashup‖ functionality.

: Mashup Designer

: SFE Mashup Platform : IR_Security : IP_FrontEnd

1 : createSFEMashup()

2 : createSFEMashup()3 : isAuthorized()

4 : true

Sequence Diagram for "createMashup"

5 : createWorkspace()

6 : empty SFE Mashup

7 *[1..*] : composeSFERs()

8 : isAuthorized()

9 : true

10 : SFE Mashup

Figure 17 Sequence diagram for creating a Mashup

The scenario starts with a mashup creation request. The Mashup Platform checks whether the user is authorized or not, and if it is, a workspace is created to hold such a mashup. The Mashup Platform returns an empty SFE Mashup. With the empty SFE Mashup the mashup designer can start composing the SFERs if she is authorized. Finally the SFE Mashup created is returned.


accessSFEMashup

The figure below shows the sequence diagram for the ―accessSFEMashup‖ functionality.

: End User

: IR_Security : SFE Mashup Platform : ContextOfUse Manager : IP_FrontEnd : SFER Access Platform

Sequence Diagram for "accessMashup"

1 : accessSFEMashup()

2 : accessSFEMashup()

3 : isAuthorized()

4 : true

5 : selectWorkspace()


7 : Context Of Use

8 *[1..*] : accessSFER()


10 : Context of Use

11 : SFERs Ready

12 : mashupReadyToInteract

13

<<UserInteraction>>14 : accessSFER()

15 : wireSFERs()

16 : interactionResult

Figure 18 Sequence diagram for accessing a mash-up

First, a end user wants to access a mash-up. Then, the ―Mashup Platform‖ verifies it the user is authorized, and if it is, a workspace is selected to hold such a mash-up. The ―Mashup Platform‖ needs the information about the context of use, which is provided by the ―ContextOfUse Manager‖. With that information, the ―Mashup Platform‖ requests the SFERs that compose the mash-up. When the SFERs are ready, the mash-up is ready to interact with. The interaction with the mash-up might encompass connections between the SFERs (wiring) to interchange and aggregate data between them.


deploySFER

The figure below shows the sequence diagram for the ―deploySFER‖ functionality.

: Administrator

: SFER Access Platform : IR_Security : IP_FrontEnd : IR_Resource

1 : deploySFER()

2 : deploySFER()

3 : isAuthorized()

4 : true

5 : assignCR()

Sequence Diagram for "deploySFER"

6 : SFER Deployed

Figure 19 Sequence diagram for deploying a SFER

An administrator needs to deploy a SFER. The SFER Access Platform first checks for authorization, and then asks for computational resources. Finally the SFER is deployed.

undeploySFER

The figure below shows the sequence diagram for the ―undeploySFER‖ functionality.

: Administrator

: SFER Access Platform : IR_Security : IP_FrontEnd

1

2 : undeploySFER()

3 : isAuthorized()

Sequence Diagram for "undeploySFER"

4 : true

5 : SFER Undeployed

Figure 20 Sequence diagram for undeploying a SFER


An administrator needs to undeploy a SFER. The SFER Access Platform first checks for authorization, and then perform the undeployment.


startAgentForSFER


: Administrator

: SFER Access Platform : IR_Security : IP_FrontEnd : IR_Resource

1

2 : startAgentForSFER()

3 : isAuthorized()

4 : true

5 : assignCR()

6 : UI Agent

Sequence Diagram for "startAgentForSFER"

Figure 21 Sequence diagram for starting an agent for an SFER

An administrator needs to start an agent for a SFER. The SFER Access Platform first checks for authorization, and then asks for computational resources. Finally the SFER Agent is started.

stopAgentSFER


: Administrator

: IP_FrontEnd : IR_Security : SFER Access Platform

1 : stopAgentSFER()

2 : stopAgentSFER()

3 : isAuthorized()

4 : true

5

6 : agent Stopped

Figure 22 Sequence diagram for stopping a SFER Agent

An administrator needs to stop an agent which is realizing a SFER. The SFER Access Platform first checks for authorization, and then performs the stop.


publishSFEComponent

The figure below shows the sequence diagram for the ―publishSFEComponent‖ functionality.

: IR_Security : SFE Mashup Platform : IP_FrontEnd

: SFE Publisher

Sequence Diagram for "publishSFEComponent"

1 : publishSFEComponent()

2 : publishSFEComponent()

3 : isAuthorized()

4 : true

5 : SFEComponent Published

Figure 23 Sequence diagram for publishing a SFEComponent

An ―SFE Publisher‖ wants to publish a SFEComponent. The ―Mashup Platform ―first verifies whether the user is authorized. If the authorization check is successful the publication takes place.


unpublishSFEComponent

The figure below shows the sequence diagram for the ―unpublishSFEComponent‖ functionality.

: IR_Security : SFE Mashup Platform : IP_FrontEnd

: SFE Publisher

Sequence Diagram for "unpublishSFEComponent"

1 : unpublishSFEComponent()

2 : unpublishSFEComponent()

3 : isAuthorized()

4 : true

5 : SFEComponent unpublished

Figure 24 Sequence diagram for unpublishing a SFEComponent

An ―SFE Publisher‖ wants to unpublish a SFEComponent. The ―Mashup Platform‖ first verifies whether the user is authorized. If the authorization check is successful the publication removal takes place.


sendMessage

See the Designer and Runtime Tools in E-SOA pattern.

getLoggedData


subscribeEvent


configureMonitoringPolicy


3.1.7 Relationships to other patterns

The following diagram shows the relationship of the ―Front-End in E-SOA‖ Pattern with other patterns.

Enterprise SOA

Designer and RuntimeTools for E-SOA

isPartOf[Designer Tool, Runtime]

Front End in E-SOA

isPartOf[UIDesigner Tool, UIRuntime]

Figure 25 Relationship between “Front End in E-SOA” and “Designer and Runtime Tools for E-SOA” patterns

The ―Front-End in E-SOA‖ pattern is part of the ―Designer and Runtime Tools for E-SOA‖ pattern. This pattern provides the architecture of the ―UI Runtime‖ and the ―UI Designer Tool‖. More specifically the ―UI Runtime” has been refined into three main components: the ―SFER Access Platform‖, the ―SFE Mashup Platform‖ and the ―Context of Use Manager‖. At the present level of abstraction the ―UI Designer Tool‖ has only been refined into the ―SFE Authoring Tool‖. A specific pattern will give more details about such a component.


3.1.8 Relationships to Components Catalogue

3.1.8.1 Abstract Components

Name Description of the main features

Device Description Repository

Provides information about the a priori known characteristics of a Delivery Context. For example, what is the resolution width or the input mechanisms of a device.

OMA-STI Transcoder

It is in charge of transforming multimedia resources to different formats to meet certain characteristics of a delivery context.

Web Container for Java Applications

It is a container of web applications based on Java technologies (servlet, JSP). It must support the servlet 2.4 and JSP 2.0 specifications

RDBMS A relational database

HTTP Transparent Proxy

An HTTP proxy that does not modify the request or response beyond what is required for proxy authentication and identification

3.1.8.2 Concrete Components

Name Description of the main features

Related abstract component

Reference to the concrete implementation

TID’s Device Description Framework

See Device Description Repository


http://forge.morfeo-project.org/projects/ddr-ri/

Alembik See OMA-STI Transcoder

OMA-STI Transcoder

http://alembik.sourceforge.net/

Tomcat See Web Container for Java Apps

Web Container for Java Apps

http://tomcat.apache.org

MySQL See Relational Database description

RDBMS http://www.mysql.com/

Apache Module mod_proxy

See HTTP Transparent Proxy


http://httpd.apache.org/docs/2.2/mod/mod_proxy.html



http://alembik.sourceforge.net/

http://tomcat.apache.org/

http://www.mysql.com/




3.1.9 Relationships to Standards Catalogue

3.1.9.1 Delivery Context Ontology

The Delivery Context Ontology [Cantera 2009] provides a formal model of the characteristics of the environment in which devices interact with the Web or other services. The delivery context includes the characteristics of the device, the software used to access the service and the network providing the connection among others.

The delivery context is an important source of information that can be used to adapt materials to make them useable on a wide range of different devices with different capabilities.

The ontology is formally specified in the Web Ontology Language [OWL].

Related Abstract Components: Device Description Repository

3.1.9.2 DDR Simple API

Web content delivered to mobile devices usually benefits from being tailored to take into account a range of factors such as screen size, markup language support and image format support. Such information is stored in "Device Description Repositories" (DDRs). The DDR Simple API [Rabin 2008] is an API for access to DDRs, in order to ease and promote the development of Web content that adapts to its Delivery Context.


3.1.9.3 OMA STI

The deployment of multimedia applications (MMS, WAP (2), e-mail, web browsing… etc.) may require some Content Adaptations, due to the diversity of the phone specifications (memory, screen size, resolution, colour depth…etc. and supported media formats) and of the media formats as distributed by the Content industry (JPEG, GIF, all AMR modes, 13k vocoder, EVRC, MPEG-1, MPEG-4, H.263…etc.).

STI 1.0 [OMA05] is the first specification of a standard interface between Application Platforms and a Transcoding Platform and is meant to resolve some of the integration and testing problems when deploying multimedia services towards mobile devices.

Related Abstract Components: OMA-STI Transcoder


3.1.9.4 JSR-154

JSR-154 [Coward 2003] specifies the Java Servlet 2.4 technology. A servlet is a JavaTM technology-based Web component, managed by a container that generates dynamic content. Like other Java technology-based components, servlets are platform-independent Java classes that are compiled to platform-neutral byte code that can be loaded dynamically into and run by a Java technology-enabled Web server.

Related Abstract Components: Web Container for Java Applications

3.1.9.5 JSR-152

JSR-152 [Roth 2003] specifies the JSP 2.0 technology. JavaServer™ Pages (JSP) is the Java™ 2 Platform, Enterprise Edition (J2EE) technology for building applications for generating dynamic web content, such as HTML, DHTML, XHTML, and XML. JSP technology enables the easy authoring of web pages that create dynamic content with maximum power and flexibility.

Related Abstract Components: Web Container for Java Applications

3.1.9.6 HTTP 1.1 (RFC 2616)

The Hypertext Transfer Protocol (HTTP) [Fielding 1999] is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.

HTTP has been in use by the World-Wide Web global information initiative since 1990.

Related Abstract Components: HTTP Transparent Proxy

3.1.10 Application Examples

Examples of the application of this pattern can be found on the projects MyMobileWeb, EzWeb and FAST.


3.2 Mashup as a Service Pattern



The evolution of web-based interfaces is a testimony of the progress achieved to improve the user experience on the Web. However, existing, web-based front-ends, are far from completely meeting end-user expectations. Most applications and information portals nowadays are still based on monolithic, inflexible, non-context-aware, non-customizable and unfriendly UIs. As a consequence end-users do not really benefit from the advantages promoted by services in terms of modularity, flexibility and composition.

At this respect, Internet of Services front-ends are still based on monolithic and non-customizable user interfaces and portals that invoke, when needed and in ad-hoc manner, backend services and processes. In this scenario services do not feature a ―face‖ to human users, as they reside on a merely technical layer.

Existing approaches such as typical, hand-made mash-ups are valid in the short term, but unsustainable in the long term. The main issue is the restricted functionality of the UI which is limited to the combination of simple content rather than application functionality. High dependency on the underlying computing infrastructure is also a limiting factor. Changes in the original wrapped applications, in the back-end services, or in the portal infrastructure may cause a failure in the UI and render user service interaction unusable.

The reality is that nowadays users cannot actually benefit from the potential advantages provided by the Internet of Services in terms of composition, flexibility, customization and adaptability in a contextual manner. We advocate a next generation front-end technology where Internet users should be able to create their own applications by combining different pieces without any help from IT experts or deep knowledge about the underlying infrastructure. This new architectural concept is called “Mashup as a Service”.

Name Mashup as a Service

Abstract In the context of the Internet of Services, this pattern suggests an architecture intended to enable end-user composition of heterogeneous Service Front-End Resources, yielding to Service Front-End Mashups.

Level Abstract

Type Functional

Key Concerns Presentation

Credits EzWeb

FAST

Contact JOSE MANUEL CANTERA FONSECA ([email protected])


Therefore, Mashup as A Service (MaaS) is a new front-end paradigm capable of providing an environment which empowers end-users to easily use, customize, contribute, enhance and compose Internet services coming from different providers. Such an architecture embraces the Web 2.0 principles, exploiting user’s collective intelligence and domain knowledge.

Figure 1 depicts our technical proposal to materialize the MaaS vision. The main component of the underlying platform is a resource catalogue containing gadgets (which will implement be the front-end for one or more services) and possibly other application or content delivery services. This resource catalogue plays a similar role than backend service and process registries.

Resource 1

Resource n

End-User

Publication

User-Generated

Metadata

Search

Recommendation

Resource 2

End-User

Catalogue

Figure 26 Mashup as a Service Conceptual Model

Our proposed catalogue will be responsible for maintaining the information about each front-end resource (gadget) and associated metadata (template descriptors, deployment information, author, icons, versions, formal-semantics-based annotations, user-assigned tags and punctuation…). In addition the following software modules will be devoted to user-catalogue interaction:

An upload module that will allow service front-ends creators to add new resources to the catalogue, making them available to the community. To upload a new resource it will be necessary to provide a gadget descriptor (template) with all the metadata and deployment information.

A search and recommendation module that will make it possible to locate and discover those gadgets that satisfy the necessities of end-users at a given moment.

A drag-and-drop-based browsing and selection module that will allow end-users to browse and select the resources of their interest, putting them in their operating environment, thus enabling further interactions.

Apart from a resource catalogue and its supporting modules, it is also necessary a runtime environment devoted to the execution of the user’s operating environment. Such operating environment (or workspace) will act as a container, enabling the interaction between the end-user and service front-ends.


We envisage an operating environment runtime with the following functionalities:

Flexible layout composition enabling the free disposition of gadgets on the viewport.

Multiple service front-end views (implemented as tabs, for example) allowing the user to group and compose different gadgets for different problems or situations.

Publish and subscribe facilities enabling the interconnection between the different front-end resources.



Figure 27 Functionalities provided by the MaaS Pattern

createWorkspace: this functionality enables the creation of an empty Workspace ready to be used by a Mashup Creator or a Mushup User

setupWorkspace: this functionality is in charge of the configuration of the workspace including the insertion of new gadgets and determining their size and position.

createMashup: this functionality allows a Mashup Creator to compose a new Mashup, including searching of the appropriate gadgets (searchGadget functionality) gadget insertion in the workspace, determining size and position (setupWorkspace functionality), the


creation of new channels and creating connections between different gadgets (createGadgetConnection functionality).

publishMashup: this functionality allows a Mashup Creator to publish the selected Mashup on the catalogue, including the meta information about the mashup, its constituent gadgets and the connection between the gadgets. A published mashup can be searched by a Mashup User, to use it.

unpublishMashup: this functionality allows a Mashup Creator to unpublish from the catalogue a published Mashup.

publishGadget: this functionality allows a Gadget Provider to publish the selected Gadget in the catalogue, including the meta information about the gadget. It also includes the functionality to tag the gadget with the selected labels. A published gadget can be searched by a Mashup Creator, to create a Mashup.

unpublishGadget: this functionality allows a Gadget Provider to unpublish from the catalogue a published Gadget.

createGadgetConnection: defines a connection between two different gadgets, for interchanging information. One of the gadgets acts as a source of information and provides input data for the other gadget.

tagMashup: this functionality allows a Mashup Creator and a Mashup User to catalogue a mashup with the selected tag. Associating a tag to a mashup makes it easier to be found.

tagGadget: this functionality allows a Gadget Provider to catalogue a gadget with the selected tag. Associating a tag to a gadget makes it easier to be found.

searchMashup: this functionality allows a Mashup User to make a search in a catalogue looking for the desired mashup.

searchGadget: this functionality allows a Mashup Creator to make a search in a catalogue looking for the desired gadget.

accessMashup: this functionality allows a Mashup User to access a previously created mashup. This functionality deals with the security constraints and the delivery and wiring of the gadgets that are in the mashup.

deliverGadget: this functionality allocates the resources needed by the gadget, making the deploy of the gadget in the workspace.

wireGadget: this functionality is in charge of implementing the interchange of information from the different gadgets of a mashup, as is defined in the connections of the gadgets.



Availability -

Integrability +

Modifiability (Adaptation to new operating environments)

+


+

Reusability +

Security (Isolation) -

Resource Efficiency -

3.2.4.1 Rational

This pattern is part of the Internet of Services pattern, it provides an architectural solution for a subset of components belonging to the IoS pattern. In particular, this pattern provides the architecture of the components belonging to User Interface and Service Execution concerns of the IoS.

All the architectural choices made by this pattern are related to the decomposition into four functional aspects: Designing the Mashup, Accessing and using the Mashup, Delivery of a workspace and storing and managing of Meta-Information:

the ―Mashup Designer” This component enables a Mashup Creator to design a Mashup.

The ―Mashup Access‖ enables a Mashup User to access and use a Mashup.

The ―Workspace Manager‖ enables the creation, edition, configuration and delivery of a workspace and all its content: (Mashup, gadget, etc…)

The ―Mashup Metadata‖ is in charge of store all the Meta information about the mashups, allowing the publication, tagging and searching of mashups and its individual elements.

The proposed pattern aims to improve the integrability of service front-ends. Indeed, front-end mash-ups are an enabler to make separately services developed as Gadgets work correctly together. This pattern also allows connecting and composing services improving the ―Extension of Capacity‖ and reusability.

The ―Mashup as a Service‖ pattern enables the development of user interfaces that can be executed in different Mashup Platforms available in different environments, thus ―Adaptation to new operating environments‖ is positively affected.

Nonetheless, this pattern approach has security issues, particularly with respect to the isolation of components. As the different Gadgets within a mash-up are typically executed under the same client platform, sensitive information can be exposed between Gadgets or denial-of-service attacks can be performed by malign Gadgets.


Additionally, the proposed pattern impacts negatively on the ―resource efficiency‖. Indeed, each Gadget is executed without being aware of the others Gadget execution status. This could be a risk for the application of ad hoc resource allocation policies that allows the optimization of the resources usage.

Final, the architectural choice that integrates the Gadgets in a Mashup Platforms, decrease the availability of the system, as it is combination of components provided by different providers that needs to be all available at the same time.

3.2.5 Assumptions

IR_MaaS

+isAuthorized()+getContextOfUse()

MaaS<<subsystem>>

Figure 28 Functionalities required by the Mashup as a Service Subsystem

A summarized of the description of the functional assumptions (in terms of high level functionalities) of the pattern and their rationale:

isAuthorized: The Mashup infrastructure needs this functionality in order to perform user authentication and authorization.

getContentOfUse: This functionality is required to obtain the characteristics of the Context of Use in order to adapt accordingly the user interface offered by the Mashup Platform.

3.2.6 Solution

The diagram below shows the architectural choices made by the pattern to design an ―Mashup as a Service‖. It introduces the components and their provided and required interfaces.


IR_MaaS

+isAuthorized()+getContextOfUse()

MaaS<<subsystem>>

IP_MaaS

+createMashup(): Mashup+accessMashup(m: Mashup)+publishMashup(m: Mashup)+unpublishMashup(m: Mashup)+publishGadget(g: Gadget)+unpublishGadget(g: Gadget)+searchMashup(s: searchCriteria)

Figure 29 The MaaS subsystem (provided and required interfaces)

Figure 30 Components of the MaaS subsystem and their dependencies


Figure 31 MaaS Pattern




Mashup Designer

Figure 32 Mashup Designer component (provided and required interfaces)

This component enables a Mashup Creator to design a Mashup.


Provided Operations:

− createWorkspace(): Workspace

It allows to create a Workspace that will serve as a container for the mashups.

− createChannel(): Channel

Creates a channel used for the interchange of information. It allows a connection between the events that a gadget fires, and the input slots of another gadget.

− removeChannel(c: Channel)

It removes the channel from the mashup, making no longer available for the interchange of information.

− createGadgetConnection (c: Connection)

It creates a connection between 2 gadgets, using a channel for the interchange of information. One of the gadgets acts as a source of information and provides an input for the second gadget.

− removeGadgetConnection (c: Connection)

It removes the connection of the gadget from the mashup, making no longer available for the interchange of information.


− addGadgetToWorkspace (g: Gadget, w: Workspace)

It adds the selected gadget to the actual group of gadget of the workspace.

− removeGadgetFromWorkspace (g: Gadget, w: Workspace)

It removes the selected gadget from the workspace.

− addGadgetGroup (gn: GroupName): Group

It adds a new Gadget Group, with the selected name, to the workspace.

− searchGadget (s: SearchCriteria): Gadget

This operation makes it possible to find gadgets according to the selected criteria, for adding it to the workspace to configure a mashup.

− setupWorkspace(w : Workspace)

This operation configure the characteristics of the workspace including the insertion of new gadget and determining its size and position.

Required Operations:



− searchMashup(s : SearchCriteria): Mashup

This operation makes it possible to find mashup according to the selected criteria, for adding it to the workspace to be used.

− publishMashup(m : Mashup)

This operation allows publishing the selected mashup in the catalogue, including the meta information about the mashup, its gadgets and the connection between the gadgets.

− unpublishMashup(m : Mashup)

This operation removes a selected mashup from the catalogue, making it no longer available for use.

− publishGadget(g : Gadget)

This operation allows publishing the selected gadget in the catalogue, including the meta information about the gadgets.

− unpublishGadget(g : Gadget)

This operation removes a selected gadget from the catalogue, making it no longer available for use.

− tagGadget(g : Gadget, t: Tag)

This operation catalogue a gadget with the selected tag. Associating a tag to a gadget makes it easier to be found.


− tagMashup(m : Mashup, t: Tag)

This operation catalogue a mashup with the selected tag. Associating a tag to a mashup makes it easier to be found.

− addGadget(g: Gadget, w: Workspace)


− removeGadget(g: Gadget, w: Workspace)


− addTab (t: Tabname): Tab

It adds a tab, with the selected name, to the workspace.

− removeTab (T:Tab)

It removes the selected tab from the workspace.


It allows creating a Workspace that will serve as a container for the mashups.

− bindMashupToWorkspace(m: Mashup, w: Workspace)

This operation makes the delivery of the selected mashup into the actual workspace.

− resizeGadget(g: Gadget, s: Size)

It allows modifying the size of a selected gadget.

− moveGadget(g: Gadget, p: Position)

It allows modifying the position of a selected gadget in the workspace.

− renderWorkspace(w: Workspace)

This functionality displays the selected workspace in the device of the user, taking into account the context of use for the adaptation of its contents.

− deliverGadgets(w: Workspace)

This functionality allocates the resources needed by the gadgets of the mashup, making the deploy of the gadgets in the workspace.

Mashup Access


Figure 33 Mashup Access component (provided and required interfaces)

This component enables a Mashup User to access and use a Mashup.



− accessMashup(m: Mashup)

It allows accessing the selected Mashup, delivering all the gadgets contained.

− wireGadgets(m : Mashup)

This operation implementing the interchange of information from the different gadgets of a mashup, as is defined in the connections of the gadgets.



− setupWorkspace(w : Workspace)

This operation configure the characteristics of the workspace including the insertion of new gadget and determining its size and position.














This functionality allocates the resources needed by the gadgets of the Mashup, making the deployment of the gadgets in the workspace.

Workspace Manager

Figure 34 Workspace Manager Component (provided and required interfaces)

This component enables the creation, edition, configuration and delivery of a workspace and all its content: (Mashup, gadget, etc…)











− setPreferenceForGadget(g: Gadget, p: Preferences)


This operation is in charge of the configuration of the gadget according to the user preferences.

− setPreferencesForWorkspace(w: Workspace, p:

Preferences)

This operation is in charge of the configuration of the workspace according to the user preferences.




This functionality allocates the resources needed by the gadgets of the mashup, making the deploy of the gadgets in the workspace.

− addGadget(g: Gadget, w: Workspace)


− removeGadget(g: Gadget, w: Workspace)


− addTab (t: Tabname): Tab

It adds a tab, with the selected name, to the workspace.

− removeTab (T:Tab)

It removes the selected tab from the workspace.

















− untagGadget(g : Gadget, t: Tag)

This operation removes a tag from a gadget making the gadget no longer tagged with it.



Mashup Metadata

Figure 35 Mashup Metadata component (provided and required interfaces)

This component is in charge of store all the Meta information about the mashups, allowing the publication, tagging and searching of mashups and its individual elements.


















− untagGadget(g : Gadget, t: Tag)

This operation removes a tag from a gadget making the gadget no longer tagged with it.



− untagMashup(m : Mashup, t: Tag)

This operation removes a tag from a mashup making the mashup no longer tagged with it.



In this section is described how the different components collaborate to realize the provided functionalities of the overall system. The realization of some internal functionalities is described as well, to clarify the behaviours of the system when they can raise some ambiguity or they can be useful for the refinement of this pattern.

createMashup

The figure below shows the sequence diagram for the ―createMashup‖ functionality.

Figure 36 Sequence diagram for creating a Mashup


The scenario starts with a mashup creation request. The Mashup Designer component checks whether the user is authorized or not, and if it is, the context of use is required to take into account the adaptation of resources according to the context. After that a workspace is created to hold such a mashup.

The Mashup Designer component returns an empty Workspace. With the empty Workspace the mashup creator can start composing the Mashup, searching and adding the adequate gadgets and making connection between them.

Finally the Mashup Creator publishes the Mashup, making it ready to be used by Mashup User.


accessMashup

The figure below shows the sequence diagram for the ―accessMashup‖ functionality.

Figure 37 Sequence diagram for accessing a Mashup

The scenario starts with a user trying to access a mashup. The Mashup Access component checks whether the user is authorized or not, and if it is, the context of use is required to take into account the adaptation of resources according to the context. After that a workspace is created to hold such a mashup.

The user search an select a mashup which is bind to the workspace, after the delivery of the gadgets of the mashup, and after making the appropriate wring between them.

The Mashup User is free to setup the mashup, resizing and moving components to adapt its requirements. Finally the Mashup is ready to be used.



The following diagram shows the relationship of the ―Mashup as a Service‖ Pattern with other patterns.

IoS

Mashup as a service

isPartOf[UserInterface, Service Execution]

Figure 38 Relationship between “Mashup as a Service” and IoS Service patterns

The MaaS pattern is part of the Internet of Services pattern, i.e. it provides an architectural solution for a subset of components belonging to the IoS pattern. In

particular, this pattern provides the architecture of the components belonging to User Interface and Service Execution concerns of the IoS.


The following sections detail the relationships of the components of this pattern with regard to the NEXOF Reference Architecture.

3.2.8.1 Abstract Components Name Description of the main features

RDBMS A relational database


An HTTP proxy that does not modify the request or response beyond what is required for proxy authentication and identification

3.2.8.2 Concrete Components Name Description of

the main features



MySQL See Relational Database description

RDBMS http://www.mysql.com/

Apache Module mod_proxy

See HTTP Transparent Proxy




No relationships to the catalogue of standards.

http://www.mysql.com/




3.2.10 Application Examples

Examples of the application of this pattern can be found on the project EzWeb. Particularly at http://ezweb.tid.es the reader will find an instantiation of this pattern and the Mashup as a Service paradigm.

http://ezweb.tid.es/


3.3 Context of Use Management Pattern


Name Context of Use Management

Credits MyMobileWeb

Type Architectural Pattern

Key Concerns

Presentation

Abstract This pattern describes the architecture of a component able to detect, to represent and to provide the information about the Context of Use for SFEs. The Context Of Use is a dynamic, structured information space that includes a model of the user, U, (who is intended to use or is actually using the system), the hardware-software platform, P,(which includes the set of computing, sensing, communication, and interaction resources that bind together the physical environment with the digital world), and the social and physical environment, E, (where the interaction is actually taking place). Thus, a context of use is a triple composed by (U, P, E)


Today’s Service Front-Ends (SFEs) are often designed with the assumption that they are going to be used in a single, static, predefined context of use. Such a context usually involves an able-bodied user who is using a typical set of input and output devices (e.g., a desktop / laptop computer) and who is sitting in a stable environment (e.g., home, office). Any deviation from this assumption (for instance, hand tremor due to aging or low vision for a user, switching from one device to another such as from a feature phone to a multi-touch smartphone, riding on the noisy environment of a jostling bus) may significantly hamper users’ effectiveness — not because of any inherent barrier to interaction, but because of a mismatch between the effective context(s) of use (and its evolution over time and space) and the static, predefined context of use.

Currently, this diversity of needs and demands are either ignored or are addressed in one of two ways: a manual UI redesign for a new context or a transcoded UI for this new context. For instance, an external assistive technology can provide a mechanism for adapting UIs to users with motor or perceptual impairments. These approaches are clearly not scalable: new contexts of use constantly appear. Indeed, new users come in with different capabilities with even more varying abilities and preferences, new devices constantly enter the market, and people evolve in environments that cannot be anticipated.

A ―one size fits all‖ approach obviously does not accommodate the broad range of contexts of use, neither a ―many sizes fit all‖ since the perpetual movement of change will never be fitted by any predefined technique. Many interfaces are needed because of the myriad of distinct individuals, each with his or her own abilities, preferences, computing platforms and needs which can arise in


different environments and situations. Therefore, traditional manual interface design and engineering will not scale to such a broad range of potential contexts of use. A different approach is needed.

Context is an all-embracing term. Composed of ―con‖ (with) and ―text‖, context refers to the meaning that must be inferred from the adjacent text. As a result, to be operational, context can only be defined in relation to a purpose, or finality [CRO02]. In the field of context-aware computing a definition of Context that has been largely used is provided by [DEY00]: Context is any information that can be used to characterize the situation of entities (i.e. whether a person, place or object) that are considered relevant to the interaction between a user and an application, including the user and the application themselves. Context is typically the location, identity and state of people, groups and computational and physical objects.

While the above definition is rather general, thus encompassing many aspects, it is not directly operational. Hence, we hereby define the Context of Use of an interactive system as a dynamic, structured information space that includes the following entities:

a model of the User, U, (who is intended to use or is actually using the system)

the hardware-software Platform, P, (which includes the set of computing, sensing, communication, and interaction resources that bind together the physical environment with the digital world)

the social and physical Environment, E, (where the interaction is actually taking place).

Thus, a context of use is a triple composed by (U, P, E).

The User represents the human being (or a human stereotype) who is interacting with the system. The characteristics modelled or relevant can be very dependant on the application domain. Specific examples are age, level of experience, the permissions, preferences, tastes, abilities and disabilities, short term interests, long term interests, etc. In particular, perceptual, cognitive and action disabilities may be expressed in order to choose the best modalities for the rendering and manipulation of the interactive system.

The Platform is modeled in terms of resources, which in turn, determine the way information is computed, transmitted, rendered, and manipulated by users. Examples of resources include memory size, network bandwidth, and input and output interaction devices. [CCB02] distinguishes between elementary platforms (e.g. laptop, PDA, mobile phone), which are built from core resources (e.g. memory, display, processor) and extension resources (e.g. external displays, sensors, mice), and clusters, which are built from elementary platforms. Resources motivate the choice for a set of input and output modalities and, for each modality, the amount of information made available.

The Environment denotes the set of objects, persons and events that are peripheral to the current activity but that may have an impact on the system and/or users behaviour, either now or in the future (Coutaz and Rey, 2002). According to our definition, an environment may encompass the entire world. In


practice, the boundary is set up by domain analysts whose role is to elicit the entities that are relevant to the case at hand. Specific examples are: user's location, ambient sound, lighting or weather conditions, present networks, nearby objects, user's social networks, level of stress...

The relationship between a UI and its contexts of use leads to the following definitions:

Multi-target (or multi-context) UI

A multi-target (or multi-context) UI supports multiple types of users, platforms and environments. Multi-user, multi-platform and multi-environment UIs are specific classes of multi-target UIs which are, respectively, sensitive to user, platform and environment variations. [CCTLBV03]

Adaptive UI

An Adaptive UI refers to a UI capable of being aware of the context of use and to (automatically) react to changes of this context in a continuous way (for instance, by changing the UI presentation, contents, navigation or even behaviour).

Adaptable UI

An Adaptable UI can be tailored according to a set of predefined options. Adaptability normally requires an explicit human intervention. We can find examples of UI adaptability on those word processors where the set of buttons contained by toolbars can be customized by end users.

Plastic UI

A Plastic UI is a multi-target UI that preserves usability across multiple targets. Usability is not intrinsic to a system. Usability can only be validated against a set of properties set up in the early phases of the development process. [CCTLBV03]

The present pattern describes an architectural solution aimed to the sense and provision of the information about the Context of Use of an interactive system. Such an architecture is intended to enable the creation of multi-target, adaptive, adaptable and plastic user interfaces.



Here after a subset of the conceptual model is reported. The defined concepts are necessary for the description of the functional requirements. These are here reported for completeness reasons.

The figure below depicts graphically the "Context of Use" Model proposed by the NEXOF-RA Project. Such a Model captures the Context of Use in which a user is interacting with a particular computing platform in a given physical environment in order to achieve an interactive task.

Context of Use is the main entity which has been modelled as a an aggregation of User, Platform and Environment. They are all Context Elements. A Context Element is an instance of Context Entity. A Context Property represents a characteristic of a Context Element or information about its state. A Context Property might be associated to zero or more instances of Context Value. Examples of Context Property instances are: 'position', 'age' or 'cpuSpeed'. There can be Context Property instances composed by other sub-properties. For example, the 'position' property is typically composed by: 'latitude', 'longitude' and 'altitude'. Both a Context Property and a Context Value can be associated to different metadata represented by the Context Property Description and Context Value Description classes respectively. A Context Property can be obtained from different Context Providers. A Device Description Repository (DDR) is a Context Provider of information about the "a priori known" characteristics of Platform Components, particularly devices or web browsers.

Figure 39 Functionalities provided by the Context Of Use Management



System

Provide Context of Use

Service Front-End

Monitor Context of Use

Figure 40 Functionalities provided by the Context Of Use Management

provideContextOfUse: this functionality enables the retrieval of the values of the context properties of the different context elements from a set of context providers available in the system.

monitorContextOfUse: this functionality enables the monitoring of the values of the context properties of the different context elements from a set of context providers available in the system.


Integrability +


+

Reusability +

Security (Auditability) +

Security (Authorization) +

Performance (Response Time) -


3.3.4.1 Rational

The presented pattern defines the architecture of a software infrastructure for managing the Context of Use of an interactive system. The proposed architecture identifies three different layers. The API layer (provision and monitoring), which offers a programmatic interface for getting access and for monitoring the Context of Use. The mediation layer, in charge of providing a uniform view of the Context of Use, hiding the complexities of gathering (possibly distributed) contextual information. And finally, the sensing layer which knows all the technical details (including protocols) needed to gather the information from the different Context Providers.

The proposed pattern affects positively to the integrability, as different and heterogeneous Context Providers can work within the system, provided a connector is made available to the sensing layer. For the same reasons the pattern aims to increase the extension of capability.

The pattern aims to increase the reusability by defining a mediation layer which it is independent of the context provision infrastructure. In addition the pattern is independent of the Context Properties and it can work with any property that fits in the proposed Context Model.

The pattern promotes an authorization schema that controls every access to a Context Property. Hence both security and auditability are improved.

Finally, it has to be remarked that the response time is negatively affected due to both the granularity of the security checks and the division of the system in three layers which adds a significant overhead. Particularly, the dynamic invocations that are issued by the sensing layer to the different Context Providers.

3.3.5 Assumptions

This section describes the context where the proposed pattern is applicable.

ContextOfUseManagement<<subsystem>>

IR_ContextOfUseManagement

+notifyPropertyEvent(e: Event)+isAuthorized()+sendMessage(a: Agent, m: Message)

Figure 41 Functionalities required by the Context of Use Management Subsystem

A summarized the description of the functional assumptions (in terms of high level functionalities) of the pattern and their rationale:

notifyPropertyEvent: this functionality needs to be present and implemented by those components interested in receiving events of interest coming from the Context of Use Management component.


isAuthorized: The Context of Use Management component infrastructure needs this functionality in order to perform user authentication and authorization.

sendMessage: The component requires this functionality to send a

message to other agents in the system.

3.3.6 Solution

The diagram below shows the architectural choices made by the pattern to design a ―Context Of Use Management‖ component. It introduces the components and their provided and required interfaces.

ContextOfUseManagement<<subsystem>>

IR_ContextOfUseManagement

+notifyPropertyEvent(e: Event)+isAuthorized()+sendMessage(a: Agent, m: Message)

IP_ContextOfUse

+getPropertyValue(ContextElement, ContextProperty)+getAllPropertyValues(ContextElement)+watchProperty(ContextElement, ContextProperty, MonitoringPolicies): watchId+watchElement(ContextElement): watchId+registerProvider(ContextElement, ContextProperty, ProviderDescription)+unRegisterProvider(ContextElement, ContextProperty, ProviderDescription)+expressInterest(ContextElement, ContextProperty, InterestPolicies)+withdrawInterest(ContextElement, ContextProperty)+clearWatch(watchId)

Figure 42 Context of Use Management (provided and required interfaces)

ContextofUse_Provision

ContextOfUse_Mediation

ContextofUse_Sensing

ContextofUse_Monitoring

Figure 43 Context of Use Management components and their dependencies





IP_ContextofUse_Provision

+getPropertyValue(ContextElement, ContextProperty)+getAllPropertyValues(ContextElement)

IR_Context_Notify

+notifyPropertyEvent()

IP_ContextOfUse_Mediation

+registerProvider(ContextElement, ContextProperty, ProviderDescription)+unRegisterProvider(ContextElement, ContextProperty, ProviderDescription)+expressInterest(ContextElement, ContextProperty, InterestPolicies)+withdrawInterest(ContextElement, ContextProperty)+determineProviders(ContextElement, ContextProperty)+calculatePropertyValue(ContextElement, ContextProperty)+obtainPropertyValue(ContextElement, ContextProperty)+obtainAllPropertyValues(ContextElement)+subscribeToProperty(ContextElement, ContextProperty, MonitoringPolicies)+unsubscribeToProperty(ContextElement, ContextProperty)+subscribeToElement(ContextElement)+unsubscribeToElement(ContextElement)

IP_ContextofUse_Sensing

+getData(ProviderDescription)+monitorData(ProviderDescription)+clearMonitorData(ProviderDescription)+invokeProvider(ProviderDescription)

IP_ContextofUse_Monitoring

+watchProperty(ContextElement, ContextProperty, MonitoringPolicies): watchId+clearWatch(watchId)+watchElement(ContextElement, MonitoringPolicies): watchId


IR_ContextOfUse_Sensing


IR_Security

+isAuthorized()

Figure 44 Context of Use Management Pattern




Context of Use Provision


IP_ContextofUse_Provision

+getPropertyValue(ContextElement, ContextProperty)+getAllPropertyValues(ContextElement)

IR_ContextOfUse_Provision

+obtainPropertyValue(ContextElement, ContextProperty)+obtainAllPropertyValues(ContextElement)+isAuthorized()

Figure 45 Context of Use Provision component (provided and required interfaces)

This component is in charge of providing information about the Context of Use (User, Platform and Environment).


Provided Operations

− getPropertyValue(ContextElement, ContextProperty)

This operation represents the functionality that allows retrieving the value of a context property pertaining to a context element.

− getAllPropertyValues(ContextElement)

This operation represents the functionality that allows retrieving the value of all context properties pertaining to a context element.

Required Operations

− obtainPropertyValue(ContextElement, ContextProperty)

This operation represents the functionality that obtains the value of a context property of a context element.

− obtainAllPropertyValues(ContextElement)

This operation represents the functionality that obtains the value of all context properties of a context element.

− isAutorized()



Context of Use Monitoring

IP_ContextofUse_Monitoring

+watchProperty(ContextElement, ContextProperty, MonitoringPolicies): watchId+clearWatch(watchId)+watchElement(ContextElement, MonitoringPolicies): watchId


IR_ContextOfUse_Monitoring

+subscribeToProperty(ContextElement, ContextProperty, MonitoringPolicies)+unsubscribeProperty(ContextElement, ContextProperty)+subscribeToElement(ContextElement)+unsubscribeToElement(ContextElement)+notifyPropertyEvent()+isAuthorized()

Figure 46 Context of Use Monitoring component (provided and required interfaces)

It is the component which implements the infrastructure that performs the monitoring of properties and elements of the Context, notifying of changes on its values.


Provided Operations

− watchProperty(ContextElement, ContextProperty,

MonitoringPolicies): watchId

This operation represents the request of the watching of a context property of a context element, in accordance with the policies (thresholds, notification conditions) expressed in the MonitoringPolicies.

− clearWatch (watchId)

This operation represents the request of the removal of the watching indicated by the watchId.

− watchElement(ContextElement, MonitoringPolicies):

watchId

This operation represents the request of the watching of all the context properties of a context element, with the policies expressed in the MonitoringPolicies.

Required Operations

− subscribeToProperty(ContextElement, ContextProperty,

MonitoringPolicies)

This operation represents the request to mediation layer for the subscription to a context property of a context element, with the policies indicated by the MonitoringPolicies parameter.

− unsubscribeProperty(ContextElement, ContextProperty)

This operation represents the request for the removal of property subscription.

− subscribeToElement(ContextElement)


This operation represents the request of the subscription to changes in the value of all the context properties of a context element.

− unsubscribeToElement(ContextElement)

This operation represents the request for finishing the subscription to changes in the value of all the context properties of a context element.

− notifyPropertyEvent(Event e)

This operation notifies an event produced by a change in a context property of a context element.

− isAutorized()


Context of Use Mediation


IP_ContextOfUse_Mediation

+registerProvider(ContextElement, ContextProperty, ProviderDescription)+unRegisterProvider(ContextElement, ContextProperty, ProviderDescription)+expressInterest(ContextElement, ContextProperty, InterestPolicies)+withdrawInterest(ContextElement, ContextProperty)+determineProviders(ContextElement, ContextProperty)+calculatePropertyValue(ContextElement, ContextProperty)+obtainPropertyValue(ContextElement, ContextProperty)+obtainAllPropertyValues(ContextElement)+subscribeToProperty(ContextElement, ContextProperty, MonitoringPolicies)+unsubscribeToProperty(ContextElement, ContextProperty)+subscribeToElement(ContextElement)+unsubscribeToElement(ContextElement)

IR_ContextofUse_Mediation


Figure 47 Context of Use Mediation component (provided and required interfaces)

This component provides a uniform view of the context of use regardless of its distribution or underlying infrastructure. As a matter of fact it is in charge of locating the different context providers available in the system when trying to retrieve the values of the context properties of the context elements. If more than one Context Provider is available for a concrete context property, an algorithm could be use to integrate the different values obtained by the different context providers.


Provided Operations

− registerProvider(ContextElement, ContextProperty,

ProviderDescription)

This operation adds a new provider, defined by the ProviderDescription, to be available for future requests for retrieving the value of the ContextProperty of the ContextElement.


− unregisterProvider(ContextElement, ContextProperty,

ProviderDescription)

This operation removes the association between a Provider and a Property.

− expressInterest(ContextElement, ContextProperty,

InterestPolicies)

This operation allows to notify to the Context Management System, the future interest in retrieving the value of the ContextProperty of a ContextElement. This expression of interest allows the system to set up the necessary infrastructure for dealing with a future request of a property value.

− withdrawInterest(ContextElement, ContextProperty)

This operation notifies to the Context Management System that the interest on a certain property has been lost. As a result the system might release all the resources previously allocated for such a property.

− determineProviders(ContextElement, ContextProperty)

This operation determines all the available Context providers for retrieving the value of the ContextProperty pertaining to a ContextElement.

− calculatePropertyValue(ContextElement, ContextProperty)

This operation performs the calculation to determine the value of the ContextProperty of a ContextElement in accordance with the (possibly) various values supplied by providers. All the data transformations are also performed by this method.

− obtainPropertyValue(ContextElement, ContextProperty)

This operation represents the functionality intended to obtain the value of a context property of a context element.

− obtainAllPropertyValues(ContextElement)

This operation represents the functionality intended to obtain the value of all context properties of a context element.

− subscribeToProperty(ContextElement, ContextProperty,

MonitoringPolicies)

This operation represents the request of the subscription to changes in the value of a context property of a context element, in accordance with the policies expressed in the MonitoringPolicies.

− unsubscribeProperty(ContextElement, ContextProperty)

This operation represents the request of the removal of the subscription to changes in the value of a context property of a context element.


− subscribeToElement(ContextElement)

This operation represents the request of the subscription to changes in the value of all the context properties of a context element.

− unsubscribeToElement(ContextElement)

This operation represents the request of the removal of the subscription to changes in the value of all the context properties of a context element.

Required Operations

− getData(ProviderDescription)

This operation retrieves context data from a defined context provider. It is in charge of establishing the protocol needed to communicate with the context provider to obtain the data.

− monitorData(ProviderDescription)

This operation makes the monitoring of the context data from a defined context provider. It is in charge of establishing the protocol needed to communicate with the context provider to monitor the data.

− clearMonitorData(ProviderDescription)

This operation removes the monitoring of the context values from a defined context provider, releasing resources if needed.

− invokeProvider(ProviderDescription)

This operation invokes, through the corresponding adaptor, a defined context provider from the list of available context providers of the system.

Context Of Use Sensing


IP_ContextofUse_Sensing


IR_ContextOfUse_Sensing


Figure 48 Context of Use Sensing component (provided and required interfaces)

This component is in charge of sensing the context through the communication with the different context providers of the system.


Provided Operations

− getData(ProviderDescription)

This operation get access to context data from a defined context provider. It is in charge of establishing the protocol needed to communicate with the context provider to obtain the data.


− monitorData(ProviderDescription)

This operation performs the monitoring of the context data from a defined context provider. It is in charge of establishing the protocol needed to communicate with the context provider to monitor the data.

− clearMonitorData(ProviderDescription)

This operation removes the monitoring of the context values from a defined context provider.

− invokeProvider(ProviderDescription)

This operation invokes, through the corresponding adaptor, a defined context provider from the list of available context providers of the system.

Required Operations





This section describes how the different components collaborate to realize the provided functionalities of the overall system. The realization of some internal functionalities is described as well, to clarify the behaviours of the system when they can raise some ambiguity or they can be useful for the refinement of this pattern.

getPropertyValue

The figure below shows the sequence diagram for the ―getPropertyValue‖ functionality.

: IP_ContextOfUse

: Service Front-End

: ContextofUse_Provision : IR_Security : ContextOfUse_Mediation : ContextofUse_Sensing

1 : getPropertyValue()2 : getPropertyValue()

3 : isAuthorized()

4 : true5 : obtainPropertyValue()

6 : determineProviders()

7 *[1..*] : getData()8 : invokeProvider()

9

10 : calculatePropertyValue()

11 : value

12 : value

13 : value

Figure 49 Sequence diagram for getPropertyValue

A Service Front-End needs to obtain the value of a Context Property. The ContextofUseProvision is the responsible of implementing such functionality. Before, granting access, an authorization check has to be done. After this checking, a call to the ContextOfUseMediation is made to obtain the propertyValue. The ContextOfUseMediation determine the available providers that have the capability to offer the required data, and makes an invocation (through the ContextOfUseSensing) for each of them. With those values it calculates the final requested value and returns it.


getAllPropertyValues

The figure below shows the sequence diagram for the ―getAllPropertyValues‖ functionality.

: IP_ContextOfUse

: Service Front-End

: ContextofUse_Provision : IR_Security : ContextOfUse_Mediation : ContextofUse_Sensing

1 : getAllPropertyValues()2 : getAllPropertyValues()

3 : isAuthorized()

4 : true5 : obtainAllPropertyValues()


7 *[1..*] : getData()8 : invokeProvider()

9

10 *[1..*] : calculatePropertyValue()

11 : values[]

12 : values[]

13 : values[]

Figure 50 Sequence diagram for getAllPropertyValues

A Service Front-End needs to obtain the value of all the Context Properties of a Context Element. The ContextofUseProvision is the responsible of implementing such functionality. Before, granting access, an authorization check has to be done. After this checking, a call to the ContextOfUseMediation is made to obtain all the property values. The ContextOfUseMediation determine the available providers that have the capacity to offer the required data, and issues an invocation to each of them. With those values it calculates the final requested values and returns them.


watchProperty

The figure below shows the sequence diagram for the ―watchProperty‖ functionality.

: IP_ContextOfUse

: Service Front-End

: IR_Security : ContextOfUse_Mediation : ContextofUse_Sensing : ContextofUse_Monitoring

1 : watchProperty()

2 : watchProperty()3 : isAuthorized()

4 : true

5 : subscribeToProperty()


7 *[1..*] : monitorData()8 : invokeProvider()

9

10 : ok

11 : ok

12 : ok

Figure 51 Sequence diagram for watchProperty

A Service Front-End needs to monitor the value of a Context Property. The ContextofUseMonitoring is the responsible of implementing such functionality. Before, granting access, an authorization check has to be done. After this checking, a call to the ContextOfUseMediation is made to start monitoring the property. The ContextOfUseMediation determine the available providers that have the capacity to offer the required data, and notifies all of them.


watchElement

The figure below shows the sequence diagram for the ―watchElement‖ functionality.

: IP_ContextOfUse

: Service Front-End


1 : watchElement()

2 : watchElement()3 : isAuthorized()

4 : true

5 : subscribeToElement()


7 *[1..*] : monitorData()8 : invokeProvider()

9

10 : ok

11 : ok

12 : ok

Figure 52 Sequence diagram for watchElement

A Service Front-End needs to monitor the changes occurring on a Context Element. The ContextofUseMonitoring is the responsible of implementing such functionality. Before, granting access, an authorization check has to be done. After this checking, a call to the ContextOfUseMediation is made to monitor the Context Element. The ContextOfUseMediation determine the available providers that have the capacity to offer the required data, and makes all the necessary invocations.


clearWatch

The figure below shows the sequence diagram for the ―clearWatch‖ functionality.

watchIDseq

: IP_ContextOfUse

: Service Front-End


1 : clearWatch()

2 : clearWatch()3 : isAuthorized()

4 : true

5 : unsubscribeToProperty()


7 *[1..*] : clearMonitorData()

8 : invokeProvider()

9

10 : ok

11 : unsubscribeToElement()


13 *[1..*] : clearMonitorData()

14 : invokeProvider()

15

16 : ok

17 : ok

18 : ok

[watchID belongs to Property]

[watchID belongs to Element]

Figure 53 Sequence diagram for clearWatch

A Service Front-End needs to clear the monitorization of a Context Property or a Context Element. The ContextofUseMonitoring is the responsible of implementing such functionality. Before, granting access, an authorization check has to be done. After this checking, and depending if the watchID corresponds to a Context Property or to a Context Element a call to the ContextOfUseMediation is made to clear the monitoring of the Context Property or the Context Element. The ContextOfUseMediation determines the available providers that have the capacity to monitor that data, to require the monitorization end.


registerProvider

The figure below shows the sequence diagram for the ―registerProvider‖ functionality.

: IP_ContextOfUse

: Service Front-End

: IR_Security : ContextOfUse_Mediation

1 : registerProvider()


3 : isAuthorized()

4 : true


6 : ok

7 : ok

Figure 54 Sequence diagram for registerProvider

A Service Front-End needs to register a new Context Provider. The ContextofUseMediation is the responsible of implementing such functionality. Before, granting access, an authorization check has to be done. After this checking, the new Context Provider is registered.


unregisterProvider

The figure below shows the sequence diagram for the ―unregisterProvider‖ functionality.

: IP_ContextOfUse

: Service Front-End


1 : unRegisterProvider()


3 : isAuthorized()

4 : true


6 : ok

7 : ok

Figure 55 Sequence diagram for unregisterProvider

A Service Front-End needs to unregister a Context Provider. The ContextofUseMediation is the responsible of implementing such functionality. Before, granting access, an authorization check has to be done. After this checking, the Context Provider is no longer available.


expressInterest

The figure below shows the sequence diagram for the ―expressInterest‖ functionality.

: IP_ContextOfUse

: Service Front-End


1 : expressInterest()

2 : expressInterest()

3 : isAuthorized()

4 : true

5 : ok

6 : ok

Figure 56 Sequence diagram for expressInterest

A Service Front-End wants to inform about its future interest in a Context Property. The ContextofUseMediation is the responsible of implementing such functionality. Before, granting access, an authorization check has to be done. After this checking, the interest on such a Context Property is reflected.


withdrawInterest

The figure below shows the sequence diagram for the ―withdrawInterest‖ functionality.

: IP_ContextOfUse

: Service Front-End


1 : withdrawInterest()

2 : withdrawInterest()

3 : isAuthorized()

4 : true

5 : ok

6 : ok

Figure 57 Sequence diagram for publishing a withdrawInterest

A Service Front-End wants to indicate that it is no longer interested in a Context Property. The ContextofUseMediation is the responsible of implementing such functionality. Before, granting access, an authorization check has to be done. After this checking, it registers the withdrawal of interest for that Context Property.



The following diagram shows the relationship of the ―ContextOfUseManagement‖ Pattern with the ―Front-End in E-SOA‖ pattern.

Enterprise SOA

Designer and RuntimeTools for E-SOA

Front End in E-SOA

isPartOf[Designer Tool, Runtime, Management Tool]

isPartOf[GUIDesigner, GUIRuntime]

Context of Use Management

isPartOf[ContextOfUseManager]

Figure 58 Relationship between “Context of Use Management” and “Front End in E-SOA” patterns

The ―Context of Use Management‖ pattern is part of the ―Front-End in E-SOA‖ pattern. This pattern provides the architecture of the ―Context of Use Management‖ component. More specifically the ―Context of Use Management” has been refined into four main components: the ―Provision‖, the ―Monitoring‖, the ―Mediation‖ and the ―Sensing‖.

The diagram below shows the relationship of the ―ContextOfUseManagement‖ Pattern with the ―Mashup as a Service‖ pattern. The ―Context of Use Management‖ pattern is part of the ―Mash up As a Service‖ pattern. This pattern provides the architecture of the ―Context of Use Management‖ component. More specifically the ―Context of Use Management” has been refined into four main components: the ―Provision‖, the ―Monitoring‖, the ―Mediation‖ and the ―Sensing‖.


IoS

Mashup as a service

isPartOf[UserInterface, Service Execution]

Context of Use Management

isPartOf[ContextOfUseManager]

Figure 59 Relationship between “Context of Use Management” and “Mashup as a Service” patterns


The following sections detail the relationships of the components of this pattern with regard to the NEXOF Reference Architecture.

3.3.8.1 Abstract Components Name Description of the main features


Provides information about the a priori known characteristics of a Delivery Context. For example, what is the resolution width or the input mechanisms of a device.

3.3.8.2 Concrete Components Name Description of

the main features



TID’s Device Description Framework

See Device Description Repository




3.3.9.1 Delivery Context Ontology

The Delivery Context Ontology [Cantera 2009] provides a formal model of the characteristics of the environment in which devices interact with the Web or other services. The delivery context includes the characteristics of the device, the software used to access the service and the network providing the connection among others.




The delivery context is an important source of information that can be used to adapt materials to make them useable on a wide range of different devices with different capabilities.

The ontology is formally specified in the Web Ontology Language [OWL].


3.3.9.2 DDR Simple API

Web content delivered to mobile devices usually benefits from being tailored to take into account a range of factors such as screen size, markup language support and image format support. Such information is stored in "Device Description Repositories" (DDRs). The DDR Simple API [Rabin 2008] is an API for access to DDRs, in order to ease and promote the development of Web content that adapts to its Delivery Context.


3.3.10 Application examples

Examples of the application of this pattern can be found on the project MyMobileWeb.


REFERENCES

[CAL03]

Calvary, G., Coutaz, J., Thevenin, D., Limbourg, Q., Bouillon, L. and Vanderdonckt, J. (2003), A Unifying Reference Framework for Multi-Target User Interfaces, Interacting with Computers, V15N3, June, 289-308. (See http://www.isys.ucl.ac.be/bchi/publications/2003/Calvary-IwC2003.pdf)

[CAN09]

Jose Manuel Cantera, Rhys Lewis , Delivery Context Ontology, W3C Editor's Draft 02 March 2009. (See http://www.w3.org/2007/uwa/editors-drafts/DeliveryContextOntology/LastCallWD-March2009)

[CRO02]

Crowley, J., Coutaz, J., Rey, G., Reignier, P., 2002. Perceptual Components for Context- Aware Computing. Proceedings of International Conference on Ubiquitous Computing UbiComp’2002 (Göteborg, 29 September-October 1 2002). Lecture Notes in Computer Science Vol. 2498, Springer Verlag, Berlin, pp. 117–134.

[DEY01]

Anind K. Dey, Understanding and Using Context, Personal and Ubiquitous, volume 5, number 1, year 2001, pages 4-7.

[FLO06]

Murielle Florins, Graceful Degradation: a Method for Designing Multiplatform Graphical User Interfaces, Ph.D. thesis, Université catholique de Louvain, Louvain-la-Neuve, Belgium, 11 July 2006.

http://www.isys.ucl.ac.be/bchi/publications/Ph.D.Theses/Florins-PhD2006.pdf

[MariaXML]

Paternò F.; Santoro C.; Spano, L. D.: Designing Usable Applications based on Web Services; I-USED’08, September 24, 2008, Pisa, Italy

http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-407/paper15.pdf

[PAT03]

Paternò, F., Santoro, C., 2003. A Unified Method for Designing Interactive Systems Adaptable To Mobile And Stationary Platforms. Interacting with Computers, in this volume.

[RAG09]

Dave Raggett, Model-based User Interfaces Incubator Group Charter, W3C Incubator activity, 26 October 2009.

[SEF04]

http://www.isys.ucl.ac.be/bchi/publications/2003/Calvary-IwC2003.pdf

http://www.isys.ucl.ac.be/bchi/publications/2003/Calvary-IwC2003.pdf

http://www.w3.org/2007/uwa/editors-drafts/DeliveryContextOntology/LastCallWD-March2009

http://www.w3.org/2007/uwa/editors-drafts/DeliveryContextOntology/LastCallWD-March2009






Seffah, A., & Javahery, H. (2004). Multiple user Interfaces: Cross-Platform Applications and Context- Aware Interfaces. In A. Seffah & H. Javahery (Eds.), Multiple User Interfaces: Engineering and Application Framework (pp. 11-26). Chichester (GB): Wiley and Sons.

[USIXML]

UsiXML. User Interface eXtensible Markup Language. (See http://www.usixml.org/)

[W3C04]

W3C. Device Independent Working Group. (See http://www.w3.org/2004/05/di-charter-2004-06.html)

[W3C10]

W3C. (2010). Model-based User Interfaces Incubator Group Final Report (See )

[W3C09]

W3C. (2009). Accessible Rich Internet Applications (WAI-ARIA) 1.0. W3C Working Draft 24 February 2009. (See http://www.w3.org/TR/2009/WD-wai-aria-20090224/)

[W3C07]

W3C. (2007) Ubiquitous web applications activity (See http://www.w3.org/2007/uwa/)

http://www.usixml.org/

http://www.w3.org/2004/05/di-charter-2004-06.html

http://www.w3.org/TR/2009/WD-wai-aria-20090224/

http://www.w3.org/2007/uwa/

NESSI Open Framework Reference Architecture€¦ · NEXOF-RA • FP7-216446 • D1.1c Appendix A...

Documents

Transcript of NESSI Open Framework Reference Architecture€¦ · NEXOF-RA • FP7-216446 • D1.1c Appendix A...