Ubicomp Secretary : A Web Service based Ubiquitous Computing Application

1. Ubicomp Secretary : A Web Service based Ubiquitous Computing Application • Salmin Sultana Member, Research & Development Commlink Info Tech. Ltd. Dhaka, Bangladesh salmin01010@yahoo.com • Md. Mostofa Akbar Assistant Professor, CSE, BUET Dhaka, Bangladesh mostofa@cse.buet.ac.bd • Rezwana Karim Lecturer, CSE BRAC University Dhaka, Bangladesh rezwana.karimnawrin@gmail.com • Sheikh I. Ahamed Assistant Professor Marquette University Milwaukee, WI, USA iq@mscs.mu.edu

2. 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

3. 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.

4. 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.

5. 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.

6. 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.

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

8. Scenario 1 • 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.

9. US helps her to • Browse the list of famous places of Shanghai • Get necessary information about them.

10. Scenario 2 • 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.

11. Scenario 3 • 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.

12. Characteristics Of UbiComp Secretary (US) To fulfill all the major requirements of a specific user, US must encompass the following prime 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.

13. 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.

14. 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.

15. 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.

16. 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.

17. Implementation of UbiComp Secretary (US)

18. 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

19. 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.

20. 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.

21. General Approach of Implementation • Algorithm For A Service Provider • Start the Web Server. • Deploy the Service in to the web server. • Publish the WSDL in a UDDI Registry Server. • Accept user request for a service with WSDL URL. • If the WSDL URL exists reply with the desired WSDL file. • Take proper inputs from the user. • Provide the service i.e. - Generates output - Sends back the results to service requestor in vector form

22. General Approach of Implementation (Contd.) • Algorithm For User (Client Module) • Takes user’s current location information from GPS. • Finds out the corresponding Country Code. • The software connects to the Universal Registry Server for the first time to get the Registry URL of the current location. • Henceforth, Client communicates to this Local inquiry URL to list all the Services Available. • Issue request to get a Service. • Connects to the associated WSDL URL to get the WSDL file. • Parse this WSDL file to retrieve necessary information’s about the Service. • Generate an Input window dynamically & give desired inputs to access the Service. • If validated by the Server, get the service & shows the result in an output window. Otherwise receive proper error message & Go to step 3. • Go to step 4 until user exits the application.

23. 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).

24. 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.

25. Evaluation Wecan evaluate US in the following ways • Implement a prototype • Cognitive walkthrough strategy • Performance measurement

26. 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.

27. Screenshots

28. Screenshots

29. 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 2Figure show the user’s satisfaction rating and application developer’s satisfaction rating.

30. Evaluation (Cont’d) Rating by developers Rating by users

31. 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 Evaluation (Cont’d)

32. 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.

33. 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.

34. Questions • Please email to • iq@mscs.mu.edu