Ubicomp Secretary : A Web Service based Ubiquitous Computing Application

Salmin SultanaMember, Research &

DevelopmentCommlink Info Tech. Ltd.Dhaka, Bangladeshsalmin01010@yahoo.com

Md. Mostofa AkbarAssistant Professor, CSE, BUETDhaka, Bangladeshmostofa@cse.buet.ac.bd

Rezwana KarimLecturer, CSEBRAC UniversityDhaka, Bangladeshrezwana.karimnawrin@gmail.com

Sheikh I. AhamedAssistant ProfessorMarquette UniversityMilwaukee, WI, USAiq@mscs.mu.edu

Outline

Abstract Key Terms Related Works Motivation Characteristics of UbiComp Secretary (US) Underlying Architecture of US General Approach of Implementation How US Adheres the Characteristics Evaluation Conclusion Future Works

Statement of the problem

an omnipresent customizable service because of extensive availability of wireless internet connectivity and low cost light weight mobile devices

it can be used by different types of users indifferent fields such as education, tourism, shopping or business, at any time and at any place.

In this paper, we present the details of Ubicomp Secretary (US), which is designed and developed to accomplish the above objectives.

Key Terms Ubiquitous Computing A post-desktop model of human-computer interaction in which information processing

has been thoroughly integrated into everyday objects and activities.

Goal: To enhance computer use by making many computers available throughout the physical environment, but making them invisible to user.

Web Services• Self-describing and Modular business applications that - Expose the business logic as services over the Internet - Provide ways to find,subscribe, and invoke those services.• Based on the concept of service-oriented architecture (SOA)• Describes a standardized way of integrating Web-based applications using - XML - SOAP - WSDL - UDDI

open standards over an Internet protocol backbone.

Key Terms XML (Extensible Markup Language)• A language , recommended by W3C, for - creating common information formats - sharing the format and content of data over the Internet and elsewhere.• In Web Services, XML is used to Tag Data.

SOAP• An XML-based, extensible Message Envelope Format. • Possesses "bindings" to underlying protocols.• Used to transfer the data in Web Services.

UDDI (Universal Description Discovery & Integration)• A protocol for - publishing - discovering metadata about Web services i.e. their capabilities, location, requirements etc. in a universally recognized format.

Key Terms

WSDL ( Web Services Description Language )

• An XML-based language used to

- describe the services as business offers by publishing them to a UDDI directory

- provide a way to access those services electronically.

• Describes

- service interfaces

- details of their bindings to specific protocols , data types, location etc.

• Typically used

- to generate server and client code

- for configuration.

Motivation

To better understand the need of US, it is helpful to describe some scenarios using available devices and services.

Viona flies from Indonesia to Shanghai Arives at Pudong International airport

The US in Viona’s PDA gives Her Present location Location & Route to the 3 star hotel Jian Tiang

In the hotel lobby, US automatically Joins the Hotel Reception network Verifies Viona’s identification from her PDA.

Viona chooses a suitable room The Reception Service of US - Authorizes the PDA. - Opens the door lock - Controls devices in the room When Viona is nearing her room, PDA joins the room network.

Scenario 1

US helps her to

Browse the list of famous places of Shanghai

Get necessary information about them.

Professor Hopkins will give a talk on Ubiquitous Computing. His US

- Joins the class room network - Uploads the Lecture slides - Discovers and Connects to the A/V devices During the talk, the audio and video feeds from the room are captured, saved and available for later use.

Scenario 2

Fred is at home working on the organization of a conference. Fred leaves home and heads to his office.

When he enters the office, his US

Sets up the incomplete task using the applications of AURA.

Scenario 3

Characteristics Of UbiComp Secretary (US)

To fulfill all the major requirements of a specific user, US must encompass the followingprime criteria

C1) Interoperability Invoke applications provided by other existing ubicomp architecture.

C2) Simplicity Provide a simple mechanism for accessing services from anywhere and any device.

C3) Dynamic Discovery Dynamic exploration and invocation of services depending on user’s current context.

C4) Tiny memory footprint For usage mainly in tiny devices having - limited memory space - a small footprint.

C5) Heterogeneous platform Executable in devices like PCs, laptops, PDAs, smart phones.

Characteristics Of US (cont’d)

C6) Security Ensure - secure environment for online processes - privacy protection for users across multiple domains and services.

