Introduction: Objective of our project to design a ...



The Buddies

CS551 – Design Document

Project Group

Sushil Puradkar

Uday Joshi

Swapnil Deshmukh

Preeti Naik

Madhura Maideo

Neeta Prasad

Saurabh Pathak

Date of Submission: October 22, 2003

TABLE OF CONTENT

Introduction 3

Dictionary 3

Requirement specification 4

Stakeholders 4

Functional/Business requirements: 4

Nonfunctional requirements: 6

Technical requirements 6

Framework Specifications. 7

Algorithm 7

Data Structures 8

Design Pattern 8

System Specification 9

Use Case Diagrams. 9

Sequence Diagram. 14

Operation Specification: 18

System User Interface 20

System Architecture 21

Component Diagram. 21

Package Diagram 23

Protocol Design Diagram 24

Utility Components 24

Class Diagram 25

Class Interface Description 26

Appendix 29

Algorithms. 29

Database Design 33

Service Script 34

Introduction

Objective of our project is to design a framework to execute device workflow. The information about the workflow can be given as a script. This is our design document where we try to explore requirements for this framework and then try to come up with our design for this framework. In this document we first list the functional and non-functional requirements from this framework and then used use case diagram to understand these requirements. Then we try to identify different components required to develop this framework and then we focused on classes and database design that will be required for this framework.

Dictionary

This is list of some of the terms that you will come across in this design document.

Intelligent environment: Our basic goal is to develop intelligent environment which can understand and communicated with the devices available in the environment, which offer services to user by execute device workflow.

Device Workflow: Device can be connected to execute certain task. Output of one task executed by a device can be given as input to other task which can be executed by another device.

This way we form a workflow of devices. Like we can scan read user file from hard disk and then print it. So this workflow has two tasks, reading hard disk and printing on a printer.

Device: This can be any device that can be found in intelligent environment, like printer, camera, PDA, scanner etc.

Device URI: It a URI assigned to device to identify it universally.

Client Machine: This is external machine where device is attached. If device is not intelligent that is it can’t register on itself then client machine sends request to register device.

User: User is anyone who is in the intelligent environment. The environment provides service to the user.

User URI: This is a URI assigned to a person to identify him universally.

User Device: These are devices that can be used to communicate with users and which belong to user, like PDA, laptop, mobile phone etc. System uses these devices to communicate with the user.

Administrator: Administrator is a person who manages the framework. He installs services and does the maintenance work.

Service: This is similar to device workflow. It is collection of task that needs to be performed to provide particular service to user.

Script: This framework reads service description from a script. This script is in XML format. Sample script can be found in the appendix.

Script reader/parser: This is one component of our framework which reads this script and interprets it. It prepares the device workflow to execute.

Event: Event is external event that triggers framework to execute different task given in different services. An example of event is - person walks into environment.

Event Handler: This unit of the framework captures external event and search of task which can be executed on that event. It also executes those tasks.

Device Handler: This component is responsible to select particular device to execute certain task. Like if several printers are available then this event will decide on which printer it should print.

Function Set: This is collection of atomic functions that is used by Event Handler to execute a service.

Buddy System: This is a test service that we want to implement on our framework. Buddy service is a service which will notify user if any user friend is present in the environment.

Device Table: This is a table maintained in database to store information about different devices.

Service Table: This is a table maintained in database to store information about different services.

Now we focus on requirement specification for this framework.

Requirement specification

Stakeholders:

Developers

• The Buddies group who are developing this Buddy system are potential stake holders as we are the ones who studied the current market and identified that market would welcome such a system. However, the real challenge lies in sustainability. If our system fails to gain popularity and some other competitor traps more clients then we will lose efforts, time and money. This is a big risk on our part.

Middlemen or Assemblers

• There would be some organizations or people who will like to buy our system and combine it with some more components to build an entirely new system. Thus, our ‘Buddies System’ will act as a component.

• Such middlemen may face the challenge of integrating our system with other components. Thus, they are also potential stakeholders.

Users

• Suppose an organization requires a group of people to interact with another set of people who are geographically apart. They cannot communicate through a common tool like video conferencing because they could be using different devices like PDA, cell-phone etc. It is now necessary to intimate a person about the other person’s presence for communication to take place. The Buddy system will notify a person about all his buddies who will be online as soon as he enters the system.

• Thus, the users are the biggest stakeholders.

Functional/Business requirements:

We are developing a generic framework, which will work with any kind of scripts. The organizations just need to build the function – specific script and they can plug that in into our framework and start using it. Thus, here we will split function / business requirements into two categories. We will first describe those requirements, which are generic to our framework and then we will go ahead and explain requirements particular to our Buddy System

General framework related requirement:

• Area of Concentration

