Vision of ubiquitous computing

Chair for Communication Technology (ComTec), Faculty of Electrical Engineering / Computer ScienceChair for Communication Technology (ComTec), Faculty of Electrical Engineering / Computer Science

Service CreationWhat’s the issue ??

Keynote @ WAWC’07

Dr. Olaf Drögehorn

Lappeenranta, August 16th, 2007

© © ComTec ComTec 20072007

Dr. Olaf DroegehornDr. Olaf Droegehorn22

Vision of ubiquitous computing



Technologies

Markets

Users

Market playersLicenses and regulationBusiness modelsBilling and pricingCompetitionOperator strategiesFight between standardsStandardisation bodies

NetworksTerminalsSoftware toolsContent managementSecurity

User needsService deliveryTypes of servicesCost of servicesContentEase of usePersonalisationPrivacySecurityDrivers and barriers!

Technologies, markets and users



Devices• User interface• Capabilities• Development platform• Network interface

Heterogeneousnetworks• xDSL• Mobile networks• Bluetooth• IEEE 802.x• Digital TV or radio• …

Market players• Telecom operators• Other network operators• Broadcasters• Content providers• Content aggregators• Service providers• Payment providers

ContentContentmanagementmanagement

SoftwareSoftwareAPIsAPIs

TerminalsTerminals

PaymentPayment

SecuritySecurity

Quality-Quality-of-serviceof-service

NetworksNetworks

PersonalizationPersonalization

PrivacyPrivacy

DigitalDigitalrightsrights

User needs :• To communicate• To form communities• To be informed• To be entertained• To be efficient• To feel secure• To feel capable and “in control”• To be educated

Services: Putting technology to work …• Services exist, because they fulfill a need or solve a problem for the end users• A good service must be designed for the target users and the context of use - and be user-friendly!• How can we make use of present and future networks, terminals and software to address specific user needs?• Who are the stakeholders of a service?

Content server(database)

Mobile phones PDAs PCs / Internet Digital TV

Networks

Contentprovider

Contentaggregator

Networkoperator

Serviceprovider

(Mobile) end users

Regulator

Paymentprovider

Equipmentproducer

Services and networks - the big picture



The Challenge for the Future of Communication Service (Creation)

So, what shall we do, nowthat we can do everything?

Bruce Mau,Author of “S,M,L,XL”



Outline

• The problem of service (creation)• What might people want (depends on the role)• The vision of Service Creation • The old way of service creation• A new way of service creation• Activity Theory• WWRF WhitePaper on Service Creation• An example how to do user-driven Service

Creation• The Service Creation Workbench• Findings from the example• Conclusion



What is a Service ?

• An application ?• A piece of software ?• An outcome of a process ?

=> There are many definitions (business, economics, technologies, etc.)

=> Something, that fulfills a need

(for help, for fun, for communication)

=> Is UMTS fulfilling ANY need at all ?? ;)



Things that can make a service fail

• There is no need for the service – If nobody uses the service, the whole thing is a failure

• The user interface doesn’t work– Bad navigation design, bad graphics

• The service is too slow– Content / bandwidth ratio, application doesn’t respond

• The service is unreliable– Application crashes! Blank screens, hangs, resets– Data is not up-to-date, e.g. yesterday’s weather– Transactions fail - what happened to my order?

• The service is insecure– Personal data compromised, money disappears

• The service isn’t used - boring concept



Understanding a need

• Example: Just want to get out ….– Looking for „EXIT“, or similar– Arriving here, you find:



Service Creation challengesJosef: There are no services, why ?

• Why is Service Creation so difficult ?– Maybe we are expecting THE service

(like the killer-application)

– We are NOT developing variations(like product-designers do)

– Most services are developed from scratch(Users don‘t recognize elements/widgets, therefore we try to enhance an already available service)

– We are not reusing existing codes/technologies/widgets/platforms



Service Creation, why do we need to talk about it ?

• User needs are not addressed

• Software service creation lifecycles are by far too long– Most services are developed from the scratch

• Service composition is proprietary, at best

• Ease the life of professional software developers

• Ease the life of providers/operators• Enable „non-professionals“ to create their

