A Web Services Strategy for Mobile Phones
August 19, 2003
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.
SMS Workarounds
Most wireless carriers allow anyone to send SMS messages to their customers via email. Although users cannot reply to the sender of the email, this is useful for notification messages. You have to be a "premier partner" to be able to send and receive, but the average programmer can use an SMS Broker to have the same access without going broke. SMS Brokers partner with a cellular service provider and then lease access to developers. Simplewire offers one such development environment for creating and testing your wireless messaging application. They have a free evaluation version and they also offer paid commercial deployment packages. ActiveBuddy's BuddyScript SDK is very complete solution for developing, testing, and deploying your interactive agent. The BuddyScript SDK includes its own scripting language, IDE, server for deploying agents, and much more. You can launch your interactive agent to mobile users via SMS and WAP without setting up a relationship with a wireless carrier. The BuddyScript Server included in the SDK can exchange data via SOAP over HTTP. The only downside to the BuddyScript approach is that you are pretty much tied in to their development platform.
For the tech savvy, you might be able to buy a data cable for your GSM phone and, with the appropriate software, process the modem commands. Of course this is not suitable for a commercial application, but they do have dedicated GSM modems. So, theoretically, you can get a personal account with a wireless GSM carrier, take out the SIM card, put it in a dedicated GSM modem, and hack your way through to make it work. And, on the subject of hacking, I must mention Kannel, an open source WAP and SMS gateway.
VoiceXML
Accessing web services with VoiceXML has never been easier using BeVocal's JavaScript SOAP API. The BeVocal Cafe is an excellent place to get started; it offers a phone number you can call to access your application as well as documentation, samples, and tools.
Earlier I mentioned how Tellme offers access to voice driving directions using the MapPoint web service. Tellme also offers a robust development environment for developing VoiceXML applications. Unlike BeVocal, Tellme does not have built-in support for SOAP. You would have to roll your own Javascript Library or you could forward the input to an external application with SOAP support (e.g. a CGI script or Servlet) and then have that application generate VoiceXML back to the client. Have you ever picked up the phone only to hear an automated message? The telemarketers are getting lazy, but now you too can bug people with Tellme's Notifier service which allows your VoiceXML application to initiate the call to your clients. The Notifier service can be useful for reminders of appointments and other types of asynchronous messages.
WAP
Since you cannot view WML on regular browsers, you will need a WAP browser emulator for testing your WAP applications. WAP also allows applications to initiate sessions through the use of the use WAP Push Access Protocol. By creating push-enabled applications, you can implement asynchronous messaging. Openwave provides a WAP Push Library as part of its Openwave Mobile Developer Toolkit (OMDT). The OMDT is an excellent place to get started with its inclusion of emulators, messaging APIs, and support for the latest technologies in the mobile world. Nokia also has an excellent resource page that has tools and documents to help you get started.
If you don't have access to a WAP gateway don't forget about the open source Kannel project. The open source crowd will also enjoy Enhydra's open source Java/XML application server. Although you can serve up WML pages using any Web server, Enhydra provides an excellent framework for separating presentation from code. Using Enhydra's XMLC, you can convert a specially formatted WML document into objects that you can access from your Java code.
J2ME
The Wireless Messaging API (WMA) package gives you access to SMS functionality but there are third party packages that are more suitable for XML messaging. kSOAP, another open source project from Enhydra, is a lightweight SOAP implementation suitable for J2ME. If you think SOAP is too bloated and want to shave off some overhead, Enhydra also has an XML-RPC implementation (kXML-RPC project). For the Java RMI and JMS fans out there, there is a J2ME RMI optional package and a commercial wireless JMS solution available. To speed up your development efforts, you might want to consider using one of several SDKs available. Sun and Nokia's toolkits can run as standalone tools and also integrate into SunONE and JBuilder.
.NET Compact Framework
The .NET Compact Framework provides a robust environment for developing mobile applications. In traditional Microsoft point-and-click fashion, you can have an application running with minimal effort. If you are a .NET developer, you will enjoy its .NET Framework heritage and its integration with Visual Studio .NET. The .NET Compact Framework will definitely have its biggest impact in the PDA market where Windows enjoys some success. The downside is that the .NET Compact Framework has no market share whatsoever in the mobile phone space and it will try to break into a tight market.
Conclusion
With the availability of packet-switched, always-on networks for mobile phones becoming more widespread, mobile access to data will become easier than ever. web services seem like the natural solution for integration problems, but mobile phones do not have the privilege of guaranteeing support for the core web services technologies. However, you can still effectively deploy a web service for mobile clients by deploying a client interface using existing technologies available. Technologies such as SMS, WAP, and VoiceXML can be utilized to make this possible. As more mobile phones support J2ME, you can even choose to deploy a pure SOAP client without the need for a middleman.