o The organization or office or small shopping complex as well as individual users are thought of as potential clients/users who would deploy such system.

o They all essentially need to develop a script and make it talk to our framework. Our framework will provide all the needed interfaces to all other devices thus providing a layer of transparency.

• Registration of users

o A unique login password will allow users to register with the system.

o The framework should be able to provide all necessary authentication methods like encryption of password etc to ensure secure entry into the system.

o System will also implement mechanisms to stop unauthorized users from hacking important information and entering the system.

o Multiple users can register with the system concurrently. Thus, the system will support multiple simultaneous instances of registrations.

• Basic functions

o System should be able to allow user to enter as well as exit the system gracefully.

o After user exits, system should update his/her status accordingly on global level.

o When user downloads the specific script, that script should be locally saved on his server.

o Thus, there should be a local instance of script, which will reduce query and parsing time and increase speed of processing.

o Also, we can go one step ahead and propose that the system should be able to keep a backup script available stored in the database. This will help if you accidentally lose or modify the existing script.

o Use of state: The system should be able to keep the ‘state’ information of users as well as devices. This information will be updated periodically and will be stored in the form of ontologies. The ontology will be created for both users and devices. Thus, every time user logs off, his status will be updated. Similarly if a device is currently offline, its status will be marked as ‘offline’ and updated from time to time.

o All this information will be cached and thus the querying time will reduce for all subsequent queries to the framework and ontologies and database.

o Seamless integration with the existing system: Any new application should seamlessly integrate with the existing project framework. You should be able to write new script for your application, plug it in, update the data in the databases and use the newly developed application effectively, with minimal changes in other components of framework.

• Transparency functions

o Scalability and performance factor: The system should be scalable, ie support large number of users. Also, the performance should not be affected due to such large number of users. Similarly, since the scripts will be loaded locally along with a backup script, even if the script from the web is not available, the system should continue to perform normally. Also, the newer versions of the scripts should be backward compatible. (Although this entirely depends on the people who develop the script)

o Location and access factor: The users should be able to login to the system from any location and they should be able to gain access to the system. Remote or local logins should be treated with same priority or preferences.

Buddy – System specific functional requirements:

• The user should be able to log in and out of buddy system. Thus, users should be able to start and shut down the system.

• Any new user should be able to subscribe and unsubscribe to the buddy system from any location ie locally or remotely.

• Once the user logs in, his buddy list should be loaded locally. Any subsequent entry or exit of his buddies from the system should be notified to the user on the device that he is currently logged on from. This notification will include sending text messages to his cell phone, PDA, email etc. If system fails to determine the device on which he is logged in, then a default device or preferred device (As specified in the user specification) will be detected and a message will be sent there.

• The buddy system should be scalable, ie large number of users should be able to register and use the system efficiently and at the same time. Thus, multiple instances of this buddy system will be deployed and accessed simultaneously.

• The buddy system will keep track of the user’s state (online, offline, busy etc) and also, it will maintain a status list of all the devices in his vicinity.

• Reliability and security It should allow for a sufficient degree of reliability and security during online notifications, providing a mechanism to ensure secure, one-time delivery of the data over the network. There might be some users who do not want their presence to be notified to their buddies during a particular time of day.

Nonfunctional requirements:

• Attractive and user friendly GUI:

o A main GUI will be provided for the new user while subscribing to the system.

o User should be able to enter a lot of personal information and device preferences.

o The choices should be easy and language of questions should be simple and easy to understand.

o User friendly buttons like ‘OK’, ‘YES’, ‘NO’ etc should be provided.

o The GUI should not take long time to load.

• Configurable options:

o Some of the options should be easily configurable by the user. (preferred device on which user wants to receive a message/notification, his name, phone number, email address etc)

o Some extra personal information which will allow the system to understand user better.

o Thus, users can subscribe to some newsletter, weekly updates etc from other vendors.

o Some fancy options like symbols, emoticons etc should also be configurable.

Technical requirements

• Script (Xml or similar parsing enabled scripting language)

o This will be a generic parsable document (mostly written in built–in parser enabled language like xml), which will have all the commands like ‘read’, ‘write’, ‘print’ etc.

o The user who writes this script is assumed to have a minimum knowledge of all such terms which reflect

o This script will provide all the possible atomic functions with respect to Buddy system.

o This script will vary from system to system. Thus, anyone can write a new script for his/her particular job and post it to the website.

• Framework (Java interfaces)

o This will be intelligent interface, which will translate the words from the script into actual machine recognizable words and commands with help of various functions and classes.

o This will have interface with web services, which in turn will have links to already defined ontologies

o The decision will be taken by looking at all the device specification from ontologies.

• Ontology (Jena ontologies and RDF querying language interface)

o This can be said to be the collection of all the concepts along with the specifications.

o Jena is very powerful tool

