"As Big a Change as E-Mail"

BEA Systems' Adam Bosworth, one of XML's chief architects, talks about the current state of Web services and the technology's potential

Only a few years ago, Web services -- the awkward label denoting a technology that enables previously alien computer systems to communicate via the Internet -- was virtually unheard of. Today, the name is no catchier, but the idea is catching on -- thanks in no small part to the work of Adam Bosworth.

In the 1990s, Bosworth led software king Microsoft's (MSFT ) efforts in developing XML (extensible markup language), a key tool that allows all data -- anything from a medical record to an address -- to be recorded in the same language. XML later became an integral part of Microsoft's .Net (pronounced dot-Net) initiative, a set of hardware and software tools that allows for seamless retrieval, manipulation, or exchange of data from different applications -- in other words, for Web services.

Bosworth "is somewhat of a celebrity among people consumed with XML," says Dwight Davis, a vice-president with emerging-markets researcher Summit Strategies in Kirkland, Wash. That makes him one of the progenitors of Web services. So great is his stature in the industry that Bosworth's current employer, infrastructure software company BEA Systems (BEAS ), recently distributed a bobblehead doll of him at a company-sponsored Web-services conference.

As BEA's chief architect, Bosworth is developing tools designed to make sure that Web services are used by more industries to link together more devices. Bosworth talked to BusinessWeek Online Reporter Olga Kharif on June 17 about the future of Web services and the challenges that lie ahead for developers of the technology. Here are edited excerpts of their conversation:

Q: What's driving Web services today?


Mainly, the need to integrate software applications across big enterprises. [Web services] offers a huge return on investment, and it's easy to do. Every customer I talk to is doing Web services internally, then looking at [implementing it with their] partners.

Of course, some companies have done things you don't want to see with Web services. The whole idea was that not only can your programs talk to another one but if you change a field [such as a customer's address] in one program, you wouldn't break the other program. There are some customers who don't make sure that this happens. Some products, such as .NET, don't enforce this.

Q: What do you think of .Net in its present form?


I think .Net was a good first step. There wasn't a [toolbox for developing Web services] before that mere mortals could use. The big issue I have with .Net -- and I have no doubt it will be fixed -- is that as a framework for developers, it encourages a couple of things you don't want to encourage. I already mentioned one.

Also, it wasn't focused on the enterprise and delivering service-level volumes. While it's easy to use and the applications interoperate well, the systems you build with it don't necessarily provide the robust model for scaling and for change that a big organization will need. [Microsoft] fully understands those problems. I'm confident they'll get fixed.

Q: What will Web services look like in five years?


I think Web services will have a wide impact five years from now -- and not one that most people expect.

As we move to a world of mobile devices, it becomes increasingly appropriate that the information comes to us, instead of us having to browse for it. Browsing doesn't work well on mobile devices, but having information come to you does. So, consumers are going to expect every system out there to track what they need to know and send them the information when they need it. If I'm in Chicago, I'll get information on Chicago hotels.

That sort of thing is going to be huge. Once people start to take it for granted, it's going to be as big a change as e-mail. And Web services are going to be the mechanism by which information flows to mobile laptops and personal digital assistants (PDAs).

Q: What kind of challenges have to be overcome to get to this vision?


The biggest challenge now is almost an anti-challenge. The reason XML took off was because it was a revolution of simplicity over complexity. When I was driving this stuff at Microsoft, there were alternative languages that were extraordinarily complex, and almost no one understood them.

The big virtue of XML was that it was dumb: Anyone could get it, and everyone could use it. In the same way, the challenge now is to have Web services become something we take for granted. If it becomes more and more complex, that would slow things down.

Q: There are three Web-services standards that govern how programs look for each other and exchange information. Plus, there's XML, an integral part of this information exchange. Are there too many standards already?


Basic Web services are easy, and if the standards were quickly finished, there would be no problem. Only if the standards took forever to finish would there be a problem, and I don't expect that to happen.

Q: Are there any limitations on Web services today?


Moore's law [which postulates that the amount of computing power per unit of cost doubles every 18 months] has always changed what you can do in computing, so whatever limitations there are will change rapidly. With that caveat, Web services today are just fine for integrating software companywide -- there are virtually no cases where you can't get what you need.

Sometimes you have to scale up, to a cluster [of PCs], when you can't do it all on one computer. But in general, Web services work. They also work extremely well for business-to-business applications.

The one situation in which you want to use Web services judiciously, however, is when you start to move not 10 or 100 messages a second but up to 10,000 messages or more, approaching real-time delivery -- where the message always has to be there within the same number of milliseconds.

Take financial systems that do trade management. They not only generate tons of trades but also tons of messages about the trades. And the speed with which you execute -- the latency between when a message is sent and when it's delivered -- is very important.

Another case is any kind of real-time instrumentation, such as on oil-drilling rigs, which produce huge amounts of information very, very fast from monitors on the drill. Those are the sorts of job where Web services still aren't applicable. But it's very well understood that even without Moore's law, we can get there in the next five years.

Q: You've said that one of the virtues of Web services is that they're easy to implement. Can that cause security problems?


One of the concerns we get from some customers is they didn't realize just how easy it would be for outsiders [on the Net] to get access to their programs once they expose them as Web services. Customers have been startled by how many developers quickly took advantage of this, because it was so easy.

Q: How do corporations deal with Web services security?


It's not as big an issue as it sounds. Most Web services today support a security mechanism called SSL [secure sockets layer], which encrypts data that's transmitted over the Internet. Or you can buy products that act as a traffic cop, from companies like Blue Titan or Cofluent Software. With these, whenever one program tries to contact another, it goes through the traffic cop, which makes sure that you are who say you are and that you do what you are supposed to be doing.

Q: How will Web services change corporate hardware requirements?


Several years ago, I started a company called Crossgain, which was acquired by BEA in 2001. Crossgain was a bet on the principle of "utility," or service computing. [Under that principle, a corporation would buy a computer with six processors, but as long as it used only four, it would pay for only four.] I still believe in that idea profoundly.

But as soon as you say that anything you deliver is a service, it has to run robustly. Imagine if you went home and your electricity was out periodically –- you'd be very upset. With a utility, you expect utility-like performance. You expect it to run 24 hours a day, seven days a week. You also expect to always have enough [capacity] on tap.

That's going to drive a model of computing that has to have the ability to scale [to easily handle bigger tasks]. Before, to scale, you just bought more hardware. What you're going to start to see [with Web services] is that you'll be able to add hardware dynamically. This is just coming out of universities now.

Dynamic, on-demand hardware will probably take a few years. But when it arrives, Web services is really going to live up to its potential. Then, anyone will be able to sell any specialty that they have as an on-tap, as-much-as-you-want-to-drink utility.

    Before it's here, it's on the Bloomberg Terminal. LEARN MORE