Why Bother?
When I was asked to focus this month's column on the subject of wireless and Web services, my immediate reaction was "Why bother?"

If you follow industry press and talk to prospects and customers, it seems that the brave new world of Web services is number 11 on the list of top 10 priorities for the wireless strategies of corporate IT managers and CIOs. Bandwidth, coverage, and device proliferation (and their associated management headaches) seem to be the real issues (or at least my top three) that bother folks today, and not some great new plumbing.

Bandwidth is certainly a concern that is well- documented - and we all know that come 2.5G or, even better, 3G, all these problems will be solved - even though we've started hearing rumors and concerns that many of the networks providers won't actually achieve the fabulous throughput we'd hoped for. (Well, I wasn't really interested in streaming video on my cell phone anyway. I'd be content if I could receive my voice-mail messages while in a roaming area.) Coverage really has two associated dimensions. One is the availability of any kind of coverage; the other is the availability of one single provider, or at least a coherent set of protocols and standards that make our applications and devices work seamlessly. Unfortunately, we can't assume full service on either.

Device proliferation introduces a real headache for IT managers. Sometimes employees purchase their latest new gadgets and then expect full-blown support from internal IT staff. In other cases, a smart sales specialist sends a company's brand new offering - as a complimentary offer - to the ruling senior vice president of one division, while another company targets that VP's counterpart in another division, and one-two-three you have two different "standards" for wireless devices that you need to deal with.

Not much work to do here for Web services, you might say. However, I believe each of these areas can get some help from Web services. They won't solve the problem, but at least they should ease some of the pains.

What it all really amounts to is the fact that we have to deal with multiple devices (each with their own form factor) that need to receive services via potentially multiple (incompatible) technologies via carriers that may offer varying levels of bandwidth. And to add one more level of complexity, ultimately we don't deliver to devices but to human end-users (remember, those entities that make software engineering harder than it really should be).

The dynamic nature of Web services will help us create services more usable for delivery to devices requiring such a multidimensional customization approach. However, I believe it will take Web services, in conjunction with other technologies and patterns developed currently under the code name "Semantic Web," to have the potential to tremendously impact the way we address these problems.

Web Services and Wireless
Separation Is Good
Since the dawn of markup languages, we have come to realize that the more we separate the individual building blocks of our applications from each other, the more adaptable and dynamic they are and the more easily we can re-assemble them at design- and run-time.

XML (or rather its parent, SGML) was the first step in separating content from display. In programming, the model-view-controller (MVC) paradigm is experiencing a renaissance as well. Renaissance because not only do we use MVC in the context of modern-day J2EE, but developers of Smalltalk-based systems have used this approach since the '80s. Web services - the separation of business components from their associated display (or to be more precise, separating a services interface from its underlying implementation as well as separating a method-call from the transport protocol over which it operates) - is yet another piece in this ongoing trend.

So why do we care about this from the perspective of the wireless Web? As we have said, the challenge at hand is to build applications and services that can deal with the various factors that impact the way a service is being delivered to a wireless device. Web services, because of their componentized and de-coupled nature, are one important cornerstone of these services.

One Service for Multiple-User Interface
One of the most obvious benefits of wireless Web services is the elimination of a hard-wired user interface. Each device is unique in its form factors, screen size, support of colors, font sizes, and so on. Using Web services we can develop individual style sheets for our services that reflect the constraints for a particular device, or maybe even better the bandwidth situation at hand combined with other contextual factors (more about this later, however). When I say style sheets, I really mean any kind of technology that allows us to bind a user-interface to a business object at run-time, whether that is XSLT, JSP, or ASP conceptually doesn't matter.

From Fat-Client to (Very) Thin-Client
Web services allow us to take monolithic applications and offer discrete components of these as standards-based services. This simple step alone brings with it enormous results. Instead of potentially having to install fat clients on our wireless devices (as in the case of a PDA), we can deliver a service dynamically and on-demand. The smaller footprint of a wireless Web service also means that our dependency on high-performance networks is reduced significantly (yet not fully eliminated). As a secondary effect of wireless Web services, we may also want to mention that since we don't have to install any client software, we're able to reduce many of the management nightmares associated with these.

Having said this, what does not go away is the requirement to develop different style sheets for different devices, or at least categories of devices, as required. The difference is that, instead of having to install an update on the client device each time we change something, we can perform these changes on the server-side and, automatically, the next time the client tries to access that service, the new style sheet will be used.

(Semantic) Wireless Web?
Having Web services that provide us with an agile business backbone that's highly dynamic, parametric, and customizable is great. However, without information about how we utilize this flexibility, it's almost like a car engine without wheels. While this is true for any device, it's even more important for wireless devices, because of the complexity of the service delivery issues involved.

