Interview: IBM's software chief speaks out

Steve Mills gives his thoughts on Java, Web services, and Microsoft's .Net strategies

AS THE OVERSEER of IBM's $12 billion software business, a business that spans every major software market from mainframes to PCs, Senior Vice President and Group Executive Steve Mills must feel a little like that guy on the Ed Sullivan show trying to keep about 20 plates spinning at once. With one hand the 28-year IBM veteran must make sure the strategies against long-time rivals such as Microsoft, Oracle, and Sun are spinning in the right direction. And with the other he must direct a raft of emerging and very different Web-based technologies and all of their associated strategies and political wranglings that go on in any number of standards bodies and other institutions where political in-fighting rages.

Sometimes sounding much like the hard core technologist he is, and sometimes more like a politician carefully clarifying his position on the issues of the day, Mills recently sat down with InfoWorld's Editor In Chief Michael Vizard, Steve Gillmor, director of InfoWorld's Test Center, and Ed Scannell, editor at large, for a wide-ranging interview. Mills gave his thoughts on where he and IBM stand on such things as the technical and political ins and outs of Java, XML, Web services, peer-to-peer computing, Microsoft's .Net strategies, IBM's open-source Eclipse initiative, as well as on Web services standards organizations such as the W3C (World Wide Web Consortium) and the recently formed WSIO (Web Services Interoperability Organization).

InfoWorld: A couple of years ago it seemed like the evolution toward distributed computing would be driven primarily out of the Java space. But now it seems to be driven more by alliances and deals between companies like IBM, Microsoft, and BEA and then brought to some other standards body. What has changed about the process here and what's good about that?

Mills: Well we never thought it was going to be driven by Java. And when we jumped on the Java bandwagon in 1995, we saw Java as something very valuable for server-side development, programming, and interoperability. That was not the message Sun was delivering, but that was the interest that we had. We saw Java as a logical mechanism to replace the more complex C++ and CORBA-based implementations for system interoperability that preceded what's now emerged as J2EE. That's the way we saw Java. We've always seen CAD mark-up languages as being useful for high-level data descriptions and normalizing information. And we've been working on XML and its predecessor technologies for decades. We delivered WebSphere in 1998 before anyone was talking much about XML with native XML parsing capability because we knew this was going to be the technology that would become preferred for doing these high level descriptions.

InfoWorld: People talk to us about J2EE {Jave 2 Enterprise Edition] and its support for Web services. But it is unclear to us what really belongs in J2EE and what doesn't. Not just that, but what's the line between where J2EE is supposed to begin and end and where some of these other initiatives begin?

Mills: But they're really an apple and an orange. If you look at what Java is, it's pretty clear; it's low-level programming syntax. I write an application in Java and the application logic is written in Java. Nobody would write an application in XML. It doesn't make a lot of sense. You want to define data elements and interfaces in XML, it makes things interoperable by using XML. For example, if you're a bank and you need to exchange funds with other banks and do querying and all the things that banks do with each other like credit card activity, billing activity. Well then you and the member banks that you do this with have to agree to formats and structures that permit you to do this with each other. And you've been doing that kind of interactive interoperable banking before programmable computing came about. So you had ways in which you defined this stuff on paper. And then you digitized it and you were defining it in a computing sense.

InfoWorld: What I'm driving at is, there's a process today where application servers and J2EE environments, especially WebSphere, are supporting Web services through the additions that you're making. What seems to have everybody somewhat anxious is that the standard around J2EE 1.4 doesn't appear to be fully cooked. People are worried about going down a path of working with this stuff today, only to have to rip it out and tweak it later when the standard gets more fully baked.

Mills: If they understand the technology, they ought to be relatively unconcerned about that. XML, if you know what it looks like and how it works, it's this infinitely flexible high-level structure where I use a particular compliant syntax to annotate things and describe what they are. And through the interpretation of that annotation that I can map any piece of information to any other piece of information that is annotated using the same technique. So you're describing information, is all you're doing with it, whereas in Java, you're actually writing program logic. You use them for two different things. They complement each other just as all things in IT have complementary characteristics to them.

InfoWorld: So what you're saying is what J2EE adds in terms of Web services support in 1.4 could be relatively irrelevant?

Mills: Yes. That's exactly what I'm saying. The need for Java to keep evolving will continue. The emergence and the use of XML in so-called Web services doesn't deny Java in its continuing evolution. It doesn't deny creative ways in which these things can be combined together for the value that they deliver.

InfoWorld: Nor does it imply though that the Web services support needs to be actually bundled into J2EE, because it's kind of orthogonal.

Mills: They're different things. If we eliminated all the cute doublespeak, and we were talking about XML and C++, we wouldn't be having this discussion. You would say, well, C++ is all this, gorpy, low-level syntax, and manipulation stuff that's associated with writing programs, and XML is a high-level description language. But instead of calling it C++ and XML, we talk about Java and Web services, then we get lost. This is one of the problems with the IT industry is that it constantly revs names and terminologies in ways that create confusion. We didn't coin the term Web services, but we stuck with it. Sun named Java, "Java". If IBM had created Java, we probably would have called it C+.

