Nivel de satisfacción personal
4.3. Análisis y discusión de resultados
The application has been implemented as a Java EE Web application developed and tested on an Apache Tomcat 6.0 container. MySQL 5 has been used as the underlying database and the Axis Web service framework1, has been used for accessing the mobile Web services. All development has been conducted using the Eclipse IDE.
The user interface is based on JSP/JSTL pages generating the XHTML code and JavaScript code. Servlets are used to implement the controllers and drive the main logic of the application. Information about the logged in user is stored in
auserDataclass and made available to the JSP pages and Servlets as a session
bean. Database Connection Pool (DBCP) is used to set up, maintain and make connections to the underlying database available. A DatabaseHelper class is used to implement common needed database functionality such as getting a database object from the pool.
The interesting part of the implementation is in a packet namedcalendar, which wraps all functionality used to manage the calendar information. There are three sources of calendar entries in the system, the mobile device, the Google calendar and the systems own database. The calendar packet defines classes implementing management of all the the sources and a main class implement- ing a unified interface to all the sources. Its classes are:
• Commons.java: Implements routines needed by the other classes within the packet
• DatabaseCalendarManager.java: Implements management of the calen- dar entries stored in the database
• GoogleCalendarManager.java: Implements management of entries stored in the Google calendar
• MobileDeviceCalendarManager.java: Implements management of entries stored on the mobile device
• GeneralCalendarEntryType.java: An object to contain calendar entries • CalendarManager.java: Provides a unified implementation to the other
classes easily usable by the controllers to provide the desired functional- ity. It provides methods such asaddEntry,deleteEntry,fetchDay,getCalen-
darEntriesandsynchronizeMonth.
8.5 Future directions 93
Apache Axis 1.4 is used to request the mobile hosted Web services through pre generated stubs from the WSDL interface. For communication with the Google Calendar, the Java client library of Google Data APIs Client Libraries2is used.
8.5
Future directions
Obviously mobCal is still in its infancy, the project time only made room for implementing few of the possible use cases. Consequently, many interesting use cases are left for future work. Here are listed some possible features that can be a starting point for future implementation on the project.
• Map calendar entries to location: Associating a calendar entry with a location creates metadata information about the entry that can be used to realize more user stories. The calendar interface on the device has a location field that can be filled out. The system could use the content of that field as the input into a geological search query on a service like maps.google.com, in order to map it into an actual location. Through the interface users could define the location of an event and define locations for ambiguous entries likeHomeandWork.
• Get directions to a meeting: When able to map a location string into an actual location, the location information can be used to replace the stan- dard alarm with an alarm with directions to the location.
• Flexible alarm time: Depending on location, the alarm time could be var- ied and calculated by the system.
• Link different users together: Linking different users together provides another set of usable metadata to implement new services. Linking the users together can happen through use of the system, for example by querying the address book or some social network service. Of course all linking must be done with users consent.
• Organize meetings: A meeting usually has many participants. When planning a meeting, the owner of an entry could invite other users to join the meeting. Invited users would get a confirmation request they could accept. Users could also opt into a meeting, leading to the owner getting a confirmation request.
• Send change request notifications to meeting participants: If a partici- pant in a meeting would like to change the meeting time he could simply do so in the calendar application on his device. The system noticing the changed time entry would consult the calendar entries of other partici- pants and in a case of a collision report it back to the changer, possibly with a suitable suggested time. In case of no collision other users would be sent a changed meeting time request and if successfully accepted by everyone the meeting times would be changed automatically.
94 CHAPTER 8. A CASE STUDY: MOBCAL
• Notify delays: In combination with the location information above, par- ticipants in a meeting could receive notifications in case a participant is running late with an estimated arrival time.
• Suggest meeting: Through the public / private tag on entries, users could create meeting suggestions that would replicate to their friends. Users could choose to subscribe to other users public entries, have them repli- cate to their device or get notifications. They could then even opt into a specific entry.
• Archive media files: Information from the calendar could be used to tag metadata to media files on the mobile device. Calendar entries define metadata such as time and can be used to archive media files. As an ex- ample of that is displaying images taken and recordings made in a meet- ing, on the web site.
As shown, there are possibilities in creating new use cases and services for the standard calendar application, which is available on every mobile device today. It can be done without any modifications or programming on the device, given that the device is publishing the appropriate set of Web services.
Chapter 9
Conclusion and further work
As has been demonstrated, providing HTTP connectivity to a mobile device opens new ways in interacting with the device and enables new use cases. In the report, use cases relating to the calendar of the mobile device have been derived. The focus has been on the calendar since it is personal, present in every device and its use is commonly understood.Using Web services allows publishing functionality in a more structured and controllable manner. Further it enhances reuse of services, reducing the im- plementation needed for applications. Web services also help utilizing the communication channel in a more efficient way. Only fetching the required information from the device instead of a full web page including markup in- formation. Binary serialization of the XML data can also be used to reduce the amount of transmitted data. Further, by introducing a proxy in the message path data can more efficiently be cached and the number of requests to the device limited.
In the project, a framework for publishing and managing Web services is sug- gested. This framework has been successfully implemented on a commercial mobile device. The framework makes it easy to publish normal Python classes as services and works well with established Web services standards. It has been shown that the added processing needed to handle service management, user management and validation of users, does not significantly impact the response time for the Web services. Even despite the fact that it has been im- plemented in Python, an interpreted language. A native C++ implementation should press the processing speed further down, bringing it close to the limi- tations of the wireless link.
Whether or not, mobile hosted Web services will succeed and propose any sig- nificant change in the mobile domain, in my opinion, depends upon two fac- tors.
First of all, it depends on the uptake of a solution providing HTTP connectivity to the devices. That is whether it will become common and natural for a mo-
96 CHAPTER 9. CONCLUSION AND FURTHER WORK
bile device to be addressable in this manner. As discussed in the first chapter, todays mobile networks are optimized for out-bound traffic. That proposes a thread to operators willingness for a large scale uptake of such a solution. To- day operators have direct contact with customers and have a lot of influence on the market and on the uptake of new solutions. Technologies like HSPA En- hanced Uplink, promising up to 5.8 Mbps on the uplink, should help making networks being optimized further for uplink access, and limit this thread. An- other influencing factor on the uptake of HTTP addressing is of course pricing on data usage. Todays rates are too high to stimulate such usage. That how- ever, seems to be changing with flat rate data subscriptions being introduced. Secondly for Web services to truly become beneficial and usable, depends on the industry capability to standardize the usage of Web services. Thus making them easily available and reducing the amount of Web services needed to be developed and maintained for each application. Most Web service interfaces in use to day seem to be based on an application specific interface. This is due to the fact that Web services are usually published by a central entity and used by multiple clients, where clients are implemented to utilize the interface of the service. Automatically searching for new service providers and binding to them, for example through a public UDDI discovery service, seemingly has not prevailed. This is supported by the fact that in 2006 IBM, Microsoft and SAP announced that they were closing their public UDDI nodes. Today UDDI is mostly used within organizations to maintain services and publish them to partners. Whether this will be any different for mobile hosted Web services remains to be seen. It is though necessary to bear in mind that standardization is at the heart of the telecommunication and mobile industry. Various aspects of the mobile devices are already standardized and capable standardization bodies like the Open Mobile Alliance (OMA), European Telecommunication Standards Institute (ETSI) and the 3rd Generation Partnership Project (3GPP) are already in place. It thus might not be fair to compare the standardization capabilities of the mobile industry with other industries that do not thrive on such common standardization. The effect of those standardization bodies is already demonstrated with the presence of the previously introduced Parlay X Web service standard.
The current framework has implemented a SOAP messaging interface, serializ- ing XML in the normal textual angle bracket form. It could be further extended to support binary XML serialization. In order to do so the SOAP parser and builder would have to be modified to support the binary XML serialization. The framework can also be extended with new interfaces, JSON serialization has been mentioned as an example. This could even be taken a step further to an interface making functionality available through a browser plug-in. This hints at a common service engine on the mobile device, providing access to de- vice functionality. The service engine whould be accessible through multiple interfaces, one being Web services communicating through SOAP messaging. This should enable development of applications for mobile devices that would have access to device functionality through a consistent set of services accessi- ble in a practical way for each scenario. The server based application controller would request Web services through SOAP messaging. The server based con-
97
troller delivers its interface in the form of XHTML/JavaScript/CSS to its clients that either reside on a personal computer or on the mobile device itself. The interface makes request back to the server controller, but additionally can also have access to device functionality through JavaScript calls. Based either on JSON services, if the interface is loaded on a remote client such as laptop, or on a browser plug-in calls, if the interface is loaded on the target device itself. This would enable creating truly interoperable and independent of access Web applications to for the mobile medium.
The mobile industry has proven that it is capable and willing to come together in open standardization to help new technologies and services to prevail. Be- cause of those conditions such a service framework and a standard service in- terface seems more like a logical next step rather than drastically new direction.
Appendix A
Mobile Web Service Interface
Table A.1:Mobile Web Services Interface
Presence
Services
Operations Availability getAvailability DeviceStateInfo getDeviceState setVolume setLocalTime SystemInfo getSystemInfo getMemoryInformation TerminalLocation getLocation getTerminalDistance getGSMLocation getGPSLocation TerminalLocationNotificationManager startGeographicalNotification startPeriodicNotification endNotificationDevice Utilities
Services
Operations Camera getInformation takePhoto PlayAudio playTextMessage playAudioMessage playVoiceXmlMessage SMSMessaging sendSMS sendSmsLogo sendSmsRingTone getSmsDeliveryStatus SMSNotificationManager startSmsNotification stopSmsNotification MMSMessaging sendMessage99 getMessageDeliveryStatus MMSNotificationManager startMessageNotification stopMessageNotification Telephone dialNumber hangUp answerIncomingCall TelephoneNotificationManager startCallStateNotification endCallStateNotification getActiveCallStateNotifications
Data Management
Services
Operations Contacts getContacts insertContact updateContact deleteContact getContacts findContacts importVCard createGroup deleteGroup getGroups moveToGroup Calendar getEntriesInMonth getEntriesAtDay insertEntry updateEntry deleteEntry getEntry insertVCalendar getEntries Logs getRawLogData getSMSs getCalls getFaxes getData getEmails getLogData getScheduler100 APPENDIX A. MOBILE WEB SERVICE INTERFACE
Mobile Web Service Framework
Services
Operations General restartServer displayMessage getUserConfirmation launchApplication Management installService deleteService updateService createUser deleteUser grantUserAccess deleteUserAccess changePassword checkIfUserExists getServicePolicy setServicePublic setOperationPublic setServicePrivate setOperationPrivate getUsers getInstalledServicesAppendix B
WSDL Interface
commons.xsd
Variable Element name Type Multiplicity DeliveryInformation address anyURI [1..1] deliveryStatus deliveryStatus [1..1] SimpleReference endpoint anyURI [1..1] interfaceName string [1..1] correlator string [1..1] TimeMetric metric metricType [1..1] units init [1..1]
102 APPENDIX B. WSDL INTERFACE
Variable Enumeration value deliveryStatus DeliverdToNetwork DeliveryUncertain DeliveryImpossible MessageWaiting DeliveredToTerminal DeliveryNotificationsNotSupported metricType Milliseconds Seconds Minute Hour Day Week Month Year
103
Availability.wsdl
Direction Element Type Multiplicity
getAvailability: Information about the availability of the device owner input resultFilter string [0..1]
output Profile ProfileType [0..1] CalendarAvailability boolean [0..1] ReservedForSec int [0..1]
Table B.3:Availability portType
Variable Enumeration value ProfileType general silent meeting outdoor pager offline drive custom Table B.4:Types
104 APPENDIX B. WSDL INTERFACE
Camera.wsdl
Direction Element Type Multiplicity
getInformation: Retrieves information about device cameras
input resultFilter string [0..1]
output camerasAvailable cameras availableType [0..*] imageModes imagesModes [0..1] imageSizes imageSizesType [0..*] flashModes flashMode [0..*] maxZoom int [0..1] exposureModes string [0..*] whiteBalanceModes string [0..*] takePhone: Takes a photo with a camera on the device
input mode imageModes [1..1]
size imageSizesType [1..1] flash flashMode [1..1] zoom int [1..1] exposure string [1..1] whiteBalance string [1..1] position int [1..1]
output out anyURI [1..1]
Table B.5:Camera portType
Variable Enumeration value cameras availableType general
imageModes RGB12 RGB JPEG Exif JPEG JFIF RGB16 imageSizeType 1280x960 640x480 160x120
105
Variable Element name Type cameras availableType id int description string imageSizeType width int height int
106 APPENDIX B. WSDL INTERFACE
Contacts.wsdl
Direction Element Type Multiplicity
getContact: Retrieves a contact
input id int [1..1]
resultFilter string [0..1] output out contactDetails [0..1] insertContact: Creates a contact
input contactDetails contactDetails [1..1]
output id int [1..1]
updateContact: Updates a contact
input contactDetails contactDetails [1..1]
output out string [1..1]
deleteContact: Deletes a contact
input id int [1..1]
output out string [1..1]
getContacts
input resultFilter string [1..1] output out contactDetails [0..*] findContact
input searchTerm string [1..1] resultFilter string [1..1] output out contactDetails [0..*] importVCards
input vcards string [1..1]
output out string [1..1]
createGroup
input name string [1..1]
output out string [1..1]
deleteGroup
input id int [1..1]
output out string [1..1]
moveToGroup
input contactId int [0..1]
contactName string [0..1]
groupId int [0..1]
groupName string [0..1]
output out string [1..1]
107
Variable Element name Type Multiplicity contactDetails city string [0..1] companyName string [0..1] country string [0..1] date dateTime [0..1] dtmfString string [0..1] emailAddress string [0..1] extendedAddress string [0..1] faxNumber string [0..1] firstName string [0..1] jobTitle string [0..1] lastName string [0..1] mobileNumber string [0..1] note string [0..1] pagerNumber string [0..1] phoneNumber string [0..1] poBox string [0..1] postalAddress string [0..1] postalCode string [0..1] state string [0..1] streetAddress string [0..1] url anyURI [0..1] videoNumber string [0..1] wvid string [0..1] firstNameReading string [0..1] lastNameReading string [0..1] picture base64Binary [0..1] speedDial string [0..1] thumbnailImage base64Binary [0..1] voiceTag base64Binary [0..1] id int [0..1] synchronization string [0..1] asVCard string [0..1] title string [0..1] lastModified dateTime [0..1] groupDetails id int [0..1] name string [0..1]
108 APPENDIX B. WSDL INTERFACE
DeviceStateInfo.wsdl
Direction Element Type Multiplicity
getDeviceState
input resultFilter string [0..1]
output battery level battery levelType [0..*]
localtime dateTime [0..1]
connection type connection typeType [0..*] signal bars signal barsType [0..*]
signal dbm int [0..1]
audio volume int [0..*]
max volume int [0..*]
available networks available networksType [0..*] setVolume
input volume int [1..1]
output out string [1..1]
setLocalTime
input time dateTime [1..1]
output out string [1..1]
Table B.10:DeviceStateInfo portType
Variable Element name Type Multiplicity available networksType
name string [1..1]
type connection typeType [1..1]
connection typeType
connection type string [0..1]
109
General.wsdl
Direction Element Type Multiplicity
restartServer
input resultFilter string [0..1]
output battery level battery levelType [0..*]
localtime dateTime [0..1]
connection type connection typeType [0..*] signal bars signal barsType [0..*]
signal dbm int [0..1]
audio volume int [0..*]
max volume int [0..*]
available networks available networksType [0..*] setVolume
input volume int [1..1]
output out string [1..1]
setLocalTime
input time dateTime [1..1]
output out string [1..1]
110 APPENDIX B. WSDL INTERFACE
111
Direction Element Type Multiplicity
getFaxes
input startLog int [0..1] numOfLogs int [0..1] mode modeValues [0..1] resultFilter String [0..1] output out logsType [0..*] getData
input startLog int [0..1] numOfLogs int [0..1] mode modeValues [0..1] resultFilter String [0..1] output out logsType [0..*] getEmails
input startLog int [0..1] numOfLogs int [0..1] mode modeValues [0..1] resultFilter String [0..1] output out logsType [0..*] getRawLogData
input resultFilter String [0..1] output out logsType [0..*] getLogData
input logType typeValues [0..1] startLog int [0..1] numOfLogs int [0..1] mode modeValues [0..1] resultFilter String [0..1] output out logsType [0..*] getSMSs
input startLog int [0..1] numOfLogs int [0..1] mode modeValues [0..1] resultFilter String [0..1] output out logsType [0..*] getCalls
input startLog int [0..1] numOfLogs int [0..1] mode modeValues [0..1] resultFilter String [0..1] output out logsType [0..*] getScheduler
input startLog int [0..1] numOfLogs int [0..1] mode modeValues [0..1] resultFilter String [0..1] output out logsType [0..*]
112 APPENDIX B. WSDL INTERFACE
Variable Enumeration value modeValues in out fetched missed in alt out alt
Table B.14:Simple types
Variable Element name Type Multiplicity logsType number string [0..1] name string [0..1] description string [0..1] direction string [0..1] status string [0..1] subject string [0..1] id int [0..1] contact int [0..1] duration int [0..1] durationType int [0..1] flags int [0..1] link int [0..1] time dateTime [0..1] data string [0..1]
113
114 APPENDIX B. WSDL INTERFACE
Direction Element Type Multiplicity
installService
input location string [1..1]
service string [1..1]
classname string [1..1] receiptRequest SimpleReference [1..1]
output out string [1..1]
deleteService
input service string [1..1]
output out string [1..1]
updateService
input location string [1..1]
service string [1..1]
classname string [1..1] receiptRequest SimpleReference [1..1]
output out string [0..*]
deleteUser
input username string [1..1]
output out string [1..1]
grantUserAccess
input username string [1..1]
service string [1..1]
operation string [1..1]
output out string [1..1]
deleteUserAccess
input username string [1..1]
service string [1..1]
operation string [0..1]
output out string [1..1]
changePassword
input newPassword string [1..1]
output out string [1..1]
checkIfUserExists
input username string [1..1]
output out boolean [1..1]
checkIfUserExists
input username string [1..1]
output out boolean [1..1]
checkIfUserExists
input username string [1..1]
output out boolean [1..1]
checkIfUserExists
input username string [1..1]
output out boolean [1..1]
115
MediaFiles.wsdl
Direction Element Type Multiplicity
getPicture
input startDate dateTime [0..1] endDate dateTime [0..1] resultFilter string [0..1] output out mediaFileType [0..*] deletePicture
input deviceFile string [1..1]
output out string [1..1]
getAudioFiles
input startDate dateTime [0..1] endDate dateTime [0..1] resultFilter string [0..1] output out mediaFileType [0..*] deleteAudioFiles
input deviceFile string [1..1]
output out string [1..1]
Table B.17:MediaFiles portType