ALIVE @IIWAS'2009

18/11/09 | 1 iiWAS, December 2009
ESAW demo November 2009

Organizing Web Services to
develop Dynamic, Flexible,
Distributed Systems
“The ALIVE project”
www.ist-alive.eu

Frank Dignum
Utrecht University

ALIVE EU FUNDED PROJECT

18/11/09 | 2 iiWAS, December 2009

Overview

• Motivation
• From Services to Services in Context
• The ALIVE approach
• Semantic web services and matchmaking
• Coordinating semantic web services
• Organizing semantic web services
• Putting it all together
• Some use cases
• Conclusions


18/11/09 | 3 iiWAS, December 2009

Conclusions (preliminary)

There is no such thing as a free
lunch

But we can help by structuring
the payment in small
installments


18/11/09 | 4 iiWAS, December 2009

Web Services

3
1 4
2

Web based application


18/11/09 | 5 iiWAS, December 2009

Example

FpML
Financial Products Markup Language
Policed by ISDA

FpML is
A set of documents that describe the structure of
how to encode financial products in XML
XMLSchema to enable validation of correct
message formats
There are a set of sequence diagrams to govern
when to send what to whom

18/11/09 | 6 iiWAS, December 2009

Example continued
Typical message:


18/11/09 | 7 iiWAS, December 2009

Example continued
Typical flow:


18/11/09 | 8 iiWAS, December 2009

The problem

How do we know what the context is for any FpML
message

Is it NovationConsentGranted?

Is it NovationConsentRefused?


18/11/09 | 9 iiWAS, December 2009

The solution

Hope and pray ….
Add meta data around the FpML package
Agree meta data with your clients

NovationConsentGranted
AllocationId 9876


18/11/09 | 10 iiWAS, December 2009

The problem was

Behavior first. Content second.

No agreement on meta data needed, because
there are no fully defined processes

What makes a NovationConsentGranted a
NovationConsentGranted is the process not
the message. The message is a
consequence.


18/11/09 | 11 iiWAS, December 2009

The problem today

Sequence diagrams are not enough


18/11/09 | 12 iiWAS, December 2009

An Example

Buyer, Seller, Credit Agency, Shipper.
Buyer barters with the Seller to get a price
Buyer accepts a price and places an order
Seller checks Buyers credit worthiness
Seller requests delivery from Shipper
Shipper sends delivery details to Seller and to Buyer

How do we write this down?


18/11/09 | 13 iiWAS, December 2009

An Example
Credit
Agency

Buyer Seller

Shipper


18/11/09 | 14 iiWAS, December 2009

An Example
• Buyer request a quote from
the seller.
• Seller responds with a quote.

• Buyer MAY accept the quote.
Buyer Seller

• Buyer MAY update quote and
request the update from the
seller.
• Seller MAY respond with the
update quote.

• Quotes may timeout.

18/11/09 | 15 iiWAS, December 2009

An Example
Credit
Agency

Buyer Seller

• If Buyer accepts the quote. Shipper
• Seller checks credit worthiness.
• If Credit worthiness is okay
• Seller requests delivery from Shipper.
• Shipper sends delivery details back to
Seller and to Buyer.

18/11/09 | 16 iiWAS, December 2009

Why Process?

All messages exist in a context.
E.g. fpml:RequestAllocationConfirmation message will not be relevant in an
Affirmation (Trade) business process

It’s not what you do but the way that you do it
Did I expect to get an fpml:AllocationConfirmed message after sending an
fpml:ConfirmAllocation?
Ordering is important because it defines how you behave. Behaviour directly
impact interoperability. Can I work with Mega Bank?

Standardising the business processes increases STP rates and enables
the market to grow.
The differentiator is the product being sold not how the back office deal with it.


18/11/09 | 17 iiWAS, December 2009

Choreographed Web Services


18/11/09 | 18 iiWAS, December 2009

Contexts?
• How to manage workflows in environments, where
not all services are owned by the same organisation?
• How to align the configurations and settings needed
by a service to operate with those of the operational
environment?
• How is service execution affected by issues of trust,
rights, obligations and prohibitions?
• What if critical applications simply cease to function if
services provisioned from third parties disappear or
malfunction?
• How to deal with knowledge representation, when
connecting or binding together two or more actual
entities or services using different ontologies?