o The ontology will contain information about all possible devices, which are indexed on their URI.

o The system will make a query to the Device ontology to see if the desired operation is possible with the given device. If yes then it will go ahead and call the corresponding web service and perform the actual operation.

o The Ontology will always be updated with all the new devices, which register themselves with the system. Thus, here device ontology will act like a information envelop which will match device with its operation and its parameters and its abilities.

• Database Management: (MS Access)

o We are using the MS Access database to create tables that keep device, user and other information for the buddy system.

o We will also use the SQL query within MS Access to get some data from the tables on demand.

o The application will keep a record of the user information, like address, age group, general interests, and so on. There will be a separate agent to add, delete, and modify user information

o It must keep a record of all available devices and their availability, along with their up-to-date shipping prices. The availability information should help to predict the shipping time and alert the agent about new products.

• Web services (standard web services as dll or exes)

o This will act as wrapper, which will envelope entire framework.

o Web services will manage various event handlers. The even handlers will always run in the background on the user system.

o When ever a buddy enters the system, when a new user registers, these event handlers will be triggered. The trigger will in turn call one more routines, which will perform the desired operations.

• Unique Resource Identification for all entities:

o To access the application, every user must be issued a user ID (URI), which will serve as an identification key to the system.

o Also, every device (PDA, computer, cell phone etc) will have URI. This URI can be looked up for its specification through the web services and ontologies.

Framework Specifications.

Algorithm

Following are very algorithm which gives very high level logic of different components of the framework. Details algorithms can be found in Appendix.

Device Management.

If new device installed in the environment

Get device-details, like device identity, device specifications etc.

Store this information in database

If some device service is requested then

Get the location where user is present.

Get the user preferences

Select device from available devices depending on requirement of task and user preference

If such device found then

Ask device to executed given task.

Else return an error message.

After specific interval.

Get the list of devices available in the environment.

Communicate with devices to know their status.

If device respond with its status then

Update status of device in database

Else

Update status of device to inactive.

If device is removed then

Remove its entry from database.

Installing services.

Get the service description.

Find out required resources to execute this service

Check whether service can be implemented using available resources.

If not the return error message.

Check whether workflow can be created from the service description

If not then return error

Do the required changes in database to install service.

Return success.

Event Handler.

Capture event.

Go to database and find out which services can be implemented on the occurrence of this event.

Get the details of the service

Execute services in threads.

Execute service.

Read service description

Find out devices required to execute task given in service description.

Call device handler to execute this task.

Data Structures

Service List: This data structure stores all the services that are installed in the system. The initial parse script and if the script is proper then it will install this service. It will create and object from this script and will store in service list. When particular event occurs, the event handler will get details about services which depend on this event and then will get the script of those services from the service list.

Design Pattern

Observer: In observer design pattern multiple objects wait for some object or event. It is many to one relationship. In our framework there could be multiple services that wait for particular event to occur. On the occurrence of that event all services will be executed. So we can use observer design pattern in this case.

The class diagram for observer would be

[pic]

Singleton: This pattern makes sure that only one object is created of a class. In our framework we are maintaining collection of services which are installed. Different thread running to execute services should user same collection of services. So here we can use singleton design pattern.

Class diagram for singleton

[pic]

Composite: Composite design pattern is used when very complex object is to be formed by composing small similar object. We can use this design pattern to create object of function set. Since there are many functions in function set it would be difficult if one class is written to manage function set. Instead of this we create small classes which implements small functionalities and then compose them to give bigger complex function set object.

Class diagram for composite design pattern

[pic]

System Specification

Use Case Diagrams.

To draw use case diagram we first try to define our problem.

Problem Description: Design a framework for intelligent environment which can do following task.

Different devices can perform different task, like printer can print, fax machine can print as well as fax a document and camera can capture images. A service is a process which is composed of such tasks. Like a service could be capture image and then print it. Framework should able to take information about such service as input and executed sub tasks of that service using available devices.

It should able to manage information about devices. This involves maintaining information of functionalities provided by devices, specifications of devices, their location and their status.

Location of devices can be changed. New devices can be added. Framework should change its records accordingly.

Framework should keep track of users coming in the environment and leaving the environment. Framework should able to provide service to these users using the devices available with the user.

Selecting a device for a particular task will depend of context. Context can be defined as the location of user and location of device, specific requirements of jobs etc. Like if something is to be printed then the device which is close to the user should print.

[pic]

Use Case Specification

Use Case Name: High level use case diagram of framework

Actors: Administrator, User, Device

Pre-Condition: Framework should be installed. Device and users should have some identification so that framework can recognize them. Administrator should provide service description. To execute service devices must be installed.

Post-Condition: Framework will store the details provided by device. It will store details provided by the user. It will execute service, which is provided by the administrator.