I am a firm believer that the power of the wireless Web will largely depend on our ability to deliver on the vision of the semantic Web. There are a lot of discussions underway about the semantic Web and you can easily get lost in academic thoughts (I will, for now, try to steer clear of discussing the beauty of ontologies, as I don't want to create major headaches for you and myself).

To keep it simple, in my mind, the semantic Web has fundamentally three cornerstones: information, devices, and users.

Three Cornerstones of the Semantic Web
Information: The semantic Web (unlike the current Web) is an infrastructure where computers and humans are equal citizens. As such, we need to store and capture information so that humans and machines alike can process it. To some extent this means describing data using standards like XML, but also providing additional explicit information about that data by means of metadata (maybe using RDF). This applies as well to documents that aren't in XML form, as in various kinds of electronic office documents. Why? Because only if we know enough about the information we (the citizens of the semantic Web) are processing can we do things like a high-precision search that really delivers the results we are looking for. Only with enough metainformation can we help machines differentiate between the meanings of certain words used in different contexts. Conversely, we also need to enable machines to understand that FirstName, Fname and FN are really the same concept, the first name of a person, even if their labels differ.

Devices: As we've discussed in previous sections, each wireless device has its own profile associated with it. These profiles need to be captured and made available in a standards-based fashion. Some of the characteristics of a device profile will be static (such as the often-cited screen size); others will be more dynamic in nature, bandwidth is a prime example.

Users: We need to capture information concerning the ultimate target of any information processing - again, the human end-user. The who, what, how, where, and why of calling a service - from a user perspective - will ultimately determine in which form this service needs to be rendered to the user.

Who, How, What, Where, and Why
Who is the user that requests a service? This is the first crucial question for any services delivery, wireless included. The "who" will determine if a user is permitted to enter our system - let's say an enterprise portal to begin with. However, we can go beyond these basic security issues and also determine any kind of preferences a user might have regarding their wireless service. Do they prefer a certain color-scheme, a certain font size or a certain way of ordering search results after a query? The more we know about who a user is and what their preferences are, the better we can cater to these individual choices.

How a service is being accessed includes information about a device and its associated profile. Are we talking about a browser on a laptop, a browser on a PDA, a cell phone, or a voice interface? Whatever the answer to this question is will determine the way a service needs to be presented to the user.

What is being accessed? Once we've authenticated the user (i.e., once we have made sure a user is the person they claim to be), we can determine whether a user is entitled to access that service to begin with. In addition, through looking at the what, we may need to add additional processing steps, such as converting a document to be suitable for the form factor of the device at hand. Beyond simple data and document transformation, depending on the device we may choose to use a different strategy to allow users to navigate between the various service components. For example, strategies for navigation in the context of a cell phone will look very different than, say, a PDA with a Web browser and a wider screen. If I access a document I may need to split it into segments requiring the user to press a button to page down; on a PDA we may be content with taking the whole document and relying on the installed browsers' scrolling capabilities (we still may have to convert heavy graphics to some smaller and more digestible format).

The where question takes us into the brave new world of location-based services. Let's say you call on the weather service. A device should be intelligent enough to know that you are in Chicago and not ask you to supply a ZIP code. But what if a device doesn't have location information available? There are numerous clues from which we can deduce the location of a user. How about checking the electronic calendar? It's Thursday; the electronic calendar says the user is (supposed to be) in Chicago - ergo? (Before being accused of smoking illegal substances, I do readily admit that to deliver on that vision a few other things have to happen as well, but that is exactly what the Semantic Web efforts are starting to do.)

Why? Now it gets really tricky. Actually, there's less black magic involved than you might think. As an example, let's look at a customer relationship management service. Imagine two scenarios: in the first one you are the sales executive and you're at a customer site. You start the service via your PDA, it asks for a customer name and laun-ches a search. It finds 10 customers by the last name of "Smith," and after paging through the list you find the right one and bring up the associated customer record.

In the second scenario, however, you again start by launching the service; the service, however, knows (thanks to structured information in your office system) that you are supposed to be at Smith's office at this time of the day and after confirming the fact that this is still the case (you may be running late), it displays the customer record for you. Which one would you prefer?

A Slam Dunk?
In the previous sections I've presented a vision that combines the wireless Web with Web services as well as the semantic Web. But none of the glorious outcomes described will be achieved for free.

We need to start capturing enough metainformation about our information assets so we can do more intelligent work with them. This would be almost impossible to do manually. However, I believe increasingly (semi-) automated tools will allows us to analyze our structured and unstructured data-sources to help with the creation of more intelligent metadata.

We need to develop Web services so that they are flexible enough to support the various interaction modalities required by wireless devices. It will be interesting to see which patterns for business objects and style sheets we will see emerge over the next months.

Most important, we'll need to put the user at the center of what we do. The e-business systems we build need to understand that whatever a user does, it does for a particular reason. Only if our systems are smart enough to understand a user's context for an action can we optimize a service for a wireless device (or any device for that matter).

Some of this context we can derive from explicit sources such as a business process description or a workflow. On the other hand, we'll be able to derive a lot of the context from a user's behavioral patterns and actions. In many ways, the time has come to use the "reasoning" power of computers to help services understand what we do and why we do it. The rise and fall of a certain paper clip, friendly and always eager to help, reminds us how difficult this task can be.

Author Bio:
Norbert Mikula is a founding member of DataChannel and an integral part of their strategic product planning and technology research. He has more than 10 years of experience in building and delivering Internet and e-business technologies. Norbert serves as vice-chairman of the board of directors of OASIS and is industry editor of Web Services Journal. He is recognized internationally as an expert in Internet and e-business technologies and speaks regularly at industry events. NORBERT@DATACHANNEL.COM