The ALIVE approach
18/11/09 | 19 iiWAS, December 2009

role Organizational level:
- norms and regulations
WHY? - organizational structure
- communication ontology
role role
(motivations) role - evaluation indicators

Functional instantiation

actor Coordination level:
actor WHAT? - coordination patterns
Methodology
actor
Framework (possible actions, plans) - task allocation
actor - actor expectation

dynamic assignment

SD SD Service level:
SD - semantic service
SD SD SD description (SD)
- standards specification

HOW? actual deployment
(available services)
WS WS
WS
Existing platforms
Existing services
WS WS WS New services
ALIVE EU FUNDED PROJECT Service interactions

The ALIVE approach
18/11/09 | 20 iiWAS, December 2009

Organizational level role
role
Methodology
role
role role
role role
role WS

WS
Coordination level
actor
actor WS
actor
actor
actor

Methodology
actor
Framework

actor
actor MODEL-DRIVEN
ENGINEERING WS

Service level SD
SD SD
SD
SD
SD WS
SD
SD SD
SD SD SD

WS WS WS
WS

WS WS WS

18/11/09 | 21 iiWAS, December 2009

Architecture


ALIVE architecture
18/11/09 | 22 iiWAS, December 2009


18/11/09 | 23 iiWAS, December 2009

Overall Structure
Framework
(applied to application)

Metamodels

Off-line Architecture On-line Architecture

Execution,
Design Set Up Monitoring, Facilitator
Tools Tools Maintenance Components Supporting
Tools Methodology

Application Application
Model Deployment
Files

Technology specific development


18/11/09 | 24 iiWAS, December 2009

ALIVE Framework
Organizational level role Concepts:
Organisational structure,
role role role objective, role, scene,
landmark, norm

Coordination level Concepts:
actor
actor actor, agent, goal, task,
actor
state, plan
actor

Service level
SD SD Concepts:
SD
SD SD SD service, service adaptor,
service template,
service matchmaker

WS WS
WS

WS WS WS

18/11/09 | 25 iiWAS, December 2009

ALIVE Framework
Organizational level role
ALIVE Organisational
Metamodel
role role role (‘OperA’ MOF)

Coordination level ALIVE Coordination
actor
actor Metamodel
actor
actor ALIVE Event
Metamodel

Service level
SD SD
SD
SD SD SD ALIVE Service
Metamodel

WS WS
WS

WS WS WS

18/11/09 | 26 iiWAS, December 2009

Advances over State of the Art
• Mapping human organisations to service-based solutions
– models are defined at a level of abstraction that allows non-
expert end-users to support better the design and the
maintenance of the system

• Provides an organisational context (such as, for instance,
objectives, structures and regulations) that can be used to select,
compose and invoke services dynamically.

• Multi-layer approach allows for:
– Traceability (why is something done in this way on this level?)
– Adaptivity (moving up in abstraction to solve problems at a
specific level)


18/11/09 | 27 iiWAS, December 2009

Advances over State of the Art
• 3 levels of adaptation:
Service
– Changes in system functionalities
e.g., services that become unavailable or are not performing correctly
 Automatic selection/discovery of (new) services

– Changes in environmental conditions Coordination
e.g., changes (sensed symptoms) that can lead to potential failure during
the achievement of objectives
 Generation of a new plan of action for the objective

– Changes in stakeholders needs Organisation
e.g., changes in laws and norms that regiment particular organisational
protocols and responsibilities
 Selection of (new) objective(s) to achieve


18/11/09 | 28 iiWAS, December 2009

Organizational level


18/11/09 | 29 iiWAS, December 2009

Goal

Provide a stable high level description of the system
that can be used to guide adaptations in the
coordination and service levels
It provides both objectives for procedures (workflows)
as well as constraints (norms) on them
It provides objectives and capabilities for the roles that
agents should fulfill and norms on how to fulfill the
role


18/11/09 | 30 iiWAS, December 2009