Basic Flow: Device details will be provided by device. These details will be used by the framework to select particular device to execute certain task mention in service description, which is provided by the administrator. User can provide its information and information about the devices he is using. These devices will also be part of the system so can participate in executing the task mention in service description.

[pic]

Use Case Name: Expanding Read and Executing Service use case.

Actors: Administrator

Pre-Condition: A service should be well defined, recognizable and available by the As for execution.

Post-Condition: As will perform operations like validating and executing a particular service. It will store the service as the final step for future use.

Basic Flow: A well known service or requested service will first be validated and then executed. As a result it will be stored in the database for future reference. The process of validating a service requires few more validations on the resources etc which is done simultaneously.

[pic]

.

Use Case Name: Expanding Validate use case.

Actors: -

Pre-Condition: A service should be well defined. The names and URIs of the resources should be available.

Post-Condition: The resources will be checked for correctness and compatibility. This will ensure that desired operations can be performed properly on the resources.

Basic Flow: It will check the resource status and whether resource can perform the operations or not. It will tell AS in turn whether validation was successful and if the given resource is ready for the operation.

[pic]

Use Case Name: Expanding Execute use case

Actors: -

Pre-Condition: A service should be well defined. The names and URIs of the resources should be available.

Post-Condition: The service will be actually executed. The given task will be performed. The status of the successful / unsuccessful operation will be reported back to AS

Basic Flow: This will select the service required and then actually perform the task.

[pic]

Use Case Name: Expand Manage Device use case.

Actors: -

Pre-Condition: A device should be well defined. The names and URIs of the devices to be managed should be available.

Post-Condition: The particular device information is updated to the system. Device status and location are updated.

Basic Flow: This will select the device required and try to find out its current state (online/ offline), location, and any other device specific information and send it to AS. AS keeps such latest information in order to immediately process the user request

[pic]

Use Case Name: Expanding Managing User Information use case.

Actors: -

Pre-Condition: A user should be well defined. The URIs of the users to be managed should be available.

Post-Condition: The particular user information along with his/her device information is updated to the system. User status and location are updated. Also, information about user’s devices and their status etc is also updated.

Basic Flow: This will manage both users and user’s preferred devices. All possible information like location, URI, status will be refreshed and updated to the AS

[pic]

Complete use case diagram.

Sequence Diagram.

1. Device Registration

[pic]

Collaboration diagram.

[pic]

Device Deregistration

[pic]

Collaboration Diagram.

[pic]

Service Installation.

[pic]

Collaboration Diagram

[pic]

4. Service Execution.

[pic]

Collaboration Diagram

[pic]

Operation Specification:

Action: Regiser Device(device URI, device location, device specification, device service description)

Pre-Condition: Device should have uri, device should have file having device specifications and information about services that can be executed by the device.

Post-Condition: Device will be recognized by the system. Details about this devices will be stored in the database.

Action: Deregiser Device(device URI)

Pre-Condition: If request is from client machine then device must have been disconnected from client machine or device is willing to leave environment.

Post-Condition: Device details will be deleted from the system. System will not recognize this device.

Action: Update Status (device URI, device location)

Pre-Condition: On status check time out. System know the device URI and location of device whose status is to be checked.

Post-Condition: Device will return its status. If system doesn’t get response then device can be considered as inactive.

Action: Install Service (service script)

Pre-Condition: Service description is available as script in predefined format.

Post-Condition: If script is proper and service is not already install in system then service will be installed in the system. Database will be modified to store service information.

Action: Event Handler(event uri, device uri, device location, user uri)

Pre-Condition: Particular event has occurred.

Post-Condition: Service which depends on this event will be executed. Some task to other devices will be assigned.

Action: Register device (event uri, device uri, device location, user uri)

Pre-Condition: Particular event has occurred.

Post-Condition: Service which depends on this event will be executed. Some task to other devices will be assigned.

Action: Notify Action (device uri, service name, service parameters)

Pre-Condition: Some service is to be provided to the user. Device has been identified to execute this task.

Post-Condition: Device will be informed about this task.

Database Operations:

Functions related to users

Action: Get User login (user uri)

Pre-Condition: User has entered in the environment and has device which can give his identity.

Post-Condition: This function will return the userlogin corresponding to the userid provided. Return userlogin on success and null on failure.

Action: Get User Password(user uri)

Pre-Condition: User has entered in the environment and has device which can give his identity.

Post-Condition: This function will return the password corresponding to the userid provided. Return password on success and null on failure.

Action: Put User Info (user uri, user location, user device list)

Pre-Condition: User has been authenticated

Post-Condition: This function will insert the user information provided in user table. Return zero on success and –1 on failure.

Action: Get Function Name (event uri)

Pre-Condition: An event has occurred.

