+ All Categories
Home > Technology > Continuous service execution in mobile prosumer environments

Continuous service execution in mobile prosumer environments

Date post: 14-Jul-2015
Category:
Upload: unai-aguilera
View: 628 times
Download: 0 times
Share this document with a friend
Popular Tags:
28
UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010 Continuous service execution in mobile prosumer environments Unai Aguilera*, Aitor Almeida*, Pablo Orduña*, Diego López-de-Ipiña* and Rafael de las Heras + *DeustoTech- Universidad de Deusto Avda. Universidades 24, 48007, Bilbao, Spain + Telefónica I+D Emilio Vargas 6, 28043 Madrid, Spain {unai.aguilera, aitor.almeida, pablo.orduna, dipina}@deusto.es, [email protected]
Transcript

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

Continuous service execution in mobile prosumer environments

Unai Aguilera*, Aitor Almeida*, Pablo Orduña*, Diego López-de-Ipiña* and Rafael de las Heras+

*DeustoTech- Universidad de DeustoAvda. Universidades 24, 48007, Bilbao, Spain

+Telefónica I+DEmilio Vargas 6, 28043 Madrid, Spain

unai.aguilera, aitor.almeida, pablo.orduna, [email protected], [email protected]

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

Introduction

• mIO! project (http://www.cenitmio.es)

– Research on technologies for mobility service provision

• Service creation and execution, consumption, publication, network infrastructure, hardware, etc.

– The presented work focuses on an architecture for continuous service execution in a prosumerenvironment

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

Introduction

• Mobile prosumer environments– Users provide services using their mobile devices– Those services are consumed by other users’ devices

(near or remote)– Due to users’ mobility

• Prosumed services and used resources (location system, near printers, etc.) change

• Disruption of execution and consumption process occurs

– Devices are heterogeneous• Mobile devices provide different resources

(GPS, camera, display, keyboard, etc.)• Computation power

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

Introduction

• This work proposes an architecture for a mobile prosumer environment

– Enables a dynamic and continuous execution of services

– Provides a decoupled vision of participant elements (services and resources)

– Creation and execution of composite services

– Usage on devices with different computationalpower

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

• Created, provided and consumed by users of the mobile prosumer environment

• Creation:

– Using a tool on a PC or a mobile device

– A mIO! Service Template is obtained

• Published into repositories

• Discovery and use

mIO! Services

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

SDL

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

mIO! Services

• Execution:

– mIO! Service Templates are obtained from repositories and instantiated during execution

– Server/client architecture

– The service can be consumed

• Locally by the mIO! service provider (own user’s device)

• Remotely by other users

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

• Components

– Abstraction of functionality provided by type of capabilities (Map, Printer, Location, etc)

– Aid users during mIO! Service creation process

– Resolved during execution using available and compatible capabilities

Components

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

Capabilities

• Capabilities are the actual implementation of components

• Provide access to the real functionality their represent

• Hide the particular characteristics of the underlying resource (Hardware/Software)

• Include metadata information used during component resolution

• Classification– Near/Remote

– Internal/External

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

mIO! prosumer main concepts

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

mIO! Service execution architecture

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

Component resolution process

• Dynamic component resolution

– Resolve components depending on user’s mobility

– Fix capability access problems

– Uses currently available capabilities in the context

– Client/server side

– Includes monitoring of resolved components

– Minimize interruption of executed service

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

Execution Engine instantiates mIO! Service

template

Components are obtained from template

and passed to Harmonizer

Capability Proxy is used to find type compatible

capabilities

Compatible capabilities are filtered using a

matchmaker (syntactic/semantic)

Selected capability are linked to component

Capabilities can be accessed by mIO! Service logic through their linked

component

Events produced by the underlying capability are passed to the Execution

Engine through component

Harmonizer monitorizesresolved components

When the mIO! Service execution stops all used capabilities are released

Component resolution process

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

Capability selection

• Type compatibility of Component/Capability– States that a common set of known methods is implemented

– Uses a defined taxonomy of components/capabilities

– Advantage

• Reduces the complexity of the component/capability matching process including method/event forwarding

– Drawback

• Supported components and capabilities must be predefined

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

• Type compatible capabilities are filtered

– Restrictions

• Obtained for each used component in the mIO! Service Template and included by service’s creator

• Preferences obtained from the user who executes or access the service (client/server)

– Restrictions are used by the matchmaker to select a compatible capability

• Matched against the metadata included in capabilities

Filtering process

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

• Expressed in XML– Conditions could be transformed to query languages

• For example, SPARQL used during semantic matching process

– Enables to decouple the restriction representation from the final matching technology

• The matching process applies to – limited devices execute a syntactic matching process

– powerful devices execute a semantic matching process (previous transformation to SPARQL).

Restriction language

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

Restriction language

• Example of restriction language of GPS Component

Logic operator (AND/OR)

Condition about a property

Select result with minimum value

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

• Capability properties example: GPS

Capability properties

Semantic annotated property

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

Capability descriptions are converted to RDF and used to populate

the reasoner

Restrictions are converted to SPARQL

queries

Query is performed using the populated

reasoner

Results are returned to the Harmonizer

Best capability is selected (first result of

the query)

Result is used to resolve the component

Semantic matching process

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

Example of SPARLQ conversion

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

Syntactic matching process

• Conditions expressed as restrictions are used to selected compatible capabilities

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

Composite mIO! Services

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

• Composite mIO! Service are created

– Using a work-flow tool executed on mobile device or Personal Computer

– There are two different ways users could create their composite mIO! Service

• Creating and publishing a composite mIO! Service Template

• During mobility creating and ad-hoccomposition

Composite services

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

• Integration enables to apply the component resolution architecture to composite services

• mIO! Services enabled for composition

– mIO! Service must export their functionality through remote invoked methods

– Create a capability to encapsulate mIO! services

– Usage of a generic component which will be used to create the composite mIO! Service

Integration with component architecture

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

• An architecture for mobile prosumer service has been proposed

– Offers an decoupled view of integrant resources

– Enables continuous execution despite user’s mobility thanks to the Component resolution process performed by the Harmonizer layer.

– Capability selection process could be performed in limited computational devices (syntactic) and powerful ones (semantic)

Conclusions

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

• Test the proposed solution in a real environment

• Test the provision of complex services

• Reduce the requirements of semantic resolution process in order to be applied to more limited mobile devices

Future work

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

• This work has been generated from the results of the deliverables E3.5.1 and E3.6.1 of the mIO! project (http://www.cenitmio.es) supported by the CENIT Spanish National Research Program (CENIT-2008 1019).

Acknowledgements

UCAmI 2010 - Valencia, SPAIN, September 7-10, 2010 at CEDI 2010

Thank you

Unai Aguilera*, Aitor Almeida*, Pablo Orduña*, Diego López-de-Ipiña* and Rafael de las Heras+

*DeustoTech- Universidad de DeustoAvda. Universidades 24, 48007, Bilbao, Spain

+Telefónica I+DEmilio Vargas 6, 28043 Madrid, Spain

unai.aguilera, aitor.almeida, pablo.orduna, [email protected], [email protected]


Recommended