Organizational Model

Normative Concrete Level Organizational Model Ontological
Concrete Level
Role Architectural Templates
Norms

Social structure Interaction structure Ontologies
Scene
Norms SCENE
Transition SCRIPT
Norms ROLE
norms objectives
scene SCENE
transition SCRIPT
role results
Role relation Communication
norms constraints
Rules languages
landmarks
ROLE
Scene Transition player
Rules Rules


18/11/09 | 31 iiWAS, December 2009

Social Structure
Role dependencies
Conference
Society

conference_organized paper_submitted

Organizer Author
program-organized local-organized

PC-chair Local-chair

paper_reviewed session_organized

PC-member Session-Chair

paper_presented

Presenter

18/11/09 | 32 iiWAS, December 2009

Role example

Role: PC Member
Objectives paper_reviewed(P, Rep)
Sub-objectives { read(P), report_written(P, Rep), review_received(Org, P, Rep) }
Rights access-confman-program(me)
Norms OBLIGED understand(English)
IF DONE assigned (P, me, Deadline)
THEN OBLIGED paper_reviewed(P, Rep) BEFORE Deadline
IF DONE paper_assigned(P,me, _) AND direct_colleague(author(P))
THEN OBLIGED review_refused(P) BEFORE TOMORROW
Type external


18/11/09 | 33 iiWAS, December 2009

The Organizational Model

Normative Concrete Level Organizational Model Ontological
Concrete Level
Role Architectural Templates
Norms

Social structure Interaction structure Ontologies
Scene
Norms SCENE
Transition SCRIPT
Norms ROLE
norms objectives
scene SCENE
transition SCRIPT
role results
Role relation Communication
norms constraints
Rules languages
landmarks
ROLE
Scene Transition player
Rules Rules


18/11/09 | 34 iiWAS, December 2009

Interaction structure

M
Send Call for Registration Conference
Participation Sessions

Conference
Form PC Review Paper
start on-site end
Process Acceptance
registration
N
Send Workshops
Paper
Call for
Submission
Papers


18/11/09 | 35 iiWAS, December 2009

Scene example

Interaction Scene: Review Process
Roles PC-Chair (1), PC-member (2..Max)
Results r1 = ∀ P ∈Papers, reviews_done(P, review1, review2)
r2 = ∀ p ∈Papers, decision_on_paper(paper, decision, review1, review2)
assign receive
Interaction PATTERN(r1) = paper review
PC1 PC1
Patterns { DONE(O, paper_assigned(P,PC1,DeadlineR) BEFORE DeadlineA),
DONE(O, paper_assigned(P,PC2,DeadlineR), BEFORE DeadlineA),
Assign Review
start end
DeadlineA BEFORE DeadlineR,
deadline deadline
DONE(PC1, paper_reviewed(P, Rev1) BEFORE DeadlineR),
DONE(PC2, assign receive
paper_reviewed(P, Rev2) BEFORE DeadlineR) }
paper review
Norms PERMITTED(O, PC2
paper_assigned(P, PC, DeadlineA) )
PC2
OBLIGED(PC, paper_reviewed(P, Rev) BEFORE DeadlineR)
OBLIGED (O, decision_on_paper(P, D, Rev1, Rev2) BEFORE DeadlineD)

landmarks

18/11/09 | 36 iiWAS, December 2009
ESAW Review February 2009
demo November

OperettA Eclipse


18/11/09 | 37 iiWAS, December 2009
ESAW Review February 2009
demo November

OperettA Eclipse


18/11/09 | 38 iiWAS, December 2009

Coordination level


18/11/09 | 39 iiWAS, December 2009

Objectives
• Operational model for coordination of dynamic workflow
services
• Mechanisms for analysis of properties in model
• Mechanisms for synthesis of components
• Goal
– Bridge organisational and service levels


18/11/09 | 40 iiWAS, December 2009

Coordination level: the big picture


18/11/09 | 41 iiWAS, December 2009

Action Editor
• Actions
– Special domain knowledge
– Complement/depend on organisation spec.
• Represented in semantically rich format (OWL-S)
– Pre- and post-conditions
– Atomic and composite (with control constructs)
• Functionalities:
– Create/edit actions
– Visualise actions