InfoWorld: Well IBM created about 80 percent of J2EE.

Mills: I think there are informed customers who clearly do understand the differences between these two things. The commotion around Java is heavily fueled by Sun. And they're concerned one way or the other about whether they're being left out of something. But nobody has an advantage in the world of Web services. It's not owned by anybody. XML is universally accessible, all the syntactic mechanisms and expressions in XML are published. They are not owned by anybody. It's a true open standard in that sense. So Sun can be as big a participant in Web services as they choose to be.

InfoWorld: Where do Web services need to go from here? One of the things that keeps coming up is the sweet spot where IBM has spent a lot of time, namely the requirement for asynchronous capabilities around Web services. But it is not clear to us whether there's going to be a standard approach to that or whether it's just going to be everybody's individual product implementation. Do you have any thoughts on how that emerges?

Mills: What you're seeing evolve today is that the vendors and the customers come together to define the layout, create templates, formats, and then they agree to an accepted format to do that particular thing. And if it becomes required as a Web service, it gets labeled as a Web service. What those XML templates run on top of is a matter of what the vendors then deliver. So the Web service itself doesn't do anything until you transport it somewhere, until you parse it, until you deal with it at the various endpoints into which these Web services are implemented. So everybody has access to the standard, and so what the stuff rides on top of will be a matter of what quality of service, what platform, and what vendor you think you want to work with. So WebSphere provides transportation services and parsing and interpretive services for Web services. But it won't be the only piece of infrastructure that Web services ride on top of.

InfoWorld: So is there going to be a thin layer in the standard to connect all the different asynchronous messaging transports?

Mills: There will be, just as there are things like JTS {Java Transaction Service] and JMS [Java Messaging Server]. Or Java implemented interface standards for a common way to express transaction semantics or messaging semantics, just as there's JDBC [Java Database Connectivity], a common way to issue calls to databases. In the world of XML these types of system level interfaces will be instantiated in an XML structure that will get labeled in some fashion and be the standard way in which you do some of these things.

InfoWorld: Take for example the BEA Cajun initiative where there's a framework that encapsulates the mapping between Java classes and the XML that you're talking about, to provide loose coupled coarse-grained and asynchronous communications. Is there an analogy in the IBM WebSphere environment to that initiative?

Mills: There's a capability in our product to do that it is one of the native features that's in WebSphere. What happens in case of all technologies is the vendor level innovation typically is preceding the standardization. For example, before there was an agreed-to enterprise Java Beans architecture, there was a prototype created by IBM called [Arabica], that we took to Sun and through the Java community process that resulted in the Java Bean specification, which was later up-leveled to the Enterprise Java Bean specification. So the vendors play with these things and come up with ways to create interoperability, cause something to happen inside of their product, and then the standards process typically takes over after that and hopefully you reach an agreed-to approach to do this thing in a standard way.

InfoWorld: The way that W3C is set up now, do you think it can move fast enough to ratify some of the standards that need to be done quickly? Or does the W3C have to make some changes to the way it works?

Mills: Clearly we would like to see the W3C move faster. I would not characterize it as being particularly slow in the context of standards bodies. The more participation you have and the more vetting process that your bylaws call for, the longer these things tend to take. On the other hand, it's a way in which you achieve adequate airing of all the issues. It's a way in which you ensure that all the right information and interests are dealt with, and it produces a standard that hopefully is a result of compromise and everybody signs up for it.

InfoWorld: Is this something the WSIO will do?

Mills: You might misinterpret what I'm going to say here, so let me give you the caveat up front. I am pro standards bodies, I am pro open standards bodies, I am pro wide participation standards bodies, I am pro customer participation standards bodies. So do not misinterpret what I'm saying here as being a criticism of standards bodies. The beauty is you get a standard. The challenge is that it takes time. So how do you find ways to try to speed that up? That's what this WSIO thing is all about, is how to you create something interim, some final standards initiative, and then the vendor community comes together and reaches some agreements. Frankly, the participants in the WSIO would be companies that would be coming to the table to drive most of the evaluation and bring most of the intellectual capital to bear anyway. So can this speed up the process? That's what we're all trying to do. Having participated in this stuff now for decades, you sort of figure there's nothing perfect here. At one end of the spectrum, you have a vendor creating something independently and they're done. You go to the other end of the spectrum, and it's the wide participatory standards body that might take a year to get something out the door. So how do we shift to something in between a weekend and a year? It's the creation of an intermediate gearbox. And that's what we're trying to do here with this WSIO effort

InfoWorld: What role might bridge technologies play in terms of bridging J2EE and .Net for Web services?

Mills: I think things always emerge in the marketplace that end up being widely accepted because they're useful mechanisms that somebody creates. Whether or not they end up going through a standards body then is another question.

InfoWorld: If companies ascribe to the proposed Web services standards faithfully, maybe you will not need some bridge technologies? Some do debate however, that you will need the bridge technologies if you want deep integration.

1 2 3 Page 1
Page 1 of 3