Post-Condition: This information returns about services which depends on given event.

Functions related to Devices

Action: Device Register (device uri, user uri, device location, device specification)

Pre-Condition: Device has been added to system.

Post-Condition: Device details will be stored in the device table.

Action: Device Deregister (device uri)

Pre-Condition: Device has been removed from system

Post-Condition: Details of device will be removed from the database.

Action: Device Get Status(String deviceid)

Pre-Condition: System needs to user particular device and wants to know devices status.

Post-Condition: This function will get the status of the device. Return zero on success and –1 on failure.

Action: Device Update Status(device uri, device status)

Pre-Condition: System has done periodic check of device status and wants to update device status in database

Post-Condition: Device status will get updated.

Action: Get User Device (user uri, device type)

Pre-Condition: Some service is to be provided to user, user is known and device required for the service is known.

Post-Condition: This function will return the URI of user's device, if it is available, given a user URI and device type.

Action: Get User Location( user uri)

Pre-Condition: Some service is to be provided to user and user location is required.

Post-Condition: User location will be retrieved from system.

Scenario using operations

Here we try to describe a scenario using operation described above. We consider that we have already installed a service to greet user when he walks into environment. Lets say that user has a mobile phone with him. Now when user walks in following things will happen.

1. Client machine will communicated with mobile phone and know that this is new device in the environment.

2. It calls register device function to register this device with system. It provides device uri, user uri, its location and information about device i.e. mobile phone that it got from the users mobile phone.

3. The register device service will in turn call database’s register device service to register this mobile phone. It will also call put user info function to store information about the user.

4. The client machine recognizes that this is – user check-in event and it inform system about this event by calling event handler function of the system.

5. The event handler system uses get function name service of database handler to retrieve information about the services which depends on this event.

6. It will get details about greeting service. It will search the script for greeting service and will try to execute it.

7. The service says that a message should be sent to user. So system try to find out which devices are available to send message. It searches the devices available with the user using function get user device. It calls get device status to know the status of the device and if the device is available then sends message to that device using notify action method.

8. User gets message on his mobile phone.

System User Interface

Since there is very less input from the user, this system has less user interfaces. We are providing two interfaces in this document.

i) Screen to install a script from the desired location.

This screen provides the user with an interface to install the script of the desired r service on to the system framework.

Browses button-to browse for the address of the script either on the local machine or on the web

Install button- to install the script on the system

Cancel button- to terminate the installation process if required

ii) Screen to provide the user with the services of the buddy system.

This Screen shows the list of buddies of a particular user

Add button- to add new buddies into the user’s buddy list

Delete Button- to delete buddies form the user’s buddy list

Display- to display the names and the ids of all the members of the buddy system

Sign Out- to sign out the user from the buddy system

System Architecture

Component Diagram.

Following are the component in this system.

[pic]

The Service Handler is responsible for installing service and executing service on the occurrence of particular event.

Function set is collection of atomic function that will be used by service handler to executed service.

Device component is a component which takes care of all devices related activities, like searching a device, selecting appropriate device to execute certain task etc.

Database component takes care of database related activities. It maintains system table and service tables.

Web service interface component provides external interface to system.

Internals of each component (Type diagram)

Service Handler

This component has classes required to parse script before installing it. It also has class to handle event. It has class called resource handler which provides interface between external entity and resource component to mange devices. It has class service list which has variables that are used by initial parser and event handler both.

2. Device Handler Component

Device handler has four different classes. Device service handler class takes care of searching services provided by any device. Device match handlers try to find out device to meet service requirement. The Device database Interface communicates with database to get details about devices from database.

Database Handler Component

Database handler component takes care of all the database related activities. It has only one class which implements all the methods required for database activities.

Web Services Component

The web service component provide interface for the system to the external environment.

The Function set component has collection of classes which provides atomic functions which are required by the system to execute any task.

Package Diagram

[pic]

Package diagram could be given as above. Database activities are provided in database package. Web services are provided thru web service interface package. Function set is a package which has collection of atomic function. The script parsing and event handling classes can be given ins core service package.

Protocol Design Diagram

[pic]

The above diagram gives details about how different component communicates with each other. Service handler is a core component which installs and executes services. It creates objects of function set and device handlers and call functions in these components by normal procedure calls. The database component has be kept separately so make system more modular and to test how different modules can be inserted into this framework if the modules are available as web service. So the service handler, function set and resource handler all communicates with database component using web services (SOAP/XML) protocol. The web service interface can be integrated with the system using normal procedure calls but it will communicate with external entities using web services i.e. SOAP/XML protocol.

Utility Components