18/11/09 | 42 iiWAS, December 2009

Action Editor (Cont’d)
Action meta-model


18/11/09 | 43 iiWAS, December 2009



18/11/09 | 44 iiWAS, December 2009

Advancement of state-of-the-art:
• OWL-S used for general agent action description (not
Web services)
• Extend OWL-S to represent adding/removing effects in
post-conditions
• Development of OWL-S meta-model
• Meta-modelling facilitated development (including
changes)


18/11/09 | 45 iiWAS, December 2009

Task Editor
• Task
– Problem description (incl. world state and objective)
– Input to plan/workflow synthesis
• Functionalities
– Visualise, create and edit tasks


18/11/09 | 46 iiWAS, December 2009

Task Editor (Cont’d)
Task meta-model


18/11/09 | 47 iiWAS, December 2009

Task Editor (Cont’d)


18/11/09 | 48 iiWAS, December 2009

Plan/Workflow Tool
• Functionalities:
– Synthesis of workflows/plans
– Visualise workflows
– Manually create workflows and edit existing ones
• Eclipse plug-in
• Invokes plan synthesis (web-) service
– Currently based on JSHOP2
– Inputs: actions and a planning problem (task)
– Generates (series of) workflow(s)


18/11/09 | 49 iiWAS, December 2009

Plan/Workflow Tool (Cont’d)
Workflow meta-model


18/11/09 | 50 iiWAS, December 2009



18/11/09 | 51 iiWAS, December 2009

Planning process

Com pound
Atom ic Action
Action


18/11/09 | 52 iiWAS, December 2009



18/11/09 | 53 iiWAS, December 2009

• Use extended OWL-S for general planning
• Organisation-oriented planning
• Modular architecture allows for different planners to be
used
• Meta-modelling provided modularity to architecture


18/11/09 | 54 iiWAS, December 2009

Agent Tool
Functionalities
– Visualise, create and edit agent specifications
– Generation of agents, based on organisation
– Allocation of actions to agents
– Synthesis and injection of agents into platform (namely,
AgentScape)


18/11/09 | 55 iiWAS, December 2009

Agent Tool (Cont’d)
Agent meta-model


18/11/09 | 56 iiWAS, December 2009

Agent editor architecture


18/11/09 | 57 iiWAS, December 2009



18/11/09 | 58 iiWAS, December 2009

– Organisation-oriented synthesis of software agents
– Organisation-aware software agents dealing with
exceptions
– Agent-based plan/workflow enactment (with re-planning)
– Technologies: AgentScape, TAEMS


18/11/09 | 59 iiWAS, December 2009

Event Analysis Tool
• Workflows enactments provide event logs
– Log file: who performed what and when
– Event meta-model with associated ontology
– Events should be analysed w.r.t. workflow
• Functionalities
– Throughput Time
– Violated Norms
– Social Network Analysis
– Task Matrix
– Quality of Service


18/11/09 | 60 iiWAS, December 2009

Event Analysis Tool (Cont’d)
Event meta-model


18/11/09 | 61 iiWAS, December 2009

Model-driven workflow design & verification


18/11/09 | 62 iiWAS, December 2009

Eclipse plug-in

1. Choose “analysis” option
2. Choose “enactment” of workflows
3. Choose period of log


18/11/09 | 63 iiWAS, December 2009

Task Matrix

Violated Norms


18/11/09 | 64 iiWAS, December 2009

Throughput Time

Social Network Analysis

Quality of Service


18/11/09 | 65 iiWAS, December 2009

Service level


18/11/09 | 66 iiWAS, December 2009

From coordination to services

Coordination Level

Service Workflow
Selection Enactment
Deploy
Required
Services
search/query services Return results Feed back
performance &
Invoke task
Service metrics
Task Query
Handle
Service Level

Disovery/Matchmaking Service Execution


18/11/09 | 67 iiWAS, December 2009

Services Layer Architecture


18/11/09 | 68 iiWAS, December 2009

Matchmaking architecture


