The idea might sound compelling, Carl Zetie says, but there are significant technical barriers.
The launch of the beta release of Microsoft .Net Compact Framework and supporting tools, following the initiation of the Java standards process for Web services on Java 2 Micro Edition clients, is the latest lap in the race to bring Web services to mobile devices. On the face of it, the idea of using Web services from a mobile device has considerable attraction. The concepts of discovery and dynamic access to services resonate with visions for mobile applications, where the user's context may change constantly, making different services or service implementations appropriate at different times.
However, for the near future, you should temper your expectations. Web services, in the full sense of the term, face significant technical barriers to adoption on mobile devices.
To understand the likely form of Web services on mobile devices, it's worth reviewing why full-blown Web services (i.e., a stack such as Soap, WSDL, and UDDI) aren't always appropriate.
Negotiation and discovery require multiple network round trips. The WANs on which mobile users rely may have high latency, and the users themselves may have low patience, making slow exchanges intolerable.
Web services may be very verbose, involving the transfer of large documents to the device. The typical bandwidth of current and emerging WAN services, even 2.5-generation networks, is measured in tens of kilobits per second, sometimes peaking above 100 Kbps. That's comparable to a fast desktop dial-up connection, not a LAN connection.
Large documents may be unsuitable for processing on a mobile device. They may require more working memory to store than is available to the device or more processing power to parse than is feasible to deal with them in real time. If the service doesn't know (or take account the fact) that it's corresponding with a limited mobile device, it will send inappropriate responses that are unusable by a mobile application.
For example, a large result set from a search might be returned to an application searching a catalog; but for a mobile device, a much smaller and more restricted result would be more appropriate. While well-designed Web services may offer multiple interfaces, some more suitable for mobile devices, not all Web services will be well-designed, and not all clients will be smart enough to take advantage of them.
Network limitations will not be completely addressed until true third-generation networks offering megabits per second of bandwidth to each device become available.
The device limitations are more challenging. On the highest-end PDAs, already running at hundreds of megahertz and offering 64 Mbytes of memory, the limitations will eventually succumb to Moore's Law, perhaps as soon as the next generation of devices, but it will be a very long time before the lowest-powered, high-volume devices can cope with large complex documents and thereby make Web services appealing as a mainstream means of mobile communication.
Despite these limitations, the marketing machine is building up a head of steam behind "Web services" for mobile devices. That's largely because of ongoing competition between the Microsoft and Java camps to establish "thought leadership" in this important emerging market. In public, both the Microsoft (.Net Compact Framework) and Java (J2ME) camps want to promote their positions as leaders in Web services and mobile technologies. Consequently, many marketing messages from both sides omit the subtle distinctions between Web services as commonly understood and Web services as they will initially be delivered for mobile devices.
In private, both sides recognize these limitations, and they are to a greater or lesser extent reflected in the reality of the respective technology road maps. In their early releases, both camps are working toward more limited and more appropriate interpretations of Web services. Strictly speaking, it's quite a stretch to describe what's being worked on right now as "Web services" as the term is commonly understood, although the proposals do share many of the fundamental standards of Web services and will deliver some--but not all--of the same benefits.
Don't view the technical barriers and the shortage of standards and production-ready technologies today as a complete block to the adoption of XML-based integration in the near term. Both experimentation in anticipation of standards and production adoption in appropriate circumstances are starting now. Early-adopter organizations are already experimenting with Soap or Soap-like integration over wireless LANs in particular, where the bandwidth issues are far less constraining.
The earliest adoption of full Web services will come in areas where the user experience can be separated from the latency introduced, where the bandwidth requirements are not an insurmountable problem, and where there's considerable value in reusing an existing Web service (possibly with a more appropriate interface) rather than developing a specific service for the small device. One example might include machine-to-machine communications, such as a set-top box communicating with a content provider. Web services will also begin to appear in device-to-server communication, where the communication takes place asynchronously from the user experience, such as where a transaction is completed on the device and later transferred to the server in background.
Despite the barriers above, some kind of XML-based integration today, leading to fuller Web-services implementation in the future, still has a lot of appeal. XML offers far greater likelihood of interoperability than binary protocols. That's an important attribute in a world in which the server side remains balanced between Java 2 Enterprise Edition and Microsoft .Net and devices remain highly diverse. As more business services are exposed as Web services, at first internally and later externally, the idea of reusing those same services on mobile devices is highly attractive. Just don't take the marketing too literally in the short term.
IT's Reputation: What the Data SaysInformationWeek's IT Perception Survey seeks to quantify how IT thinks it's doing versus how the business really views IT's performance in delivering services - and, more important, powering innovation. Our results suggest IT leaders should worry less about whether they're getting enough resources and more about the relationships they have with business unit peers.
What The Business Really Thinks Of IT: 3 Hard TruthsThey say perception is reality. If so, many in-house IT departments have reason to worry. InformationWeek's IT Perception Survey seeks to quantify how IT thinks it's doing versus how the business views IT's performance in delivering services - and, more important, powering innovation. The news isn't great.
InformationWeek Must Reads Oct. 21, 2014InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.