C7) Scalability, Flexibility and Extensibility - Extensible to allow future evolution of technology and new UbiComp architectures. - Flexibility in application to application communication over the Internet.

C8) Time efficiency User can perform the desired job as early as possible.

C9) Context sensitivity Context sensitive and aware of user preferences.

C10) Reliability All the services discovered and information fetched by US should be relevant and correct.

Related Works

OXYGEN – The Ubicomp Project from MIT

Oxygen project introduces - ‘Intelligent Space’ occupied by cameras, microphones, displays, sound output systems, radar systems, wireless networks - Controls for physical entities. People can interact by using speech, hand gestures, drawing, and body movement .

GAIA – The Ubicomp Project from UIUC

Gaia provides support for mobile user-centric Active Space applications.

Applications developed upon this architecture uses CORBA.

Related Works AURA – The Ubicomp Project from CMU

Aura is an architectural framework for user mobility in ubiquitous computing environments.

Applications developed upon it requires a task manager, built on top of existing middleware such as RPC or CORBA.

Ubicomp Assistant – Project from Marquette University

Ubicomp Assistant (UA) - developed upon MARKS middleware, is a service which can be used by various users in different situations.

It uses MARKS (Middleware Adaptability for Resource Discovery, Knowledge Usability and Self-healing) as an underlying core service provider.

Conference Assistant

A prototype for assisting conference attendees in choosing presentations to attend, taking notes, and retrieving those notes.

Related Works (cont’d) Both of the Oxygen and Gaia uses active space.

- In US, the user - may be present anywhere - get services at any time.

Gaia based applications and UA lacks sound interoperability as their underlying architecture is relatively closed.

- US developed upon Web service based architecture solves this problem.

Applications developed on Aura and Gaia are too heavy for resource constrained devices.

- US is distributed. - Light, as only the Client module executes in the user device.

Conference Assistant is entirely conference-oriented application.

- US can be extended to provide any service in different contexts. - Thus Conference Assistant may be a part of US.

Implementation of

UbiComp Secretary (US)

Underlying Architecture

US is developed on the Web Service based architecture.

The main components of this architecture are

1. Service Provider 2. Service Broker

3. Service Requestor or User

Web Service based Architecture

Underlying Architecture (Contd.)

Service May be an Application built on - Web Services based architecture - Any other UbiComp architecture.

Individual services or applications are hidden behind service abstractions.

Middleware Services or Applications are combined into higher order applications using underlying

middleware. Middleware makes all the components in a given level interact with each other to form Services.

Service Provider

Create Web services Deploy them in a Service Container or using SOAP runtime environment Define Interface for invoking them. Describe the services as WSDL-based service description Publish them in a service broker i.e. UDDI registry server.

Underlying Architecture (Contd.)Service Registry The UDDI registry stores - Service Description as binding templates - URL to WSDL files

Returns these details to the Service Requestor upon request.Service Requestor Depends on 2 components - Context Service : Receives user context information from GPS & other sensors - User Profile Management : Maintains user profile containing user information, preferences, task schedule etc. Retrieves details of required services querying Service Registry Creates a client proxy application Establishes communication with the service provider using SOAP Invoke services providing user context and profile information.

General Approach of Implementation

Algorithm For A Service Provider

I. Start the Web Server.

II. Deploy the Service in to the web server.

III. Publish the WSDL in a UDDI Registry Server.

IV. Accept user request for a service with WSDL URL.

V. If the WSDL URL exists reply with the desired WSDL file.

VI. Take proper inputs from the user.

VII. Provide the service i.e.

- Generates output

- Sends back the results to service requestor in vector form

General Approach of Implementation (Contd.) Algorithm For User (Client Module)

I. Takes user’s current location information from GPS.

II. Finds out the corresponding Country Code.

III. The software connects to the Universal Registry Server for the first time to get the Registry URL of the current location.

IV. Henceforth, Client communicates to this Local inquiry URL to list all the Services Available.

V. Issue request to get a Service.

VI. Connects to the associated WSDL URL to get the WSDL file.

VII. Parse this WSDL file to retrieve necessary information’s about the Service.

VIII. Generate an Input window dynamically & give desired inputs to access the Service.

IX. If validated by the Server, get the service & shows the result in an output window.

Otherwise receive proper error message & Go to step 3.

