In a wide-ranging interview, Adam Bosworth, chief architect and senior vice president of BEA Systems Inc., San Jose, Calif., talked to eWEEK senior writer Darryl K. Taft last month and got candid about his plans for XML at BEA, competing with Microsoft, BEAs impact on making Java development easier and lots of other good stuff.
eWEEK: Simplicity in tools is an issue on everybodys mind today, particularly with BEA and your Workshop product. How much of an impact do you think youve had on making Java development easier?
BOSWORTH: Well, I think weve had a huge impact on making it easier, which is to say… Im going to make a very aggressive assertion. I would argue that there were really only about 500,000 people who could effectively use J2EE [Java 2 Enterprise Edition] before Workshop. There were obviously more people who could program in Java and there were obviously more people who could use JSPs [JavaServer Pages]. What Im saying is the people who could actually make use of J2EE to develop true enterprise computing, it was the systems programmer crowd. Thats who we were selling to. And I believe we truly have made it possible for the corporate developer, the applications developer to play in that and that means theres more like 5 million people. And whats more is because of the two-way views weve let them work collaboratively with the business user. Now the effect of that is measured in different ways. We just released the product not too long ago and I dont know yet what the impact will be in terms of what everyone does. I think its interesting that other products are now starting to try and repeat what weve already shipped.
eWEEK: Like Suns [Microsystems Inc.] Project Rave?
BOSWORTH: Like Suns Rave or what have you. And thats fine. I mean its very healthy for the ecology. Im very pleased to see people now asking how do we make it easy. That to me was the big failing of J2EE. It was very powerful and actually fairly clean. Mark Hapner [Sun distinguished engineer] did a very good job designing the core pieces. And Mark is probably the biggest fan youll find for what we did at BEA. Hes the architect of J2EE at Sun.
But I think the right question to start asking, and I think we asked it, was how do we make this successful to everyone else so they dont have to think like plumbers. So I think the impact is huge. But whether or not we get every applications developer to switch to it, thats just time and effort and marketing.
eWEEK: Well, are you as optimistic as Sun seems to be, where they talk about their Rave tool, now known as the Java Studio Creator, growing the number of Java developers to 10 million?
BOSWORTH: Yes, I am. I think there are only about 10 million programmers total, just to be clear. So when you say were growing it to 10 million I think youve just spoken about pretty much every programmer. Whereas I think there are about 100 million people who I think can use complex abstract tools—meaning build really complex spreadsheets, do Visio, use Access at all. That number I think is about an order of magnitude bigger. But I do think there are roughly 10 million people who can program. Some percentage of them are scripters and theyre not likely to want to use Java as is. And for that weve been working hard on this ECMAscript for X. But a big percentage of them, given a language that hides complexity, will use that language. And lest we forget, Javas biggest motivation when it started was keep it simple and stupid—no garbage collection, it hides complexity, its a simple language, it avoids multiple inheritance, which was a great thing to do. I think its great that Java started from that basis. I think the big difference between Java and C is that in fact you can bring it right into the application developer. And as a language its not a problem. The closest thing that makes it a problem is the string handling, but I think thats ok. So Im very optimistic there are going to be 10 million people. The time frame? I have no idea. Im very bad at predicting the future in terms of time frames. Im pretty good actually at predicting the future in terms of whats going to happen, not necessarily when.
eWEEK: With Microsoft and what theyre doing with Longhorn it seems their emphasis is to try to “disempower” the browser and move back into making Windows more of the center of everything. In your talk [at the XML 2003 show] you seemed to be advocating against this. Can you explain?
BOSWORTH: So I think about this a lot. And I do have some notes about XAML in my blog. But the most … Ive punted on it. There are some reasons the browser became successful and we all started doing this… I dont know if you know this but I built the browser for Microsoft at one point. I built IE [Internet Explorer] 4 and built the DHTML and built the team that built it. And when we were doing this we didnt fully understand these points. And one of the points was people use the browser as much because it was easy to use as almost anything else. In other words Id talk to customers and say we can add to the browser all these rich gestures. We can add expanding outlines and collapsing and right click and drag over and all that—all the stuff youre used to in a GUI. And without exception the customer would tell me please dont do that, because right now anyone can use the sites we deploy and so our training and support costs are minimal because its so self-evident what to do. And if you turn it into GUI we know what happens, the training and support costs become huge. So one of the big values of the browser is its limits.
Steve Jobs used to talk about wouldnt it be great if software was like a radio. And then one day it was like a radio and nobody noticed. And it was the browser. My mother who is 74 has no trouble browsing, even my father who I think of as a technophobe, can browse. The second advantage of the browser you know about is that theres no deployment. Thats a huge advantage. Because theres no deployment you dont have to bring all your peoples PCs in or upload them all heavy. Now softwares gotten better at being adaptive and self-modifying, but that cuts both ways. Im sick of applying my upgrades on Windows every night. And it makes me nervous that the software on my PC is constantly changing.
So I think what we want isnt a thick client, and I wasnt leading that way. But I think there will be some cases where theres a thick client. I think in general we still want to say an app is just something you point to with a URL. And you dont have to deploy it. And you can throw it out of memory at any time, and theres no code and no libraries and no interdependencies. All the great things about installation-free software that the browser gave us. And the other thing big thing of course is that if you make a change everybody sees the change. So how do I get my cake and eat it too? How can you have a model where you have a thin client just like we have today and yet it works well against the data model. And I think what you do is you have two things that you point at on the web. One thing you point at is the information and one you point at as the way you present it and interact with it. And then the browser is smarter and it knows how to cache. It already knows how to cache your pages and now it knows how to cache your information. And it knows how to do offline synch so you actually go offline and come back online and can synchronize. But other than that its still a browser. You have to know one thing once and thats your browser. Then you just point to the URL and you run them in the way that you do in the browser mall as opposed to .EXEs.
Now, Longhorn I think is conflicted about this. Bill [Gates, Microsoft chairman] has always wanted a thick client. Eric Rudder, in part is where he is because he promised Bill a thick client—and partly because hes brilliant and a great guy. Im a big fan of Eric Rudder, which probably sounds funny coming from someone from BEA. Eric and I have a lot of mutual respect for each other. But hes trying to live up to a vision that in my opinion is mostly not in the customers interests and that is a thick client. So I think the clients going to get thicker but will still basically be a thin-client paradigm. And I think that will be true because the customers, given the ease of use of the a radio, dont move away.
Let me give you one other example. Word processing. I used to use this command-oriented word processor called Volkswriter. And other people used Emacs. It had all these powerful commands you could type in. And along came the WYSIWYG word processors. They were cooler and they printed much better, but I lost half the power I had. I could no longer say search for everything that contains this and then when you find it modify this part to include this note—things I couldve said in the old command-oriented language. And no one ever went back. To this day word processors dont let you do that. Because it turned out there were 10 times as many people that needed the ease of use as needed the custom stuff.
Thats whats happening with apps. There are some people for some apps that need really custom UI because they use them everyday day in and day out and they need that kind of productivity of a custom tool and a custom toolbar. For most of us most of the time the browser works well enough, particularly if you do some of the tricks people are doing with the HTML. And the training costs are zero and thats huge. And the deployment costs are zero and thats huge. And I dont think anyone will ever accept that being taken away again.
eWEEK: So do you think anybody is going to do a standalone browser?
BOSWORTH: You mean a browser that does what I just said?
eWEEK: Well, yeah, but one not tied to a specific platform.
BOSWORTH: I dont think that youre going to see people trying to end run IE. That would be silly. But you can think of IE as a component within something. IE is very well designed to be a component. Look at AOL. AOL uses it as a component today. Some of the Outlook stuff uses it. InfoPath was actually built on top of IE as a component. So I think what you may see is people building stuff that uses IE as a component. So the rendering is still rendering. You use the browser as you do today, but the communication on the back end is richer. Thats what I think is likely to happen, but its hard to say. Youd have to ask whose going to do this. And the only way I see it happening is in the open source community.
eWEEK: How can BEA, which seems to be mostly known as an application server vendor, lead this kind of revolution?
BOSWORTH: Well, youre asking two questions in one. Im only equipped to answer one. One is a marketing question and the right people to ask that question of are Byron Sebastian and Tod Nielsen. Tod, as you probably know, has extensive marketing experience. And Byron is in my opinion one of the finest people in software today, and is thinking very hard about this problem. Thats not my expertise, which is why I shouldnt be allowed to be the CEO of a company. Ive been one but only because I had to.
The other question youre asking is technically how could we do it, which is a different question. Technically, I do think my approach is a little bit unique. I brought about 100 people into BEA who had done this.
eWEEK: From CrossGain?
BOSWORTH: Well, from all over. I bought a company called Westside after BEA bought me [CrossGain]. And Westside had many of the people that helped me build VB and Access. And many of the people that came in with CrossGain had worked for Borland at some point and had worked with me for years. I was asked at one point how can we build an IDE for the rest of us in 18 months when no one can build an IDE in 18 months. I said look the people who are doing this, this is their fifth generation. They built Quick C then they built Visual C. Then they built another and then they did it again. Then they went to CrossGain and built work and theyve been doing this over and over and learning as they go. So I think whats unique about us is we have two separate pieces of DNA in the organization.
We have the enterprise DNA that came out of the Tuxedo roots and the WebLogic roots that are massively scalable dont-fall-down roots, which honestly are not Microsofts roots. And then at the same time we now have the DNA of how do you make it mass market and how do you make it easy. And honestly Im pretty proud of what we did in the first place. I started building 8.1 in December of 2001. And 18 months later we shipped a product that really pretty profoundly started to change what you had to know to build a truly scalable, truly asynchronous platform that took advantage of the things you can do in J2EE. Are we done? No. Were not close to done.
But from a technical point of view I would argue that what makes us unique is that we bring these two pieces of DNA together. And the understanding of the corporate and the applications developer that weve got, it isnt just me. Thats the point. There are a hundred people like me that we got over all those years of handling and supporting these people. At the same time we bring together this enterprise expertise. And to me that knowledge… And the other thing is we stay focused. BEA is not trying to be a rich client company, BEA is not trying to be a games company, BEA is an enterprise on the server company.
The discussion that I had with Alfred when I joined, because we were looking at some acquisitions, was I said lets focus on what we really do well. Lets not do any acquisitions tat would take us off target.
So from my point of view thats what we did. We focused very well. And we bring these two very different cultures together very synergistically. So technically I actually think were putting our money where our mouth is. Were inventing at an amazing rate of speed on top of the Java community in a very synergistic way. Both through the JCP [Java Community Process] process or through the open source community as well with things like XML Beans.
And were working surprisingly well with IBM on some of this stuff, too, like the SDO [Service Data Objects specification] announcement.
eWEEK: How does that play into your mobility strategy?
BOSWORTH: That Im not ready to talk about yet.
eWEEK: OK, but the SDO [Service Data Objects] spec itself has some uses in the mobile world?
BOSWORTH: SDO is obviously useful plumbing for building a data model. Its not a data model per se, but its useful plumbing because it tells you how you could cache the information in general way.
What we found is there is often common interest between us [BEA and IBM] at the plumbing level. To my point of view you build the front end and you make sure the developer doesnt have to know about the plumbing. But you still need the plumbing. So there are places where we can work together, but we obviously compete in others.
eWEEK: OK, youre currently working on a project you said you wanted to demo at the XML show but didnt. Is it internal and strictly BEA or are you working with partners on it?
BOSWORTH: I always do both. One of the ways we compete with bigger guys at a technical level is we take advantage of the fact that we dont try and do everything and it gives us a lot of natural colleagues who are threatened by Microsoft or IBM. And so very naturally they tend to team up with us given any degree of civility on our part and any degree of a promise that we wont go in there space, because they dont get that from IBM or Microsoft. So pretty much everything that we do tends to involve some outside partners that normally our competitors couldnt get, because our competitors tend to compete with them.
eWEEK: You mentioned SyncML and you said you had plans for it or that it needed to be enhanced. Can you expand on that?
BOSWORTH: Well, again, thats a classic partner thing. Were starting to talk to Nokia and others about this. SyncML works very well if I want to use it to synchronize my contacts or my address book or my mail. Very well is relative, but its a standard. In general I believe standards are not designed to be pretty , theyre just there to enable stuff.
The thing it doesnt work so well for is when you have a cache where youre throwing stuff out that you need back. For example, I have a project and that project has a set of tasks that make up the project. And I have the project out here and I throw out some of the tasks. Meanwhile, some of the tasks that I did or didnt throw out have changed out in the real world and I want to synchronize. At that point, the normal SyncML assumes it knows exactly what was on my device and it just has to tell me about whats new. And it assumes it knows it because it has some version number and it knew what the world looked like as of that version number. And therefore all it has to know is what version number my device had and it can tell me whats new. That model doesnt work in the scenario I described because it doesnt know whats on my device because I threw stuff out. And because I threw stuff out it needs to get more information from my device to efficiently tell me what I needed to know. And I threw it out because I cant put the entire web on any device, so any architecture that I have has to be able to cache to an arbitrarily small size.
So thats where SyncML needs some work. I think its a highly doable thing to extend it.
eWEEK: Do you think we need a set of RSS spin-off specifications? Like Jeremy Allaire has proposed something called RSS Data…
BOSWORTH: I need to go talk to Jeremy about it. I was actually going to come out to Boston and do it last month and I got sidetracked.
I think that we need some way to describe an information model. Whether what Jeremys doing is right I dont know yet until I can talk to him and take a harder look. I think what we need is a generalization of RSS. But theres one thing thats not in RSS formally enough for me and thats this idea of links. RSS obviously does have the idea that there are resources, but…
So let me explain what I mean. I mean context links. For example, given the project I want the tasks. Now thats a link. Thats a link that has context. The context is the project, and I want a generalization of that. So that not only can I describe my data, I can describe how to traverse links in that context. And I need to see if Jeremy is doing that. If he is, great. Ive already talked to Kevin Lynch at Macromedia about working with him on this because it would be a natural thing to use behind Flash and Royale and what have you as well—as they move toward a model where some of the data is moved to a device.
Jeremy is a smart guy and I hope I can work together with him. It would double the IQ that I have to employ on it. He did it on ColdFusion a long time ago, which at the time was very innovative. I tried to buy it when I was at Microsoft, and Jeremy turned me down and later sold for a lot more money to Macromedia.
eWEEK: What do you think of Microsofts Indigo. Were you at the PDC where they unveiled it?
BOSWORTH: I wasnt at the PDC, but Im close friends with Brad Lovering, John Shewchuck, and Eric [Rudder] and so Im pretty aware of whats going on with Indigo.
I dont know what to think yet. I think thats the short answer. Theres always the desire to build cleaner plumbing when plumbings out there. And you can see the plusses and minuses and successes and shortcomings. Normally those desires fail. Lest we forget TCP/IP was supposed to fail. There was supposed to be this seven-level OSS stack that we were supposed to have for networking and in the end that didnt happen.
Microsoft had all these good reasons why TCP/IP wouldnt succeed until it did. If plumbing is ubiquitous and everybody uses it, it tends to over time settle down and not be displaceable. I would say that the Web services stuff is pretty ubiquitous and pretty widely used at this point. Indigo as far as I can tell is still a couple years away—if they tie it to Longhorn, which they seem to be doing; and if they tie it to WinFS, which they also seem to be doing. I dont even know how far that stuff is, but certainly lets say three years. Three years from now I wonder if anyone, even Microsoft, can replace plumbing at that level. As I already mentioned I couldnt with networking. Its not clear to me why theyll be able to do it with this. The complexity is the issue. And I think the industry needs to work very hard, take what weve got and not over-complexify. But its not clear to me that you sort of have to almost start from scratch, which is a little bit of an unfair statement about Indigo, but… Clearly, theyre saying lets not assume certain things that today we do list as part of Web services.
And the other thing is I havent yet seen what Ill call a sufficient focus on messaging. This is very basic to me. Any time I wire together a set of services I want to architect so that whether they are up or down it goes on working, whether theyre slow or fast it goes on working. I just want robustness in the system. And that says to me you want to send message whenever you can. Sometimes you cant. But much of the time thats not true. And as we move to a sync world even less of the time that will be true, because in the background… The reason this works so well [holds up a Blackberry] is because they synchronize my mail in the background. So when I look at my mail its right there. So I believe were going to move more and more towards an asynch and message-oriented world. And that should be a key focus of where Web services go. I havent seen anything I would call a key focus of Indigo. Can I enable it, yes. But I didnt see it as: this is what makes it different. Maybe you did. What I saw was leaner, meaner, straight on the sockets…