services

=> Each and every user should be able to create services



Why should EVERYBODY do that?

• Looking to the web:– HTML was for specialists only– Nowadays everybody has a web-page/blog

• New hype:– User generated content (for the web)– Flickr, LifeBlog, etc.

• Next trend:– User customized services– Google Mash-Ups



Why should we do that ?

• SMS was never meant to be a product/service– By using it, it formed a hype

• Because people like to separate from each other

=> The idea is to enable everybody to improve/customize and generate services



Variations are needed - IKEA (Users like to have the choice)



Outline





„I wish to concentrate on improving my services functionalities, and not

anything else...“

The service creation problemfor Service developers



„There must be some simple ways to put all the functionalities together as ready-

to-sell services ...“

The service creation problemfor Service providers



„Is it possible for me to customize service with functionalities that i wish to have?“

The service creation problemfor End-users



Outline





Service Creation Vision

A world of services that are…A world of services that are…

•Easy to create,•Easy to share,•Easy to use, … …and still user-centric!and still user-centric!



Service Creation Vision (2)

• Easy to create – Creation tools and publishing

• Service taxonomies• Reuse of existing services and components• Semantic orchestration of components and

loosely coupled approach

• Easy to share – Generalised client-server architecture

• « My server in my pocket », « My server at home»

• Service deployment in just a few clicks• Semantic based publishing

• Easy to use – Semantic Service discovery

• Fine grain semantic-based search• Interoperability, composability of services



Outline





The classical way to think about services

• Domain-Specific Software Architectures (DSSA)

• Build a specific „platform“ for a specific domain



Domain-Specific Software Architectures (DSSA)

• DSSA definition– „a context for patterns of problem elements, solution

elements, and situations that define mappings between them“ (Software Engineering Institute, 1990)

• Comprises a couple of crucial artifacts– scenarios– domain dictionary– context and entity/relationship diagrams– data flow, state transition, and object models– functional- and non functional requirements– …

Problem: DSSA is still driven by technology



Service Categorization today with regard to DSSA

Source: UMTS Forum, http://www.umts-forum.org

A typical DSSA just reflects these typical technical enablers



Domain specific platforms

• The issues are NOT new

• The whole middleware hype was targeted to this

• Build once, use everywhere

• Why not simply using THE platform ?



Middleware supports applications

Application

Middleware

Device Device

• Middleware provides homogeneous API to applications

• By providing services that bridge between homogeneous and heterogeneous API

• To shorten time-to-market for applications

• To abstract from heterogeneity and allow applications to be executed on future mobile devices



The original goals of platforms & middleware

• Masking heterogeneity – networks, end-systems, OSs, programming

languages

• Providing a useful distributed programming model– simplicity with generality

CORBA, Java RMI, etc. have been very successful in this... business applications; wrapping of legacy systems...



The concept of middleware is used more widely

• Platforms were built for many different domains, like:

• Applications– eCommerce, 7x24 back-end servers– eScience– real-time, embedded systems– mobile agent systems– peer to peer platforms– mobile computing applications– telecomms/ programmable networking

• Underlying systems– PCs/ workstations– supercomputers– wireless PDAs– embedded devices– network processors– wireless, sensor, infrared etc. networks



A victim of its own success?

• CORBA tries to cope ...– add asynch., transactions, fault-tolerance, persistence, components,

load balancing, logging, real-time/ embedded/ lightweight CORBA, ... complexity and unmanageability

• prototypes arise to fill the gaps & to have smaller solutions

– asynchronous platforms (pub-sub, eventing, message queueing) (MSMQ, JMS, JavaSpaces, ...)

– Grid middleware (Legion, Globus, OGSA, ...)– web services (SOAP, WSDL, WSFL, ...)– mobility middleware (Rover, MOST, ...)– mobile agent systems (Tacoma, Aglets, ...)– peer-to-peer (JXTA, Jtella, ...)– real-time/ multimedia platforms (ReTINA, DIMMA, ...)– etc.

• different assumptions, paradigms, models, implementation environments, ... incompatible platforms, no cooperation, no reusability!