We are planning to user ontologies to store device specification and device service descriptions. We will be using Java’s Jena API to work with these ontologies. The script will be return in XML so we will also use Java’s packages related to XML parsing. We need Java’s packages for web services. We might use web service to authenticate user. So we need external web service like .Net passport that can be used for user authentication. The database will be maintained in MS Access so we need package providing java to database connectivity.

Class Diagram

Following is detailed class diagram of our system.

[pic]

Class Interface Description

Class DeviceOntoHandler : CallDeviceOntoHandler (String[] parsed_script, String Action_to_do, String[] Specifications, String DeviceURI, String UserURI)

It will store these keywords in the local variables. It will pass the Device or User URI to other functions to perform the specified action.

However, if Device URI is not specified, then it will resolve the User URI, by passing it to another function called QueryDatabase().

Class DeviceOntoHandler: QueryDeviceOnt (String[] specifications, String Action_to_do, String DeviceURI)

The function will make sure that the required device can perform the operation according to the specifications. It will return success or failure depending onwhether it could complete the operation or not.

Class DeviceOntoHandler : QueryDatabase (String UserURI)

The function will query the buddy – system database and get user location. Then it will again send query and get all device URIs which have same location as the user. It will them try to find the preferred device specified by the user in his preferences and then it will store this Device URI locally and send it to function QueryDeviceOnt() for further processing.

It will return success or failure depending onwhether it could complete the operation or not.

Class DeviceOntoHandler : QueryWebService (String specifications[], String Device URI)

It will check if that web service is available for particular operation and then perform the required action. It will return success or failure depending onwhether it could complete the operation or not.

Class DatabaseHandler: public string GetUserlogin(string userrui )

This function will return the userlogin corresponding to the userid provided. Return userlogin on success and null on failure.

Class DatabaseHandler: public string GetUserPassword(string useruri)

This function will return the password corresponding to the userid provided. Return password on success and null on failure.

Class DatabaseHandler: public string GetUserlogin&Passwd(string useruri)

This function will return the userlogin and password corresponding to the userid provided. Return user login and password on success and null on failure.

Class DatabaseHandler: public int PutUserInfo(string userrui,string login,string password)

This function will insert the user information provided in user table. Return zero on success and

–1 on failure.

Class DatabaseHandler: public String []GetFunctionName(string eventuri)

Returns name of service which depends on given event

Class DatabaseHandler: public int DeviceRegister(String deviceid, String Status,String type,String DeviceURI, String Location, Time LastAccessTimestamp)

This function will basically register a device into the system. The corresponding row will be inserted into the Device table. Return zero on success and –1 on failure.

Class DatabaseHandler: public int DeviceDeRegister(String deviceid)

This function will deregister a device from the system, say when it status becomes down. The corresponding row will be deleted from database. Return zero on success and –1 on failure.

Class DatabaseHandler: public int DeviceGetStatus(String deviceid)

This function will get the status of the device. Return zero on success and –1 on failure.

Class DatabaseHandler: public int DeviceUpdateStatus(String deviceid, String status)

This function will update the status of the device into the system. Return zero on success and –1 on failure.

Class DatabaseHandler: public String GetUserDeviceURI(String useruri, string devicetype)

This function will return the URI of user's device, if it is available, given a user URI and device type.

Class DatabaseHandler: public String GetUserLocation(String useruri)

This function will return the location of a user device, given a user URI.

Class DatabaseHandler: DropTable(String Tablename)

To delete a table when no longer required by a service.

Class DatabaseHandler: CreateTable(String Tablename, string columnname, string column types, string colvalue,……)

To create a new table required by some service.

List of function in function set

Math Functions:

int add (int, int)

float add (float, float)

int subtract (int, int)

float subtract (float, float)

int multiply (int, int)

float multiply (float, float)

void increment (int, int)

void increment (int, float)

void increment (float, int)

void increment (float, float)

void decrement (int, int)

void decrement(int, float)

void decrement(float, int)

void decrement(float, float)

int power(int, int)

float power(float, int)

String Functions:

string concatenate (string, string)

void copystring (string, string)

int stringlength (string)

int stringcompare (string, string)

Array Functions:

void sort (int array[])

void sort (float array[])

int search (int array[])

int search (float array[])

int search (string array[])

int maxvalue (int array[])

float maxvalue (float array[])

int minvalue (int array[])

float minvalue (float array[])

int add (int array[])

float add(float array[])

void arrayinsert (int array[])

void arrayinsert (float array[])

void arrayinsert (string array[])

int arraydelete (int array[])

float arraydelete (float array[])

string arraydelete (string array[])

int arraycount (int array[])

int arraycount (float array[])

int arraycount (string array[])

General Functions:

void filecopy (string, string)

void readfile (string)

void deletefile (string)

