Simon Phipps will deliver the keynote at the O'Reilly Conference on Enterprise Java, on Wednesday, March 28, 2001, at the Westin Hotel in Santa Clara, California.
When we spoke to Simon Phipps last year, he was IBM's Chief XML and Java Evangelist. Since then, he's moved across the street to become Sun Microsystems' Chief Technology Evangelist. O'Reilly Network Editorial Director David Sims began the interview this year by asking him why he left IBM.
Simon Phipps: I moved because I'd spent five years or so talking about the visionary future. And really all of the visionary thinking was coming out of Sun. I had the opportunity to actually go and work with the people who were doing the imagining, rather than continuing to take things second-hand. So I moved over, and I was able to work with the sorts of people who are working on Java, who are working on XML, who are implementing XML within Java, the sort of people who are working on future technologies, like P2P technologies and wireless technologies. I'm much closer to the place where the water is coming to the surface.
Simon Phipps on:
David Sims: Visionary thinking may be hard to categorize, but what are the areas that you saw things happening in?
Phipps. Well one of the interesting facts that only gradually came to my attention was that Sun has got good relationships with the wireless industry as a whole. And in particular, J2ME is very widely accepted by the people producing devices, like cellphones, and the people producing equipment. It did strike me then, what may be some of the roadblocks that we see in the side of the computer industry that's about more traditional data processing, might be removed by the influence of this community that for so long has been an outsider to traditional data processing. And also, for so long, we've been talking about us converging with traditional data processing.
Sims: We've known that wireless would have to take what it could get from traditional computing, but you're suggesting the opposite is true, that traditional computing can learn from the lessons of porting things to wireless.
Phipps: I think so. While we haven't seen IPv6 coming into mainstream data processing -- and I don't know what the exact reasons are why it hasn't come into mainstream data processing, but I think they are quite largely to do with being perfect as the way we are, thank you. And the world of cellphones has so many devices in it that they're going straight to IPv6. My hunch is that IPv6 is going to bleed back into mainstream data processing as a result of its adoption in the wireless community. For example, I can see peer-to-peer computing being made the flavor of the day by the wireless community and working its way back into mainstream data processing. I can see web services being driven by mobile devices. So I can see some of the surges of energy that are going to bring about evolutionary steps in mainstream data processing could well come or be catalyzed by the wireless community.
Sims: What are you thinking about when you talk about peer-to-peer in wireless applications?
Phipps: I'm thinking that wireless devices are actually a lot smarter than people give them credit for. The average cellphone has maybe 10 DSPs [digital signal processors] in it. It's got processing power that would put the average data center to shame, just sitting in your hand, to do signal processing.
"The dividing line to a peer-to-peer solution isn't as rigid as people are painting it. There is a continuum between the transaction and peer-to-peer activity."
And once you have a uniform machine code platform on there, like J2ME, you've then got the potential to begin to run code in that device. And you can imagine being able to set up peer-to-peer sessions. For example, imagine you are looking for a cinema to go to; you want to go see a movie somewhere. You can imagine there being a peer-to-peer transaction activity between a particular cinema and your cellphone in order to purchase a seat in the cinema. The exchange of a piece of information entitling you to a seat, what you might think of as a ticket perhaps. Now you could think of that movement as a transaction, or you could think of that movement as a peer-to-peer activity. Or imagine groups of people being able to share information as they wander through an unfamiliar city, between mobile devices. You can imagine there being things that are about being able to communicate from device to device, possibly supported by a server somewhere, acting as a directory or a locator. But the dividing line to a peer-to-peer solution isn't as rigid as people are painting it, I don't think. There is a continuum between the transaction and the peer-to-peer activity.
Sims: It sounds similar to what Clay Shirky has called "decentralized enough," in reference to Napster. It's largely peer to peer with a centralized database of users, but it seems to work.
Phipps: Yes. We have this constant desire to try to departmentalize solutions here, when all the really clever stuff happens at the boundaries of the compartments, I think.
Sims: When do you expect that we'll start to see J2ME on more cellphones? I believe there was a trial with them on iMode phones earlier this year. Are you familiar with that?
"People who work with real atoms, rather than just bits, tend to be more cautious than us software people would like them to be."
Phipps: Yes. I think that that particular industry is, like a lot of engineering industries, actually cautious about what it does. When you are pure software, when you have a bug, you can fix it just by sending a new version down. When you're a piece of hardware, you fix it by doing a product recall. And, consequently, people who work with real atoms rather than just bits, tend to be more cautious than us software people would like them to be. The key here is not so much when the phones will be available, but when people will be providing services that exploit those features. Because, to be honest, there are already phones around that have Java capabilities. It's just that you don't know about it, because you can't access them as a developer. But the first places where we're going to see those will be this year. And we'll gradually see a spread of those capabilities. Now when we will see an open, unlocked, any developer-can-use-it space on some of these devices is less clear to me.
Sims: You had mentioned that Sun's looking at web services as an expansion area for Java. One of the things that's interesting about it is, the same web services could play out whether the client's a server, a client machine with a a JVM on it, or a cellphone with J2ME. Can you talk a bit about how Sun is looking at Web service.
Phipps: We've been talking about the idea of the service-driven network since about 1996. And the idea of accessing services across the web. The term "web services" is broad enough for lots of people to mean lots of different things by it. I think the way that we're looking at web services today is in terms of something a computer somewhere else does for you, with results communicated in XML.
Now we've just recently come around to the fifth birthday of our thinking about services on the Internet, and we feel that the time is ready to start talking about making web services smart. We've been thinking about adding context to web services. In one context a web service might be a facility on your PDA to provide you with directions to get from one place to another. Using that as a web service in today's world, you'd probably navigate around either in an application on the PDA or on a web site, find the directions facility, key in your current ZIP code and your destination ZIP code, get up a view, zoom it down so that your start and end points are visible, and then you'd have a met, and you'd be able to get directions as well.
We're envisioning a future where that process has added to it context in a standardized way. By context I mean things like your calendar (where is your next meeting?), probably the calendar in your computer at the office or in your PDA has got a ZIP code in it that would be able to tell you where to go next. Maybe that ZIP code is actually in the address book, so I have to look in the calendar and then in your address book. Your cellphone knows where you are. It could actually give coordinates to say where you are at the moment. Your bank account knows whether you can afford public transport or whether you have a car, or how you're going to get around the place, and can give input as to your preferences, and your ability to use different modes of transport. Maybe there are rules that your organization has about the means of transport available to you.
All of those are pieces of context that can be fed to the web service to allow it to make smart choices and pre-empt some of the grunt work that you would have to do to get started using the web service. So a smart web service for direction-finding would probably, when you clicked on the map button on your PDA, it would show you a map from where you are now to where your next meeting is. Or it would, if you pressed the airline reservation icon on your PDA, it would come up with the three flights to take to where you've got to be next, at fares that are approved by your company's corporate policy. Those are both smart web services: web services, but with added context.
Sims: You mentioned that these services and applications are going to have to deal with the context in standardized ways. We've been dealing with standards a little bit here because we've been part of the peer-to-peer working group that's getting started. It's been interesting looking at how a standards process gets started from the ground up when there's really just people and organizations, both profit and non-profit trying to figure out how to work together. Do you think that is the basis of standards? People figuring out how to work together?
Phipps: There's a whole school of philosophy that considers standards. My estimation of what a standard is is it's a vehicle for turning a technology into a marketplace. And of course that doesn't really rest well with developers and code-heads, because that idea of turning a technology into a marketplace sounds horribly commercial. But, if you weren't aiming at a commercial marketplace with multiple players, you wouldn't need standards. And the reason you need them is because you're turning technologies into marketplace opportunities.
Now, the way you got about standards has changed, certainly within the last 20 years that I've been working with them actively. I worked in the 80s with OSI standards, and the process for doing standards in those days involved identifying who the few experts were who knew about a topic, locking them in a smoke-filled room, and telling them they weren't getting food until a specification came out the door.
Sims: Which was usually a couple of years at least.
Phipps: Which took a rather long time so they were always wasted and thin when they came out.
Now the process for standardization that came about in the 90s was broader than that. The pace that people wanted to work was faster, the community involved was broader, and the connectedness that was involved in the solutions they were producing was greater. So I think we moved to a more consortium-based approach in the 1990s, and that was really the second generation of standards organizations, characterized by groups like IETF [Internet Engineering Task Force] or W3C [World Wide Web Consortium]. IETF in particular has the laudable characteristic that it asks for implementations. It seeks to encourage an iteration of: specify, interfaces, implement, re-specify based on experience.
Sims: It's looking for a reference implementation to base a standard on?
Phipps: Yes. But it's also looking for an interface specification to base on implementation on. The two things go hand in hand in IETF's world.
Now, I think we're coming to a third generation of standards. I think it's still young. Some of the communities involved are probably rather reluctant to be described as standards communities. I believe that the Linux community, for example, is a standards community. There are issues in those young organizations that need to be worked out, things like the ownership of intellectual property, the process by which the code pool gets turned into a release, and who has the authority to do it and how they got that authority.
"I think we're coming to a third generation of standards ... we'll see a number of groups coming about in the future that deal with these massively connected areas like smart web services, and that have to base themselves in a community rather than on the fiat of a group of businesses."
There are those sorts of issues to be worked through, but I think that the future we're moving into is so massively interconnected that nothing short of a whole community-based standards process is going to be effective.
So the standards bodies that are going to succeed from now on are the ones that are community based, rather than based in either expert groups or business consortia.
Sims: It does seem like a change facilitated by the Internet, where you can be surprised by input you get from people you hadn't thought to invite to the table.
Phipps: Absolutely. And I think that the whole experience is quite scary for a lot of business folk who are used to having closed communities. On the other hand, it wouldn't be good to run away with the idea that this is a complete free-for-all that is going on. In the end, if you want to have Linux, you need Linus Torvalds. In the end, if you're going to have Apache, then you need the Apache Foundation. And, there's always going to have to be some process and regulation involved. So I think that this whole idea of a third-generation standards process is going to have to find its feet, work out what's best. I think we'll see a number of standards groups coming about in the future that deal with these massively connected areas like smart web services and that have to base themselves in a community rather than on the fiat of a group of businesses.
Sims: It actually seems like the second and third generation have worked out on their own how to develop technologies under their own processes, but bridging the two -- which web services certainly seems to need -- seems like a tougher nut to crack. Each side is familiar with its own way of operating. Linux was able to develop without corporations because no one was paying attention, at least in the first five years. Now that things are being developed -- I'm thinking of peer-to-peer and web services -- where everybody from HP, Sun and IBM to the two guys in a garage startup have to agree; seems like having to teach two communities of old dogs new tricks, doesn't it?
Phipps: Absolutely. And I think there are going to be some burnt fingers. Things like conspiring devices won't come about unless we see the ability of those diverse communities to actually do real stuff. There's going to be a constant process of having to surrender vested interest. And I'm anticipating seeing over the next couple of years very big businesses having to change the way they operate in order to fit in with that new world.
Sims: Last question: What's your favorite new device or new application that you've either been toying with or that you're waiting to get your hands on?
Phipps: I think that the toy that I'm waiting for most that I haven't really seen yet is probably a Bluetooth earpiece. I look forward to a future where, instead of having a cellphone I have an earpiece which, when I'm in the office works with a desk set, when I'm in the car works with a cellular telephone that's built into the car, and when I'm walking around in the street works with something the size of a pager or a packet of peppermints that is my cellphone identity. I'm pretty keen to see that, because I think that will open up all sorts of new applications, as other devices begin to say, hey, he's got a headset. As my laptop begins to say, hey, he's got a headset, we can start listening to it. Now that there's a Bluetooth chipset out there, I believe we'll begin to see it in more products.
David Sims was the editorial director of the O'Reilly Network.
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.