18/11/09 | 69 iiWAS, December 2009

Matchmaker Demo


18/11/09 | 70 iiWAS, December 2009

OWLSBuilder


18/11/09 | 71 iiWAS, December 2009

Model Driven Approach


18/11/09 | 72 12/11/2009 | 72 iiWAS, December 2009
Review

Methodology :: State of the Art

Core Characteristics

1. Level of Abstraction
2. Automation
3. Model based (Graphical)
4. Tool Supported
5. Adaptation
– Design-Time
– Run-Time
6. Multi Layers
– Holistic approach
– Integrated
7. Monitoring
8. Formalised

ALIVE EU FUNDED PROJECT ALIVE EU FUNDED PROJECT

18/11/09 | 73 12/11/2009 | 73 iiWAS, December 2009
Review

Methodology :: Model Driven

• Raise level of Abstraction
• Code Automation
• Creation of Tools (Editors)
• Consistency
• (validate rules)
• Layer Integration


18/11/09 | 74 12/11/2009 | 74 iiWAS, December 2009
Review

Methodology :: Multi Layers Integration

• Based on 3 Integrated Conceptual Layers

Task Service

Pre/Post
Actor Relations condition

Role Norm


18/11/09 | 75 12/11/2009 | 75 iiWAS, December 2009
Review

Methodology :: Development Process

Development Life Cycle for an ALIVE application

• Design Time Design
( Modelling)
– Modelling/Metamodelling

n
– Model Integration/Consistency

io

Auto tion
ptat

Crea
• Tools/Automations

mate
A da
• Run Time Development

d
Process
– Execution and Monitoring
• Semantic Analysis and Selection
n

Se n a
io
• Adaptation u t ri n g

m ly s
A
e c i to

a n is
Ex o n

t ic
M
&


18/11/09 | 76 12/11/2009 | 76 iiWAS, December 2009
Review

Methodology :: Design Time


18/11/09 | 77 12/11/2009 | 77 iiWAS, December 2009
Review

Methodology :: Run Time


18/11/09 | 78 iiWAS, December 2009

Use cases

• Thales:
– Focus on integration between Organization and
Coordination levels
• Calico Jack:
– Focus on integration between Coordination and
Service levels
• TMT:
– Demonstrates integration of all three levels


18/11/09 | 79 13/11/2009 | 79 iiWAS, December 2009

Thales Use Case Motivation

Simulations of crises expensive and time consuming
Distributed / Automated simulations seems to provide an
ideal solution
Challenges:
How to make the simulations realistic?
What to simulate?
How to feed results back into process?

Crisis Management Scenarios have organisation, co-
ordination and services that can be independently
assessed and modelled.


18/11/09 | 80 13/11/2009 | 80 iiWAS, December 2009
ESAW demo Review Meeting
Alive Project November 2009

Outline of Use Case

Simulation Toolkit:
Allow different scenarios to be rapidly modelled and
the results displayed for ease of evaluation
Services represent the actions that are performed
by crisis management personnel
Coordination between these tasks result in
changes to the enactment of the entire scenario.
Organisational constraints determine the
coordination that can take place.


18/11/09 | 81 13/11/2009 | 81 iiWAS, December 2009

Scenario

Flooding of two
adjacent regions
Evacuation of these
regions required
This entails evacuation
of Nietzelfredzamen
Hospitals
Elderly
Prisoners


18/11/09 | 82 13/11/2009 | 82 iiWAS, December 2009

Demo


18/11/09 | 83 13/11/2009 | 83 iiWAS, December 2009

Organisation Modeling

• Organisations are modelled using the OperettA tool
• Social Structures define the roles and their
relationships
• Interaction Structures model the landmarks and the
required steps to reach these landmarks
• Norms are defined as both the social norms and
institutional norms.
• Social Norm: Women & Children first
• Institutional Norm: Buildings should not be re-
entered; Evacuation time <= 300 minutes


18/11/09 | 84 13/11/2009 | 84 iiWAS, December 2009

OperettA