Result: Many platforms for different disciplines



Ending up in technology silos

Source: UMTS Forum, http://www.umts-forum.org

A typical DSSA just reflects these typical technical enablers



Outline





A better way to think about services ?

• Semantic-Driven Software Architectures (SDSA)

• Design a service without technology in mind



SDSA: Understand Services beyond Technology

1. No biased interfaces_ keyboard/mouse, voice, gestures, touch

display2. No limiting form factors

_ mobile phone, notebook, desktop, PDA, smart phone

3. No usage constraints, i.e._ Unlimited power supply_ Bandwidth abundance_ Workflow convenience: no/short login, no

hardware break-down, full-fledged transparent security, ...

4. No prejudice about network connection (fixed vs. wireless)

… but describe precisely the context, services are being used



Domain-Specific vs. Semantics-Driven Software Architectures

DSSA SDSA•can be an assemblage of software components

•focuses on describing the problem domain

•wants to be unambigious •makes contradictions a valuable design principle

•usually has a bias on device form factors and interaction paradigms

•is open to device implementation and interaction design

•just refers to an unambigious terminology

•makes usage of the terminology a central feature of service specification

•attempts to generalize for the purpose of a reference design

•is specific to understand one specific problem domain



Outline





Activity Theory

Tools & artefactsTelephone

RulesMutual listeningCommon Language

RulesMutual listeningCommon Language

CommunityGroup of peers

Division of EffortSender / Receiver: Mutual delivery

Receiving messages

SubjectPartners in Dialog

ActivityObjectDialog modulation

OutcomeAgreement



Understanding a service comprises more than workflow specification

Rules

•Icons instead of text

Community

•Assembly assistants•IKEA complaints hotline

Subject OutcomeObject

Tools

Division of Effort

•Assemble•Explain, not assist

From individual activities to Activity Systems



SMS acts as a mediating artefact of an Activity System

Object

Division of Effort

Subject

Rules Community

Tools

Outcome

•Register for service•Pay per text

•Mobile providers•Possible senders/receivers

•Store and forward text•Charge for service

•Sender•Receiver

•Create & send limited text•Receive text

•Text delivered•Text received

•T9 keyboard•Display

Activity Systems as a core idea for real-world services (here SMS)



Outline





The Wireless World Research Forum

• WWRF, founded in 1998 (from WSI & EU-FP5 Project)

• Working Groups trying to draft future research issues

• Definition of a reference model of User-centered communication (I-centric)

• WhitePapers on specific topics



TerminalsDevices and Communication

End Systems

Service Platform

Generic Service Elementsfor all layers

Service Semantic

Wired or wireless Networks

IP basedCommunication

Subsystem

Bu

sin

ess

Mo

del

Networks

IP Transport Layer

Network Control & Management Layer

Service Support Layer

Service Execution Layer

Application Support Layer

Service

Bun

dling

Service

Control

Service

Discovery

Service

Creation

Environ

men

t M

onitoring

Service

Deploym

ent

Conflict

Resolution

AmbientAwareness

Personalization Adaptation

User Model & Appl. ScenariosCommunication Space

(Contexts & Objects)

Reference Model for I-Centric Communications



WhitePaper on Service Creation

• A WhitePaper to highlight open issues, existing technologies & approaches– Technology driven service design

vs. Technology agnostic approaches– Existing Software Development Environments (IDEs)– Business models for Service Creation

• Identified need for:– Harmonization of tools & semantics– Technology agnostic/independent way of serivce

design/description– Common semantics– Common understanding of technology enablers

(like OSA/Parlay, ParlayX, IMS, etc.)



Outline





Semantic Service Discovery

Technology agnostic

Everyone can define own services

„Draw a service“ -Simplified service creation process

One idea for service creation



The S4ALL approach

Rule

• „Draw a service“ - Simplified service creation process



Rule

Business Rules

Rule Evaluator

State Services Action Services



Service Building Blocks (SBB)

• State SBB: Read status to enable reacting on state changes. Also from Context Providers, which enablers to easily create context aware mobile services

• Action SBB: Trigger actions on services at mobile device, in the home environment, in the Internet