IV. Go to step 4 until user exits the application.

How US Adheres All the Characteristics Web Services itself supports Interoperability (C1). Developers’ point of view As US is implemented based on web services, a Service can be developed in any

platform and any language. Databases needed for different service are decoupled . Database servers can also be different. Services can be developed by different developers but can be integrated in the same registry server

To develop a service, the developer should just - deploy the service in a server - generate the WSDL file - publish the service in registry server User’s point of view A service can explored and invoked from anywhere & any device

Thus US ensures Simplicity (C2), Scalability, Flexibility and Extensibility (C7).

How US Adheres All the Characteristics (cont’d)

Only the Client module resides and executes in user device. This module has tiny memory footprint (C4).

Table 1. Miniature footprint of US

The services an user can invoke are dependent on his current context. Thus US owns Context Sensitivity (C9).

Service list is updated dynamically from place to place without user intervention. It’s Dynamic Discovery of Services (C3).

Result of a service invocation is available to the user within few seconds thus ensuring Time Efficiency (C8).

Each service has to be published in the registry server, where the authority validates and authenticates the service provider. So, US ensures Reliability (C10) providing secure & valid information.

Lines of code Executable file size (KB)

Client module

2745 73

Evaluation

We can evaluate US in the following ways Implement a prototype Cognitive walkthrough strategy Performance measurement

Evaluation (Cont’d) Prototype Implementation Platform - Windows XP Implementation language - JAVA Web Container - Apache Tomcat Platform for creating and deploying web services applications - Apache Axis Database Server - MySQL Compiling and Building Tool - ANT UDDI Registry Server - jUDDI UDDI Client - JAVA API named UDDI4J.

The core services provided by our US are: LocationService : Informs the user of his/her current location. NeighborService : Provides the list of nearby facilities such as restaurants, museums, parks, markets etc. MapPointService : Gives the route to the destination from the current location. HotelReceptionService : Provides the available room list of the hotel with their facilities. HotelRoomService : Provides a user with the details of her room.

Screenshots

a. Available Service List b. Location Service Output

c. Input for MapPoint Service d. Result of MapPoint Service

Screenshots

e. Neighbor Service Output

f. Information of a Hotel

6(g) Details of a Hotel Room h. Booking a Room

Evaluation (Cont’d) Cognitive Walkthrough Strategy To evaluate our US, we followed this strategy.

Who will be the users of the system?

- 2 Ph.D. students ( Computer Science and Eng.) - 1 Professor - 2 Graduate students (Computer Science and Eng.) - 1 Lecturer - 1 Undergrad student (Chemical Eng.) - 1 Researcher - 2 from General mass

What tasks will be analyzed? - Services provided by US.

What is the correct action sequence for each task?

- First, we briefly explained the

- Task sequences

- Process to get result.

- A questionnaire was given to the users.

- The next 2 Figure show the user’s satisfaction rating and application developer’s satisfaction rating.

Evaluation (Cont’d)

00.5

11.5

22.5

33.5

44.5

5

Overall Usefulness Easy to use Easy to deploy

Ratin

g (h

ighe

st=5)

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

Rating by usersRating by developers

Evaluation (Cont’d)

Performance Measurement The average time needed to

Discover Services - 1.44 s Invoke Location Service - 0.45 s Appear input form for Mappoint Service - 0.35 s Invoke Neighbor Service – same as Location Service Invocation Invoke Mappoint Service & HotelRoom Service provided input – same as Location Service.

Thus, US needs reasonable time to provide output of a service which ensures its acceptability as well as user satisfaction.

Timing measurement of US for different Service Discovery and Invocation

Time Measurement

0

200

400

600

800

1000

1200

1400

1600

1800

0 5 10 15Test No

Tim

ing

in m

illi

sec

ond

(ms)

Load Service ListLocation ServiceMappoint Service Input

Conclusion

In this paper, We have shown that

Ubicomp Secretary – a ubiquitous paradigm based on Web service based

architecture

- can be developed successfully.

- can ensure almost all the features demanded by the proposer of the architecture.

- owns all the characteristics as required in different fields.

Future Works

We have not introduced the concept of XML Encryption XML Signatures SAML

in our implementation.

In the future we will incorporate User authentication by using signature or fingerprint. Semantic Web Services to discover suitable services intelligently.

Questions

Please email to iq@mscs.mu.edu