NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 1 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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 2 of 105
Change History
Version Date Status Author (Partner) Description
1.0 15/06/2010 draft TID Initial Version
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 3 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 4 of 105
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
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 5 of 105
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.2 Problem Description ......................................................................... 57
3.2.3 Functional Requirements ................................................................. 59
3.2.4 Non-Functional Qualities (Quality Attributes) ................................... 60
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.2 Problem Description ......................................................................... 78
3.3.3 Functional Requirements ................................................................. 81
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 6 of 105
3.3.4 Non-Functional Qualities (Quality Attributes) ................................... 82
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
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 7 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 8 of 105
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‖.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 9 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 10 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 11 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 12 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 13 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 14 of 105
SFE Execution
SFE Acesss
SFE Rendering
SFE Delivery
SFE Connection Management
Contextual Adaptation
[Delivery Format]
Figure 3: Service Front End access scenario
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 15 of 105
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
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 16 of 105
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.
Related Business Requirement(s):
R11 Services integration by semantic mash-up
R17 Aided Configuration
R18 Modelling Capabilities
R37 Information Integration
R30 Integration of Services
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 17 of 105
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.
Related Business Requirement(s):
R2 Uniform service representation
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.
Related Business Requirement(s):
R2 Uniform service representation
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.
Related Business Requirement(s):
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.
Related Business Requirement(s):
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 18 of 105
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
Related system requirements:
Service Front-End Publication
User-Generated Service Front-Ends
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
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 19 of 105
Related system requirements:
End-User Composition of Personalized User Interfaces
Service Front-End Publication
User-Generated Service Front-Ends
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
Related system requirements:
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
Service Front-End Contextual Adaptation
End-User Composition of Personalized User Interfaces
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.
Related functionalities:
Resource Creation
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 20 of 105
Resource Sharing
Resource Deployment
Related requirements:
End-User Composition of Personalized User Interfaces
Service Front-End Publication
Source: EzWeb Strategic Project Contribution
Functionality name: Resource Deployment
Description: This functionality will allow to deploy service front-ends in a Service Oriented Infrastructure.
Related functionalities:
Resource Sharing
Resource Publication
Resource Creation
Related requirements:
End-User Composition of Personalized User Interfaces
Service Front-End Publication
Source: EzWeb Strategic Project Contribution
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.
Related functionalities:
Resource Publication
Resource Deployment
Resource Creation
Workspace Design
Resource Creation
Related requirements:
End-User Composition of Personalized User Interfaces
Service Front-End Publication
Source: EzWeb Strategic Project Contribution
Functionality name: Workspace Design and Personalization
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 21 of 105
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.
Related functionalities:
Context-Aware Resource Discovery
Resource Publication and Sharing
Related requirements:
End-User Composition of Personalized User Interfaces
Source: EzWeb Strategic Project Contribution
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.
Related functionalities:
Resource Publication and Sharing
Model-Based Engineering
Related requirements:
User-Generated Service Front-Ends
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.
Related functionalities:
User-Oriented Resource Authoring Tool
Related requirements:
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
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 22 of 105
delivery format that can be directly interpreted by a client platform, such as a Web Browser or similar.
Related functionalities:
Query Contextual Information
Automatic Resource Transcoding
Content & Application Adaptation
Related requirements:
End-User Access to Services
Service Front-End Contextual 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).
Related functionalities:
Subscription to Contextual Information
Connection to Context Providers
Related requirements:
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.
Related functionalities:
Query Contextual Information
Automatic Resource Transcoding
Content & Application Adaptation
Related requirements:
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 23 of 105
Related functionalities:
Automatic Resource Transcoding
Content & Application Adaptation
Query Contextual Information
Subscription to Contextual Information
Related requirements:
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.
Related functionalities:
Query Contextual Information
Related requirements:
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.
Related functionalities:
Query Contextual Information
Subscription to Contextual Information
Related requirements:
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
Related functionalities:
Content & Application Adaptation
Service Front-End Rendering
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 24 of 105
Related requirements:
Service Front-End Contextual Adaptation
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.
Related functionalities:
Automatic Resource Transcoding
Application Adaptation and Personalization
Service Front-End Rendering
Related requirements:
Service Front-End Contextual Adaptation
End-User Access to Services
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.
Related functionalities:
Content Adaptation and Personalization
Service Front-End Rendering
Related requirements:
Service Front-End Contextual Adaptation
End-User Access to Services
Context Management
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 25 of 105
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.
Related functionalities:
Domain Model Management
Related requirements:
End-User Access to Services
End-User Composition of Personalized User Interfaces
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.
Related functionalities:
Service Front-End Persistence
Content & Application Adaptation
Domain Model and User Interface binding
Related requirements:
End-User Access to Services
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.
Related functionalities:
Domain Model Management
Related requirements:
End-User Access to Services
Source: Standard (XForms 1.1 [XFORMS])
Functionality name: Interaction Management
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 26 of 105
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).
Related functionalities:
Domain Model and User Interface binding
Related requirements:
End-User Access to Services
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.
Related functionalities:
Interaction Management
Related requirements:
User’s Knowledge Exploitation
Source: Contribution coming from the EzWeb NESSI Strategic Project and FAST Project
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 27 of 105
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])
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 28 of 105
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,
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 29 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 30 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 31 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 32 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 33 of 105
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)
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 34 of 105
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
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 35 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 36 of 105
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
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 37 of 105
E-SOA Front-End
SFER Access Platform
ContextOfUse Manager
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
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 38 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 39 of 105
− 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.
The exposed operations are:
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
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 40 of 105
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)
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 41 of 105
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.
SFER Access Platform
SFER Access Platform
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.
The exposed operations are:
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 42 of 105
− 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
− getContextOfUse(e: Evidence): ContextOfUse
This functionality is required to obtain the characteristics of the Context of Use to adapt accordingly the user interface offered by a SFE Resource.
− 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 Resources. 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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 43 of 105
ContextOfUse Manager
ContextOfUse Manager
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.
The exposed operations are:
Provided Operations
− getContextOfUse(e: Evidence): ContextOfUse
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.
− 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.
Required Operations
− notifyEvent(e: Event)
This component requires this functionality to notify events to the clients
that have subscribed their interest though the subscribeEvent
method.
− 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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 44 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 45 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 46 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 47 of 105
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()
6 : getContextOfUse()
7 : Context Of Use
8 *[1..*] : accessSFER()
9 : getContextOfUse()
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 48 of 105
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
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 49 of 105
An administrator needs to undeploy a SFER. The SFER Access Platform first checks for authorization, and then perform the undeployment.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 50 of 105
startAgentForSFER
The figure below shows the sequence diagram for the ―undeploySFER‖ functionality.
: 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
The figure below shows the sequence diagram for the ―undeploySFER‖ functionality.
: 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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 51 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 52 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 53 of 105
sendMessage
See the Designer and Runtime Tools in E-SOA pattern.
getLoggedData
See the Designer and Runtime Tools in E-SOA pattern.
subscribeEvent
See the Designer and Runtime Tools in E-SOA pattern.
configureMonitoringPolicy
See the Designer and Runtime Tools in E-SOA pattern.
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 54 of 105
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
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 Transparent Proxy
http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 55 of 105
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.
Related Abstract Components: Device Description Repository
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
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 56 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 57 of 105
3.2 Mashup as a Service Pattern
3.2.1 Pattern ID-Card
3.2.2 Problem Description
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])
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 58 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 59 of 105
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.
3.2.3 Functional Requirements
The following use-case diagram shows the functional requirements that this pattern meets.
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
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 60 of 105
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.
3.2.4 Non-Functional Qualities (Quality Attributes)
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 61 of 105
Availability -
Integrability +
Modifiability (Adaptation to new operating environments)
+
Modifiability (Extension of capability)
+
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 62 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 63 of 105
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
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 64 of 105
Figure 31 MaaS Pattern
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 65 of 105
3.2.6.1 Component Descriptions
The components of the architecture are described as follows:
Mashup Designer
Figure 32 Mashup Designer component (provided and required interfaces)
This component enables a Mashup Creator to design a Mashup.
The exposed operations are:
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 66 of 105
− 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:
− 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.
− 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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 67 of 105
− 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)
It adds the selected gadget to the actual group of gadget of the workspace.
− removeGadget(g: Gadget, w: Workspace)
It removes the selected gadget from the 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.
− createWorkspace(): 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
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 68 of 105
Figure 33 Mashup Access component (provided and required interfaces)
This component enables a Mashup User to access and use a Mashup.
The exposed operations are:
Provided Operations:
− 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.
− 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.
− 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:
− createWorkspace(): 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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 69 of 105
− 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 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…)
The exposed operations are:
Provided Operations:
− createWorkspace(): 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.
− setPreferenceForGadget(g: Gadget, p: Preferences)
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 70 of 105
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.
− 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.
− addGadget(g: Gadget, w: Workspace)
It adds the selected gadget to the actual group of gadget of the workspace.
− removeGadget(g: Gadget, w: Workspace)
It removes the selected gadget from the 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.
Required Operations:
− 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.
− 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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 71 of 105
− 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.
− untagGadget(g : Gadget, t: Tag)
This operation removes a tag from a gadget making the gadget no longer tagged with it.
− 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.
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.
The exposed operations are:
Provided Operations:
− 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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 72 of 105
− 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.
− untagGadget(g : Gadget, t: Tag)
This operation removes a tag from a gadget making the gadget no longer tagged with it.
− 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.
− untagMashup(m : Mashup, t: Tag)
This operation removes a tag from a mashup making the mashup no longer tagged with it.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 73 of 105
3.2.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.
createMashup
The figure below shows the sequence diagram for the ―createMashup‖ functionality.
Figure 36 Sequence diagram for creating a Mashup
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 74 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 75 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 76 of 105
3.2.7 Relationships to other patterns
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.
3.2.8 Relationships to Components Catalogue
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
HTTP Transparent Proxy
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
Related abstract component
Reference to the concrete implementation
MySQL See Relational Database description
RDBMS http://www.mysql.com/
Apache Module mod_proxy
See HTTP Transparent Proxy
HTTP Transparent Proxy
http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
3.2.9 Relationships to Standards Catalogue
No relationships to the catalogue of standards.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 77 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 78 of 105
3.3 Context of Use Management Pattern
3.3.1 Pattern ID-Card
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)
3.3.2 Problem Description
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
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 79 of 105
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
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 80 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 81 of 105
3.3.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 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
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 82 of 105
The following use-case diagram shows the functional requirements that this pattern meets.
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.
3.3.4 Non-Functional Qualities (Quality Attributes)
Integrability +
Modifiability (Extension of capability)
+
Reusability +
Security (Auditability) +
Security (Authorization) +
Performance (Response Time) -
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 83 of 105
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 84 of 105
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
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 85 of 105
ContextofUse_Provision
ContextOfUse_Mediation
ContextofUse_Sensing
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
ContextofUse_Monitoring
IR_ContextOfUse_Sensing
+sendMessage(a: Agent, m: Message)
IR_Security
+isAuthorized()
Figure 44 Context of Use Management Pattern
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 86 of 105
3.3.6.1 Component Descriptions
The components of the architecture are described as follows:
Context of Use Provision
ContextofUse_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).
The exposed operations are:
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()
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 87 of 105
Context of Use Monitoring
IP_ContextofUse_Monitoring
+watchProperty(ContextElement, ContextProperty, MonitoringPolicies): watchId+clearWatch(watchId)+watchElement(ContextElement, MonitoringPolicies): watchId
ContextofUse_Monitoring
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.
The exposed operations are:
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)
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 88 of 105
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()
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.
Context of Use Mediation
ContextOfUse_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
+getData(ProviderDescription)+monitorData(ProviderDescription)+clearMonitorData(ProviderDescription)+invokeProvider(ProviderDescription)
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.
The exposed operations are:
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 89 of 105
− 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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 90 of 105
− 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
ContextofUse_Sensing
IP_ContextofUse_Sensing
+getData(ProviderDescription)+monitorData(ProviderDescription)+clearMonitorData(ProviderDescription)+invokeProvider(ProviderDescription)
IR_ContextOfUse_Sensing
+sendMessage(a: Agent, m: Message)
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.
The exposed operations are:
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 91 of 105
− 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
− sendMessage(m: Message, a: Agent)
The component requires this functionality to send a message to other agents in the system.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 92 of 105
3.3.6.2 Functionality Descriptions
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 93 of 105
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()
6 : determineProviders()
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 94 of 105
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()
6 : determineProviders()
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 95 of 105
watchElement
The figure below shows the sequence diagram for the ―watchElement‖ functionality.
: IP_ContextOfUse
: Service Front-End
: IR_Security : ContextOfUse_Mediation : ContextofUse_Sensing : ContextofUse_Monitoring
1 : watchElement()
2 : watchElement()3 : isAuthorized()
4 : true
5 : subscribeToElement()
6 : determineProviders()
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 96 of 105
clearWatch
The figure below shows the sequence diagram for the ―clearWatch‖ functionality.
watchIDseq
: IP_ContextOfUse
: Service Front-End
: IR_Security : ContextOfUse_Mediation : ContextofUse_Sensing : ContextofUse_Monitoring
1 : clearWatch()
2 : clearWatch()3 : isAuthorized()
4 : true
5 : unsubscribeToProperty()
6 : determineProviders()
7 *[1..*] : clearMonitorData()
8 : invokeProvider()
9
10 : ok
11 : unsubscribeToElement()
12 : determineProviders()
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 97 of 105
registerProvider
The figure below shows the sequence diagram for the ―registerProvider‖ functionality.
: IP_ContextOfUse
: Service Front-End
: IR_Security : ContextOfUse_Mediation
1 : registerProvider()
2 : registerProvider()
3 : isAuthorized()
4 : true
5 : registerProvider()
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 98 of 105
unregisterProvider
The figure below shows the sequence diagram for the ―unregisterProvider‖ functionality.
: IP_ContextOfUse
: Service Front-End
: IR_Security : ContextOfUse_Mediation
1 : unRegisterProvider()
2 : unRegisterProvider()
3 : isAuthorized()
4 : true
5 : unRegisterProvider()
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 99 of 105
expressInterest
The figure below shows the sequence diagram for the ―expressInterest‖ functionality.
: IP_ContextOfUse
: Service Front-End
: IR_Security : ContextOfUse_Mediation
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 100 of 105
withdrawInterest
The figure below shows the sequence diagram for the ―withdrawInterest‖ functionality.
: IP_ContextOfUse
: Service Front-End
: IR_Security : ContextOfUse_Mediation
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 101 of 105
3.3.7 Relationships to other patterns
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‖.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 102 of 105
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
3.3.8 Relationships to Components Catalogue
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
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.
3.3.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
Device Description Repository
http://forge.morfeo-project.org/projects/ddr-ri/
3.3.9 Relationships to Standards Catalogue
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.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 103 of 105
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.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.
Related Abstract Components: Device Description Repository
3.3.10 Application examples
Examples of the application of this pattern can be found on the project MyMobileWeb.
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 104 of 105
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]
NEXOF-RA • FP7-216446 • D1.1c Appendix A • Version 1, dated 15/06/2010 • Page 105 of 105
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/)
Top Related