• Rules connect State SBBs and Action SBBs



Time

Afternoon

Location

LasVegas

Start Presentation

&

Icomp_2007.ppt

Business Rule Example



WI-PlatformWI-Platform

Business Rule Evaluator

MoodTime Game

TimeState ServiceBB

MoodState ServiceBB

GameAction ServiceBB

RuleEvaluator

Business Rule Example (2)



• Contains following components

RuleEvaluator

(Info.)Collector

ServiceTriggering

RulesState info.

(from service)

Output

Action Service(s)

Rule Reasoner

Rule Repository

Rule Evaluation



Selection of the Business Rules approach

• Model-Driven-Architecture (MDA) approach for service design: Create a graphical model of the service

• Business rule engine approach very common for connecting bigger building blocks. Enables straightforward data flow design.

• Make it easy for the service developers, not giving the power of a programming language

• Especially for Web service connection (state and action service building blocks provide Web service interfaces) this approach fits perfectly

• The ease and power of the approach depends on the provided service building blocks. They have to enforce the „Service-oriented architecture“ approach



Outline





Semantic Service Delivery PlatformSDFSDF

Semantic Semantic DescriptionsDescriptions

SemSDP

IDE ExtensionIDE ExtensionService Creation Service Creation WorkbenchWorkbench

deploysdeployspublishespublishes

SCESCE

Semantic Semantic DescriptionsDescriptions

SEESEE

Semantic Semantic ServiceService

DiscoveryDiscovery

Semantic Semantic ServiceService

DiscoveryDiscovery

Business Business Rules Rules

ExecutionExecution

Business Business Rules Rules

ExecutionExecution

Service Service Building Building

Block Block Execution Execution

EngineEngine

Service Service Building Building

Block Block Execution Execution

EngineEngine

TriggersTriggers

Service Delivery PlatformService Delivery Platform



Service Creation Workbench

• Scenario shown: Play video on user’s mobile device when he/she passes a certain location



Rules, Facts, and …

StateSBB

Converter

ActionSBB

Atom



The S4All Environment

Service Creation Workbench

Service Discovery Wizard Rule Editing Deployment GUISEE InterfaceRule editor GUIRepository Search Syntax/Semantic Discovery

State ServiceBuilding Blocks

Business RulesAction ServiceBuilding Blocks

State/ContextSources

Actions

Service Execution Environment

Execution Environment Deployment InterfaceSubscription ManagementUser Subscriptions Business Rule Engine CRUD Services

state request evaluation triggering

discoverdiscover

CRUD

RepositoryBuilding Blocks Rules



Outline





Evaluation (1)

• The SCW makes creation of new services very intuitive => enabling the combination of state information from user’s environment (“context”) with action triggering

• Our exemplary scenarios show that using the S4ALL tools significantly improves the process for developers to create mobile services

• Service building blocks can be reused

• Service logic is easy to grasp through its graphical representation

• Service logic can easily be updated

• Deployment requires “one-click”



Evaluation (2)

• The tools need a suitable SEE

• Rule Evaluation is a common task and is very well supported

• The approach can be used by operators as well as End-Users

• A larger test-case will be done in a European Project (IST-SPICE)

• A set buidling blocks will be provided soon, for a specific SEE (WI-P) as open source



Outline





Conclusion (1)

• Services are not really there• Service design/creation is technology driven• Many solutions don‘t serve a need

– Develop some solution and try to sell it as a service (MMS)

• A lot of people were looking for THE service• Software-Development tools are out there, but

how to build a service with them?• No harmonization in tools and semantics• No service design, but technology push



Conclusion (2)

• An easier process for rapid service creation is needed

• Easy service composition / customization is needed (to build variations)

• Tools need to be harmonized to use existing enablers (let‘s use IMS meaningfully)

• Business opportunities need to be exploited

=> Find more in the WWRF-WhitePaper

Chair for Communication Technology (ComTec), Faculty of Electrical Engineering / Computer ScienceChair for Communication Technology (ComTec), Faculty of Electrical Engineering / Computer Science

Thank you !

[email protected]

Documents

Vision of ubiquitous computing