Let's face it, we're going mobile. You only need to consider how you communicate these days to understand that. I, for one, find that my Blackberry is becoming my e-mail terminal of choice, as well as my best source of information via the WAP-enabled Web browser built-in. And oh yes, it's a phone. Others are finding that their mobile phones are their single point of contact, both voice and data, and this trend will only continue as we learn to cut the wires and as wireless networks become more pervasive and much faster.

The use of mobile devices as a personal information delivery platform is commonplace today. However, as mobile devices and standards progress we've begun to consider our cell phones as enterprise application delivery platforms as well. And, to this end, have also developed standards for Web services delivery on mobile devices.

The fit is clear. Mobile devices are basically becoming our new client platforms, and thus need to support most of the new computing paradigms, including SOA. Moreover, the demand is there as corporate America learns that they don't need to be tied to their computers in order to do business. Finally, we seem to have both the coverage and bandwidth needed to support this type of infrastructure. Indeed, I foresee a future where the number of applications delivered over wireless networks exceeds those delivered via more traditional means.

Web Services in Motion
The cell phone companies have not been standing by watching this trend emerge; they have begun to lead the way. At JavaOne, Nokia announced that they are building a service-oriented architecture framework on smart mobile phones that could make Web services more of a household word since it will run on our phones.

This is a bit different from more traditional SOAP interfaces between desktop/server applications and telecomm-hosted servers, such as MMS message servers, location servers (see below), and presence servers. We know those approaches work, but the core shift here is a move from simple information sharing to full-blown delivery of application services/behavior down to mobile devices. This is not only new, but useful. Nokia is proposing the integration of mobile clients directly into SOAs using asynchronous Web services.

Truth be told, mixing Web services with mobile devices is not a new concept. For instance, the .NET Compact Framework has been supporting Web services for a while now. On the Java side of things, kSOAP is a J2ME-based SOAP parser and JSR 172 provides a standard set of XML and SOAP APIs on J2ME devices.

The issue with the existing approaches is the assumption that the device interacts with one service at a time, using synchronous mechanisms (much like traditional RPCs). As you may know, synchronous and mobile devices are not terms that go well together, so many developers opted for more customized types of approaches rather than leveraging these standards.

Web services, in the context of mobile computing, is all about the notion of devices that can move in and out of service areas, and at the same time find and leverage Web services as needed and with the right validation. This should be a bidirectional mechanism where mobile devices can both consume and provide services; in essence, the mobile device becomes a peer.

Other Standard
There is never just one standard, is there? In the mobile Web services world, you also have to consider the Open Mobile Alliance (OMA) and their OMA Web Services 1.0 specification. On June 15, 2004, the OMA announced the public availability of new and "up-leveled" mobile specifications that are built by OMA member companies and define how wireless data services may be shared across operators, terminals and geographies. There are 350 member companies in the OMA.

This standard, like the Nokia announcement, defines how Web services may be exposed, discovered, and consumed using standard Web services technologies. The OMA Mobile Locations Protocol defines a core set of operations that the location server is able to perform, and the OMA Online Certificate Status Protocol defines a protocol for trusted certificate validation.

The goal of this specification is to provide guidelines for Web services implementations within the OMA architecture, and how to leverage SOA in the world of mobile devices. Moreover, it ensures interoperability across servers and terminals supporting Web services protocols.

This specification defines security threats and services, privacy and identity management, messaging and transaction, as well as policy and system management. It also defines the ability to deploy OMA Web services such that the processing associated with common, cross-enabler capabilities may be factored out of individual service enablers and delegated to other entities. Finally, the specification defines the ability to automate the discovery and use of policy information that governs Web services interactions.

What's Next?
There are still many technical challenges to consider, the most relevant being access control. In order for Web services to be effective on a mobile device a single sign-on scheme is needed to track all of the devices and services and determine who has permission to access what services. The OMA defines this type of mechanism, but this goes well beyond simple validation. You can bet that it is going to be a bit more complex than SOAP can handle, and you'll need new standard single sign-on services, such as those from the Liberty Alliance, perhaps built for mobile computing.

You also need to consider new runtime paradigms as well. Performance is a key issue, as well as connectivity, when you consider the lack of bandwidth that most wireless networks suffer from, as well as dead areas. We can't rely on fast networks to cover up inefficient programming techniques; the communication mechanisms need to be asynchronous and understand how to work around normal communications interruptions that you find in mobile network. It would be a hard pill to swallow to lose your sales order when you travel into a dead zone.