void printfile (

void movefile (string)

Buddy Service Functions:

1.int authenticate (string, string)

2.int contactuser (string)

3.int checkpresence (string)

The above functions have been listed as a part of the initial design, new functions might be added or existing functions might be modified or deleted as per the arising needs. New functions which are service specific can also be added to the system, to cater to the requirements of a particular service.

Most of the above-mentioned functions are overloaded and as an alternative to this approach the concept of templates or the concept of sending objects as parameters might be used.

Appendix

Algorithms.

Class EventHandler

{

int handleEvent(string eventuri, string userrui)

{

Call DatabaseHandler’s function to get the list of service functions which can be invoke on this event.

For each service function

{

Get script object from global hash table of scripts

Call processService( script, functionname) in thread

}

If no error then return 1

Else return 0

}

void processService(xmlobject script, string functionname)

{

Read the initialization part of the script and execute that

Jump to script function which is to be executed

For each statement in function block

If it is a command then call corresponding function from function set.

If it is a control structure then prepare follow the control structure for execution of following statement until control structure is finished.

If a database activity then call DatabaseHandler’s functions to execute query.

}

}

Class InitialParser

{

xmlobject script

InitalParser(xmlobject script)

{

this.script = script;

}

int validate()

{

Load script into Dom parser.

Get resource details and call DeviceOnto Handler to check whether required resources are available.

If error then return error code implying required devices not available.

Get database description and call DatabaseHander functions to check whether database can be implemented

If error then return error code implying database cannot be implemented.

Check whether firs time run block can be executed.

Check whether initialization block can be executed.

Read each event based procedure block.

Check whether event can be recognized.

Read each statement of the procedure.

If it is command then check whether required function from function set can be called.

If it is a control structure then check whether control structure can be implemented.

If it is database activity then check whether DatabaseHandler functions can be called to execute the database activity.

If failure in any case then return error code implying that script cannot be executed.

If no error till now then

Create service tables.

Store the script into global hash table of scripts.

Execute first run block of the script.

}

}

Class UserinfoHandler

{

string getUserLocation(string useruri)

{

Call DatabaseHandler function to get user’s location

If error then return Null else return user location

}

object array getInfoFromWeb(string useruri, string parameter)

{

Get the web service which retrieves information from user profile.

Pass user uri and parameter(what information needed, tagname) to this service and get user information in object array.

If error then return null else return object array.

}

int sendMessage(string useruri, object message)

{

Object array devicelist = getInfoFromWeb(useruri, ”UserMessagingDevicePreferences”);

For each device entry in devicelist

Call DatabaseHandler functions to check whether that userdevice is available.

If available then output message on that device using deviceOnto Handler function, return 1 and break.

Return 0 indicating failure.

}

void waitForUser(string useruri)

{

while (true)

{

call DatabaseHandler’s function to check whether user is available. if user available then break;

}

}

}

Class ResourceInfoHandler

{

int period

ResourceInfoHandler()

{}

ResourceInfoHandler(int period)

{

this.period = period;

this.periodic();

}

int registerDevice(string location, string deviceuri, resource devicespecification, resource deviceservicedescription)

{

Check whether device description is present in local file

If not present then

Store the device specification into the file containing device specifications.

Store the device service description into fie containing device service specifications.

Call DatabaseHandler function to register device.

If no error then return 1 else return 0

}

int deRegisterDevice(string dviceuri)

{

Call DatabaseHandler functions to deregister this device.

If no error then return 1 else return 0

}

void periodic();

{

While (true)

{

Wait for period ‘period’

Get list of all device uris

For each device uri

Call function of DeviceOntoHandler to check the status of the device.

Update last access timestamp if both, previous and new device status is not inactive.

Update status of the device in database.

If device is inactive and difference between last access timestamp and current time is greater than predefined time then device could be consider as disconnected so remove its entry from database and from device specification and device service specification files.

}

}

}

Class DatabaseHandler

{

GetUserlogin(userid)

{

check whether user is present

return login corresponding to input userid.

}

GetUserPassword(userid)

{

check whether user is present

return Password corresponding to input userid.

}

DeviceRegister(String deviceid, String Status,String type,String DeviceURI, String Location, time LastAccessTimestamp)

{

check if all parameters consistent to what is required

insert the row in the Device Table

return zero on success and –1 on error

}

DeviceDeRegister(String deviceid)

{

check if device exists

if yes delete the row or else return error

}

DeviceGetStatus(String deviceid)

{

check if device exists

if yes return the status else return error

}

DeviceUpdateStatus(String deviceid, String status)

{

update the device id with status

return zero on success and –1 on error

}

GetUserDeviceURI(String useruri, string devicetype)

{

   check whether user is present

   if present then check whether any device of 'devicetype' is associated with user.

   if yes then return deviceuri

   else return Null

}

}

Database Design

Design of Tables: (with sample data values)

Generic to any service, System tables

User Table:

|ID |URI |Auth_method |

|1 |…. |M1 |

|2 | |M2 |

This table will be prepopulated with userids, their URIs and the authentication method. If a new user comes in he will be assigned a new userid ,an URI and the default value for authentication method, if not provided will be M2 say local password authentication scheme.

Table for M1 can be generated on the fly depending on parameters required for that authentication method. Say if M1 is biometric authentication the parameters would contain the fingerprint image filename and other necessary terms.

If M2 is local password authentication scheme, table could be

|ID |Login |Password |

|2 |pottert |ting |

Services table

|Servicename |Status |Script_used(ID) |Filename |

|Buddy |up |S1 |C:\551\project\buddy_script |

|Billing |down |S2 | |

|PIE |installed | | |

This table keeps a list of the services which could be provided. This table will be prepopulated The status field will indicate if the service is up and running. This field can be updated by any module when it realizes that some event has taken place due to which the service can no longer be provided.

TablesByServices (Tables used by services)

|Servicename |Tables_used |Mapped_table |

|Buddy |T1 |T1 |

|Buddy |T2 |T2 |

|PIE |T1 |T5 |

Sometimes 2 or more services might request for same table name to be created. This table will internally keep a mapping, say table T1 of service PIE is basically table T5.

Script table

|Script_ID |function |event |

|S1 |F1 |E1 |

|S1 |F2 |E2 |

This table will keep track of the functions to be executed in a script when an event is triggered. Say when event E1 is triggered, the function to be executed for script S1 would be F1.

Resource(Device) table

|DeviceID |Status |type |DeviceURI |Location |LastAccessTimestam|

| | | | | |p |

|D1 |up |PDA | |R360 | |

|D2 |up |printer | | | |

This table would keep track of all the resources in the system. They would mostly be devices with a URI and location assigned to them. The last access timestamp will be used to update status of the device. Say if the device has not been up for a long period of time it can be considered as out of the system.

Global Variable Table

|Var_name |Servicename |type |value |

|MAX_COUNT |Buddy |int |300 |

This table will keep track of global variables, their type and their value for all services.

Function Table:

|Functioname |ID |Script |

|Add |F1 |S1 |

|Div |F2 |S2 |

|Mul |F3 |S1 |

System tables specific to a particular service, say ‘Buddy System’ in our case

BuddyUsers Table:

|ID |URI |Onlinethrudevice(Name/ID) |

|U1 | |D1 |

Service Script

-

  BuddySerivice

-

-

-

-

  Printer

  PrinterColorType

  Color

 

 

-

  Detector

 

 

 

-

-

  PDA

 

-

  MobilePhone

 

-

  URISupplier

 

 

 

-

-

-

  UserTable

  UserURI

  UserStatus

 

 

-

-

 

  EmployeeTable

 

  EmployeeURI

 

  EmployeePosition

 

 

-

-

-

  EmployeeTable

  EmployeeURI

-

  EmployeePosition

-

 

 

 

 

 

-

  UserTable

  UserURI

 

-

  UserTable

  UserStatus

 

 

 

 

 

-

-

 

  usruri

 

 

-

-

-

 

 

 

-

-

 

  usruri

  userbuddylist

 

-

  userbuddylist

  BuddyURI

-

-

  UserStatus

  userstatus

 

-

-

  userstaus

 

  In

 

-

-

  BuddyURI

-

  Your Friend

  useruri

  Is Here

 

 

-

  useruri

-

  Your Friend

  BuddyURI

  Is Here

 

 

 

 

 

 

 

 

 

 

 

 

-----------------------

Install

Address

Buddy System

Enter the address of the script to be installed.

Browse

Cancel

Buddy System

Buddies for – Sam

• Joe

• Nancy

• Pinky

• Tom

• Bob

Sign out

Display

Delete

Add

ServiceList

registerDevice

deregisterDevice

periodicTask

ResourceHandler

handleEvent

processService

EventHandler

Service Handler Component

Validate

validateResouce

validateDatabase,

installService

Initial Parser

Validate, handleEvent, registerDevice, deregisterDevice

[pic]

Database Component

getUserLogin getUserPassword getUserLoginandPassword putUserInfo

getFunctionName registerDevice deregisterDevice getDeviceStatus

…

DatabaseHandler

getUserLogin, getUserPassword, getUserLoginandPassword, putUserInfo, getFunctionName, registerDevice, deregisterDevice, getDeviceStatus, getUserDevice, getUserLocation, getDeviceLocation, getDeviceLocation, ListofDeviceinLocation, getDeviceatLocation, createTable, validateTableCreation

ASWebServiceInterface

registerDevice

deregisterDevice

actionNotifyer

eventNotifyer

ASWebServices

registerDevice, deregisterDevice, actionNotifyer, eventNotifyer

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download