A Web Services Strategy for Mobile Phones
In most web services presentations, the speaker has a slide of a mobile phone, a PDA, a computer, and other devices communicating with a web service via SOAP and HTTP. You quickly envision a utopia of universal access but overlook the fact that your old Nokia doesn't do XML web services. If you have a J2ME-enabled phone connected to the Internet, it's very possible to interact with web services directly. However, the majority of mobile phone users do not have these phones, which means an alternative mode of access must be provided.
Some developers assume that deploying web services is all about publishing a WSDL file. This might be enough for integrators to use your web service, but in order to facilitate widespread adoption of your service, some type of UI for regular users should be deployed to abstract away the technical details. It is possible to dynamically generate HTML web pages with input forms from WSDL files (SOAPClient is a good example of this). This offers a good environment for testing web services and, in some cases, might be all you really need to offer your users. Creating an HTML interface to your web service insures access from any computer, but what about mobile phones?
Mobile web services
Wireless carriers currently offer services that allow information to be "pushed" to your phone or accessed from your phone such as weather, stock quotes, news, traffic, and sports updates. With web services, phones now have the potential to actually consume useful services. But before developing a mobile client, you might want to think twice before taking the SOAP/HTTP route. First of all, turning your phone into a SOAP client might have some performance costs related to slow data speeds and processing both HTTP commands and XML. Secondly, most phones don't come with web services support built in. Finally, you can hide the web services complexity and leverage existing technologies to make use of their widespread availability. This would require a gateway to sit in between the phone and the web service to handle the passing and conversion of messages but you no longer have to worry about client-side performance issues or even deploying a client.
The gateway would take care of all the SOAP/HTTP request and response handling and then returns results back to the mobile phone in a supported format. There are really only a few means you can rely on being available: text-messaging, voice, and data services. For text-messaging, you can deploy a bot that sits between your client and your service. For voice, you can allow your clients to call a number and issue voice commands by creating a VoiceXML wrapper around your web service. A good example of this is Tellme's service that gives voice driving directions using Microsoft's MapPoint web service. For data services, you can have a WAP gateway that takes requests from a WML page, calls the service, and then returns the results back to a WAP browser in the WML format. Some phones have XHTML browsers that you can take advantage of and some even offer development environments that allow you to call the web service directly from the phone. Even though you cannot guarantee that your users will have phones that offer such features now, using data services along with a SOAP messaging library might be a common solution for deploying mobile clients in the future. Development environments such as J2ME and the .NET Compact Framework give developers robust platforms for developing advanced mobile clients. However, for simple clients that mainly access text-based information, deploying a gateway is sufficient.
Deploy Gateways for Maximum Availability
When deciding what kind of client to deploy, your final decision should be based on making the client available to as many users as possible. This makes deploying a gateway the best solution. You no longer have to worry about technology support or even client application installation. For example, if you deploy a Short Message Service (SMS) gateway, you have just turned every mobile phone into a potential client. By using SMS you can also take advantage of its "store and forward" features which guarantee message delivery. Sending a SMS message from a client is pretty straightforward, but messages sent between service providers and SMS gateways are quite the opposite. The SMS Forum recently announced a plan to encode these messages using SOAP and HTTP to insure interoperability -- another testament to the adoption of web services.
VoiceXML is a language for building voice applications much like you hear when calling customer service hotlines. It is an XML-based standard developed by the W3C's Voice Browser Working Group. Most VoiceXML developer portals give you access to a phone number for testing your application; however, VoiceXML is not limited to phones and can actually be accessed by any VoiceXML-enabled client. This client can be the usual phone, but it could also be an existing Web browser with a built in VoiceXML interpreter. A good example of this is the multimodal browser being developed by IBM and Opera based on the XHTML+Voice (X+V) proposed specification. The term "multimodal" simply refers to multiple modes of interaction by extending user interfaces to include input from speech, keyboards, pointing devices, touch pads, electronic pens, and any other type of input device. The W3C also has a Multimodal Interaction Working Group that is developing standards to turn the concept of universal accessibility into a reality. The basic concept of VoiceXML is to issue prompts to a user and then have that user respond using their voice. Once the user's voice is captured, the voice application can perform a specific task and return the results. Due to the inaccuracies of voice recognition, I highly recommend writing applications that accept a predefined set of commands in combination with very little dynamic speech input from the user.
The Wireless Application Protocol (WAP) is a set of standards to enable wireless access to Internet services from resource-constrained mobile devices. WAP provides an entire architecture to make a mini-Web possible by defining standards such as the Wireless Markup Language (WML) and WMLScript. Think of WML and WMLScript as HTML and JavaScript, respectively, optimized for the mobile phone world. WAP development is fairly easy and you can start serving up WML pages instantly by setting the appropriate MIME types on your web server. Wireless carriers provide WAP gateways that translate the HTTP to the equivalent WAP optimizations. Since you are using a web server to serve up content, you can use APIs on the server-side to call web services and return the results in WML format.
Use J2ME for Advanced UIs
J2ME is gaining a lot of momentum as new J2ME-enabled phones hit the market. With every major manufacturer embedding Java on some of their phones, Java in the mobile space is no longer hype. An interesting note on J2ME is that all Mobile Information Device Profile (MIDP) implementations must provide support for the HTTP protocol. This guarantees the availability of HTTP as a transport mechanism for web services. There is currently no standardized web services support for J2ME, but JSR 172 defines a J2ME Web Services Specification that will eventually provide standard access from J2ME to web services. In the mean-time, you can use a third party library such as kSOAP. J2ME also has SMS support through the Wireless Messaging API (WMA) optional package.
Text-messaging
Text-messaging development might sound simple, but it is the most confusing route to take. I mentioned SMS earlier, but we also have EMS, MMS, and other Instant Messaging protocols on the scene. AOL Instant Messenger (AIM), MSN Messenger, and Yahoo Messenger all offer bridges from their protocols to SMS. T-Mobile even has AIM embedded into some of its phones. An easy way to build a service would be to connect to one of these popular IM protocols to avoid dealing with the SMS mess. When you build SMS applications directly, you have to worry about possible hardware requirements, SMS gateway deployment, and carrier partnership. Don't forget, you will require some kind of phone number for users to access your application and, since you are connecting to a cellular network, a business account.
Pages: 1, 2 |
