Welcome!

SOA & WOA Authors: Peter Silva, Maureen O'Gara, Tony Bishop, Mark O'Neill, Yeshim Deniz

Related Topics: SOA & WOA

SOA & WOA: Article

It's About More Than Just the PlumbingThe Real Issues That Need to Be SolvedAre the Nontechnical Ones

It's About More Than Just the PlumbingThe Real Issues That Need to Be SolvedAre the Nontechnical Ones

I've described elsewhere the idea of "swarms" - spontaneously federating devices and software services connecting over networks. Some people are now describing this concept as "wireless Web services," extending the group of ideas now being called services-on-demand.

As usual, the computer industry is keen to address the details of protocols and connections, but is leaving until later the real, people-centric issues that technologies can't solve.

Possibilities
Imagine the possibilities once we can have the services not only offered to us on demand via the nearest device but also have them include both our current context and our online profile. I'll be able to tell my car who to start for and how each person may use it ("yes, you can borrow it, but don't drive home if you're drunk, and stay under 50"). As my current meeting ends late, my PDA will offer suggestions for how to reschedule the rest of the day's meetings and travel. The just-in-time production line will be able to respond to all the inputs, including current demand in the retail stores. All sorts of ideas that we thought were the domain of intelligent agents will start to become a reality.

But hold on a moment. Can it all really happen like that? For some time now my thesis has been that we already have, or can imagine, all the technology we need to build these spontaneously federating solutions. The real issues lie elsewhere.

Standards
The first priority has to be open, loosely coupled standards, for content as well as infrastructure. In the area of standards, it's clear that we've made progress over the last decade. The Web browser gives me a standard space to interact with remote computers. GSM gives me a mobile phone that works worldwide. But we're not there yet with Web services, let alone with wireless Web services - none of the basic technologies is actually an open, royalty-free standard today. Discussion over the actual XML content of the transactions, although in progress at ebXML, is in its youth and under-supported by the key vendors. And peer-to-peer ideas tend to be neglected altogether.

If we've learned one thing from a decade of the Web, it's that the massively connected mesh demands open, loosely coupled standards - "open" in the sense of available to anyone to develop with or use without fee; "loosely coupled" in the sense of tolerating extension without opening a path to proprietary lock-in; "standards" in the sense that a democratic process offers every affected developer and user the chance to be involved in each change.

For services-on-demand (both Web services and P2P services) - to be offered to the mobile user, we'll need a serious commitment to openness and standards that extends beyond the mode of merely reconciling infrastructure for proprietary content that we're seeing at the moment from some.

Business Models
Secondly, we'll need some careful progress made on business models. Web services void the only business model that "free" services on the Web ever had - that of exploiting eyeballs. Without advertisements, many information providers will have to look elsewhere for a revenue model. So far as European telcos are concerned, the urgent need to validate their investments in 3G licenses may lead to progress here. We may see commercial-quality service federations created that are free at your desk but part of the service plan on the move - as long as we can overcome the contractual, legal, and intellectual property problems.

Logistics
The procedural barriers may, thirdly, prove to be the killers. Realistically, no one vendor or service provider will ever be able to provide everything you need - it will take a community. Building communities is the lifeblood of progress on the Web and has underpinned Web standards (W3C is essentially an expert community), open source development (from pioneers like Linux and Apache to commercial foundations like NetBeans and OpenOffice), and technology evolution. But the application space gets more complex once we go mobile. What about antitrust laws? What about intellectual property ownership? What about contractual protection?

And then there are the international issues - local languages, differences in jurisdiction, and so on. Can my swarm continue to work across state lines? How about across international boundaries? Or with local services in a country with a different local language?

Opportunity
After reading this far, you might think I'm pessimistic about services-on-demand being offered to the mobile user. But, on the contrary, I'm very optimistic. In the mobile space, in the absence of the monopolistic pressures that have impacted the PC market, we've seen extensive industry agreement. Up to this point, we've seen agreement on GSM and Java technology deliver a level playing field to the network operator and to the developer.

The plumbing is in place. But people and business issues have always been the linchpins in making new technologies real in the mass market. It's true for wireless Web services-on-demand as well.

More Stories By Simon Phipps

Simon Phipps, Sun's Chief Open Source Officer, is a technology futurist and a well-known computer industry insider. At various times he has programmed mainframes, Windows and on the Web and was previously involved in OSI standards in the 80s, in the earliest commercial collaborative conferencing software in the early 90s, in introducing Java and XML to IBM, and most recently with Sun's launching Sun's blogging site, blogs.sun.com. He lives in the UK, is based at Sun's Menlo Park campus in California and can be contacted via http://www.webmink.net.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Bruce Wallace 01/21/02 09:36:00 AM EST

In response to your editorial "Its about more than just the plumbing",
I am forwarding this letter I sent early last year in response to an
editorial in the Preview Issue of Web Services which foretold some
of your points related to business models and corporate/human nature.
Great minds think alike...

Date: Sun, 17 Jun 2001 11:41:21 -0400
To: info@sys-con.com
From: rbw@polyglotinc.com
Subject: "Where are Web Services Going?" doesnt go far enough...

Having read the "Another View" column in the Preview Issue of Web Services Journal, I feel gratified that I'm not the only one who sees a naked emperor. However, I think Mr Morgenthal left
out an even larger problem than the technical ones he raised.

How does anyone get paid for providing these web services?
How is the price negotiated? Since none of the negotiations for price/service agreements are automated, nor would any
accounting dept nor program manager allow them to be, this must all be manually set up and therefore negates the dream of automated discovery and use of Web Services.
Forget the computer-to-computer integration, how does the
WS-seller-to-WS-buyer integration get done? Even if one decided to allow service engagement to be dynamic and automated by setting some sort of dollar cap on a service by service basis in the search criteria in finding a web service provider, imagine the added complexity in building a system that could handle all the various modes of pricing from various vendors;
per call, per annual fee, per user, etc, etc.

Given the above, it seems that anything Web Services can realistically do, could have already been done with most of the existing technologies because the middleware is not the real problem and hence can't be the solution.