Specifies the organisational context of the domain
Interaction Structure specifies the desired/required
interactions within the organisation
Social Structure specifies the important parties that
play a part in the organisation
(Basic) Ontology support
Creating roles/objectives/etc. adds their name as
concept to a generated ontology
Roles/objectives/… can be named by selecting a
concept from an existing ontology


18/11/09 | 85 13/11/2009 | 85 iiWAS, December 2009

Organisational Model Validation

OperettA.check adds model validation to the
organisational model editor
Validates organisational model based on defined
constraints to ensure model correctness
Checks vary from checking whether all roles have a
name…
To checking whether landmark patterns are
connected and acyclic


18/11/09 | 86 13/11/2009 | 86 iiWAS, December 2009

Organisation Modeling in OperettA

Social Structure (Roles)


18/11/09 | 87 13/11/2009 | 87 iiWAS, December 2009

Interaction Structures…

Basic Interactions:


18/11/09 | 88 13/11/2009 | 88 iiWAS, December 2009

…Leads to Action Plans

Evacuation of a Hospital requires planning for both
Critical and non-critical patients.
Help must be sought if Norms (e.g. time required to
evacuated greater than a limit) will be violated.
Organisational Structure guides how resources are
used to fulfil action plans


18/11/09 | 89 13/11/2009 | 89 iiWAS, December 2009

Action Modeling

Initial Link to Services
Help define the workflow to allow landmarks to be
reached.


18/11/09 | 90 13/11/2009 | 90 iiWAS, December 2009

Organisation Level – Coordination Level Model
Transformation
Organisation Level Coordination Level
OL::Scene CL::CompositeAction
OL::LandmarkPattern CL::CompositeAction
OL::Landmark CL::CompositeAction
OL::Objective (with CL::CompositeAction
subObjectives) CL::AtomicAction
OL::Objective
OL::PartialStateDescription CL::AtomicActionResult
OL::Player CL::Participant
OL:: ... CL:: ...
• Transformation Definition
• Model2Model (QVTO)

ALIVE EU FUNDED PROJECT • result:: actions model

18/11/09 | 91 13/11/2009 | 91 iiWAS, December 2009

Actions


18/11/09 | 92 13/11/2009 | 92 iiWAS, December 2009

Actions (Evacuate Hospital Scene)


18/11/09 | 93 13/11/2009 | 93 iiWAS, December 2009

Conclusions

Modeling based approach brings particular advantages
to the Crisis Management Simulations:
Rapid development of new scenarios;
Re-planning based on failures at run time.
Visual Development of new Scenarios


18/11/09 | 9494
15/12/2009 | iiWAS, December 2009
2nd Review

Calico Jack

• Communication in leisure domains
Need to bridge different media: instant message, e-mail,
voice call, video, SMS
Manage changing roles and identities of users
Couple with online social networking resources
• Goal: Dynamic reconfiguration of communication
pathways based on
Availability of services
Availability of user (what is appropriate when)
• Exploit existing social structures
Relationships on social network sites indicate appropriate
channels


18/11/09 | 9595
15/12/2009 | iiWAS, December 2009
2nd Review

Calico Jack – Organisational Model


18/11/09 | 9696
15/12/2009 | iiWAS, December 2009
2nd Review

Calico Jack – Interaction Structure


18/11/09 | 9797
15/12/2009 | iiWAS, December 2009
2nd Review

Calico Jack – Actions to handle message


18/11/09 | 9898
15/12/2009 | iiWAS, December 2009
2nd Review

Calico Jack – Example Scene Plan


18/11/09 | 9999
15/12/2009 | iiWAS, December 2009
2nd Review

Calico Jack

• Innovative aspects of solution developed
Designing for robustness
Abstract away from detailed engineering
Solutions that are more robust and more reliable
• Previously:
pipeline of services
single points of (potential) failure chained
together
• With ALIVE:
Dynamic substitution in the face of failure


15/12/2009 | 100
18/11/09 | 100 iiWAS, December 2009
2nd Review

TMT

Need to upgrade urban information services

For people living in or visiting a city

Ubiquitous access

Context-awareness

Personalised interaction and content

Multimedia


15/12/2009 | 101
18/11/09 | 101 iiWAS, December 2009
2nd Review

