Java creator James Gosling, a vice-president and fellow at Sun Microsystems Inc., shared his views on Web services with Computerworld senior editor Carol Sliwa during last week’s JavaOne conference. This is the second part of that interview.
Q: XML-based Web services are being much hyped at the moment. Are you buying into that? Do you think they’ll catch on?
A: Well, I would say an emphatic yes and a quizzical no. An emphatic yes on Web services are wonderful. But in a strong sense, Sun’s been building systems that do Web services, network services from the very beginning. We’ve got things like network file system, all the named servers and even all the networking protocols that people have been using over the years. They’re all about building services. And certainly the concept of building services on and around the Web and the network is really all that the network is about.
Then there’s the issue of this particular [instance] of building services on the network, which is around the SOAP [Simple Object Access Protocol] protocol. SOAP has some advantages. In many ways it’s far behind some of the protocols that exist already today, things like CORBA [Common Object Request Broker Architecture] and RMI [Remote Method Invocation]. And at some level, it’s just another network protocol. It’s another way to ship messages back and forth between machines.
And you know, to my mind, the technology piece is kind of a red herring because the important thing about the Web services push these days is not so much a particular protocol … it’s more an attitude shift for Web site developers. Somebody once characterized XML as HTML for Silicon-based life forms. I forget where I heard that line, but I mean, in the pre-Web days, if you were building a service that was on the Web, it was always a machine-to-machine service, whether it was a mail service or a name look-up service or whatever. And when the Web happened, that tended to be based on creating pages that were really intended to be turned into a human-readable image on the screen.
And so people were building services on the network whose only way to access them was through these pages that were designed to be humanly read. So you take something like the Travelocity reservation system. That is a service on the Web, but it’s designed really to be accessible to humans, and it’s designed that way through the fact that all the interactions are through HTML to get some place. And people have built programmatic interfaces to things like that, but it’s very difficult — trying to extract the information out of HTML when most of what HTML is about is sort of drawing pretty pictures on the screen. There’s one little piece of information like, “Yes, your order has been confirmed,”…. But you’ve got this whole page with ads and things flashing back at you, and you’ve got to sort of scrape the screen and find the information you want out of it … It’s really painful.
Really the interesting thing for me about the sort of Web services push and hype is it’s sort of saying to Web site developers: “Gee maybe you might want to actually have two ways in — one that’s easy for programs to get at and one that’s easy for humans.”
Q: Sun has been accused of lagging in its support for Web services. Do you have an explanation for that?
A: Well, I think the lag was more perception, was more a marketing campaign than reality. As near as I can tell, if you stack up the facilities available in J2EE [Java 2 Enterprise Edition] in the marketplace, it’s way ahead of [Microsoft’s] .Net and always has been. Certainly, Microsoft had a way of doing XML process-to-process communication before Sun shipped one. Whether that’s actually important or not, one could argue. We’ve been shipping one for awhile.
And also some of this is a matter of odd spin doctoring. One of the things that we hear a lot is people saying we don’t support XML because it’s not native in J2EE. And it’s like, well yes. If you look at the J2EE 1.3 spec, it doesn’t say you must have XML. But XML has been available as a drop-in plug-in for a very long time. I mean, all of your original XML parsers were all written in Java, and in fact, Microsoft was somewhat late to the game in XML. And those XML parsers, given the way that plug-in modularity works in Java, could drop into any enterprise app, and they have been dropping them into enterprise apps for a long time.
I mean, this document archive app that I wrote nearly two years ago uses XML for a bunch of the data storage. I got those APIs from somewhere. And so there’s a difference between XML being available and XML being required on all implementations as a built-in piece. So it’s been available for the longest time. It just hasn’t been a required component of the base platform.
In sort of an interesting twist, in JDK [Java Development Kit] 1.4 — which [shipped] a month and a half ago but has actually been available in one form or another for close to a year — it has built into it all of the XML APIs, and the J2EE spec layers on top of the standard edition spec. So XML may not be in the 1.3 spec directly, but it is indirectly because XML is actually in the underlying platform.
Q: Few are building Web services right now, so how much does it matter?
A: One of the sort of tragedies for us is that there is a real distinction between meeting our customers’ needs and dealing with the press. So one of the reactions we get from a lot of customers is sort of like, “What’s this Web services thing?” They list all these things you can do with Web services, but we’ve been doing that for years. What’s the big deal?
Q: Microsoft got an interoperability story from Web services.
A: But there have been some really good interoperability solutions available to them. I mean, they could have just done CORBA, for instance. And one of the sad twists of fate is the DCOM [Distributed Component Object Model] spec came out after the CORBA spec, and DCOM is excruciatingly similar to CORBA.
Q: I’ve heard complaints that both are cumbersome to use. Aren’t they?
A: Yeah. They’re both kind of clumsy. I can’t really speak to DCOM, but in the CORBA case, a lot of that clumsiness comes from [the fact that] they’re trying to solve some really hard problems. And one of the hard problems that they were trying to do was the sort of language-to-language, sort of platform interoperability thing. …
That sort of necessitates quite an amazing pile of complexity, and actually some of the people who were involved in the CORBA design, at the end of that experience, kind of went, “This language-to-language thing really added a lot of complexity.” And they said, “Well, what would happen if we did the design all over again but didn’t try to solve the language-to-language problem?” And they ended up with something that was much simpler. And that’s what RMI — this other networking thing that’s available in Java — [does].