TMT

• Specific requirements

Dynamically compose high value services

Content providers

React and adapt to dynamic environments:
coordination tasks to support services that come and
go;
organisational norms to support dynamic selection of
coordination plans.
Filter to match user

15/12/2009 | 102
18/11/09 | 102 iiWAS, December 2009
2nd Review

TMT – Knowledge representation


15/12/2009 | 103
18/11/09 | 103 iiWAS, December 2009
2nd Review

TMT – Interaction Structure


15/12/2009 | 104
18/11/09 | 104 iiWAS, December 2009
2nd Review

TMT – Organisational Model


15/12/2009 | 105
18/11/09 | 105 iiWAS, December 2009
2nd Review

TMT – Content adaption workflow


15/12/2009 | 106
18/11/09 | 106 iiWAS, December 2009
2nd Review

TMT – Tasks to gather user preferences


15/12/2009 | 107
18/11/09 | 107 iiWAS, December 2009
2nd Review

TMT – Actions to adapt content


15/12/2009 | 108
18/11/09 | 108 iiWAS, December 2009
2nd Review

TMT – Agent screen shot


15/12/2009 | 109
18/11/09 | 109 iiWAS, December 2009
2nd Review

TMT – Context Web Service

Obtaining
local time

Obtaining
user’s
location

Obtaining
weather
forecast


15/12/2009 | 110
18/11/09 | 110 iiWAS, December 2009
2nd Review

TMT – Legal broker Web Service

Obtain age to
be considered
legally an adult
for a specific
location.


15/12/2009 | 111
18/11/09 | 111 iiWAS, December 2009
2nd Review

TMT – User Modeller Web Service

Obtaining user’s
cinema
preferences

Obtaining user’s
restaurant
preferences

Obtaining user’s
requirements


15/12/2009 | 112
18/11/09 | 112 iiWAS, December 2009
2nd Review

TMT – Movie cinema suggestion Web Service

Obtain a movie
and cinema
suggestion


15/12/2009 | 113
18/11/09 | 113 iiWAS, December 2009
2nd Review

TMT – Restaurant suggestion Web Service

Obtain a
restaurant
suggestion


15/12/2009 | 114
18/11/09 | 114 iiWAS, December 2009
2nd Review

TMT

• Innovative aspects of solution developed
Solutions that are more robust and reliable
Multiple levels  gives robustness
Previously:
Single points of (potential) failure chained together
Lack of dynamic consideration of all relevant factors
With ALIVE:
Dynamic substitution in the face of failure
Consideration of all factors:
Accessibility: people with functional diversity
Context-awareness
Personalised interaction and content


18/11/09 | 115 iiWAS, December 2009

Conclusions


18/11/09 | 116 iiWAS, December 2009

Conclusions

• ALIVE provides a high level context for web services
• This provides stability and robustness
• The coordination level provides flexibility
• The semantic web service level provides dynamic
matchmaking based on semantic and syntactic
features
• Use cases indicate usefulness of the approach
• For more info on ALIVE see: www.ist-alive.eu


18/11/09 | 117 iiWAS, December 2009

Thanks to:

Javier Vázquez-Salceda Luigi Ceccaroni
Virginia Dignum Manel Palau Roig
Julian Padget Thomas Quillinan
Huib Aldewereld Kees Nieuwenhuis
Owen Cliffe Athanasios Staikopoulos
Dalia Khader Razvan Popescu
Juan Carlos Nieves Siobhan Clarke
Sergio Alvarez Napagao Chris Reed
Sofia Panagiotidi Paul Sergeant
David Corsar
Alison Chorley
Wamberto Vasconcelos


18/11/09 | 118 iiWAS, December 2009

END


ALIVE @IIWAS'2009

Recommended

Recommended

More Related Content

Similar to ALIVE @IIWAS'2009

Similar to ALIVE @IIWAS'2009 (20)

More from Knowledge Engineering and Machine Learning Group

More from Knowledge Engineering and Machine Learning Group (10)

Recently uploaded

Recently uploaded (20)

ALIVE @IIWAS'2009