IBM Ups the Enterprise Ante (Continued)
Web Services, Microsoft, and J2EE
Q: One thing you haven't mentioned yet in terms of integration is Web services. How does that play into the integration space?
Swainson: Web services was developed in the context of B2B, where you have an exchange or a hub and you didn't know what was going to be on the other end of the wire. Around that time, XML was emerging and people were starting to realize that we could use XML as a way of describing the data and even the semantics associated with applications. So you saw things like WSDL, SOAP, and UDDI. And that was really the origin of Web services.
Two things happened from there. First, the bloom went off the rose in terms of B2B exchanges, and people realized that Web services could be used for a lot of other processes, too, including processes inside the enterprise. They could serve as a generalized mechanism for describing things with metadata and building closer linkages between them. So Web services technology has evolved into both a connection architecture and a description architecture for how things can be connected.
There's a model-view separation going on where we'll see Web services used for external communications between firms, and we'll see them used at a modeling level to describe internal communications within firms. That's important because you might not want to parse XML all the time inside a transaction-processing system. But it's useful for describing what the interfaces and services look like for the purpose of application development, and then you end up compiling down to lower-level protocols.
So we see Web services as valuable and useful—but we need to continue to build out the technology. It's not finished yet. We have lots of customers who are using it the way it is, but security, transactions, and reliable messaging need to be added to make it more universally acceptable.
Q: As those things get added, do you see Web services displacing any of the other integration technologies we spoke about?
Swainson: Perhaps they displace CORBA IDL, but there's a role for all of these things. Web services technology represents the only complete implementation-nonspecific environment that sits on top of literally everything else. So as a meta-architecture for describing how things work, it's got great value. As I said, when you build the systems, you might want to compile out Web services to gain the performance. So, do you replace RMI over IIOP with SOAP? Not bloody likely in a transaction-processing system. I think you'll see the full protocol used ubiquitously in B2B environments, and Web services used as a meta-language for describing the stuff as people build business processes behind the firewall. So, I don't think it replaces things; I think it allows you to describe how things best work together.
Q: How do Web services play in cross-platform integration and interoperability?
Swainson: Web services clearly help in terms of the cross-architecture integration task, particularly between the Microsoft world and the J2EE world. One piece of strong feedback was that customers needed a way of making their .NET environments work with their WebSphere environments. Web services provide a useful way of effecting those transactional connections so that you can have business systems built on Microsoft technology interoperate with business systems built on IBM technology or industry-standard technology. This becomes useful as a method of tying together a heterogeneous environment, which is the norm in enterprises.
Q: You were recently quoted in the New York Times about "dancing with the devil" in relation to Microsoft. For Microsoft, working with you on Web services has to do with gaining access to the data center where IBM is strong. But how do Web services open up Microsoft's markets to you?
Swainson: Well, it's about opening up the client. We can't view the Microsoft world as some strange beast that lives off in another dimension; we have to view it as part of the entire enterprise-systems construct. Web services provide an excellent mechanism for us to do that because they now give us the ability to reach out and touch those clients as though they were first-class members of the enterprise architecture. Web services give Microsoft access to the enterprise and allow us to tie together client desktops into a broader enterprise architecture. Then we can compete on who has the better value proposition in terms of an end-to-end enterprise architecture.
Q: Is it fair to say that IBM has pursued its Web services strategy outside the context of your application server and WebSphere strategy?
Swainson: No. Web services are implementation-independent, but the technology is not useful if it isn't implemented somewhere. What we've done as the standard gets developed is to ship it as a toolkit—typically through our alphaWorks developer site. Then we instantiate it in the next release of the WebSphere product, typically six to 12 months later.
One thing that's confusing about Web services is that people tend to separate the notion of implementation from interface. But at some point you have to deal with the underlying platform's quality of service. This is one of the reasons that the Web-services-on-WebSphere strategy, we think, has such enormous appeal, because it allows people to integrate virtually anything, but then when it comes time to build something that needs to be robust and secure and reliable, they can build it in that environment and still surface interfaces to anything else. So, they get the best of both worlds. My colleagues at Microsoft tend to gloss over the second part of this because they don't want you to focus on the fact that you end up building applications on Windows. I don't think you would want to build an online banking system in Windows.
Q: In that context, IBM has long been a major backer of the J2EE platform. How would you describe your commitment to the platform, your leadership in the community, and your relationship with the other players?
Swainson: As I've said many times, we are pleased at what the community has been able to accomplish. Java has been and continues to be a tremendous boon to the industry. We're enormously committed and enormously invested in it. As for our relationship with Sun, the Java Community Process seems to be a more democratic process since the big blow-up in 2000. We still advocate that it become a truly open process and open standard. We think the industry as a whole would benefit from that—Sun would, too. But we're certainly satisfied that we're making progress in the evolution of Java.
Now, having said that, I will tell you that a systems view involves more than just how to build the business logic. Business logic is incredibly important and you wouldn't have a system without it, but there are other things that are, to a large extent, independent of that. In our view of the world, for example, Web services needs to be independent of Java and not tightly defined by the Java programming language. In part, that's because you have all these legacy systems written in C, COBOL, and other languages that need to have their interfaces expressed in Java, and you need to talk to the Microsoft world, which is never going to be in Java. So, it's clear to me that some separation of concerns here must continue, and as important as Java is, it's not the whole answer. It's a necessary and important part of the puzzle.
Q: Is that why IBM has pursued the development of Web services standards outside the context of the Java process?
Swainson: Absolutely. It has never been clear to us why you would define a Web service in the context of a programming language. In the CORBA days, IDL was never defined in the context of programming languages. What you need is a good connection between the artifacts that you build in Java and Web services. If you look at our tools, you'll see a tight connection; you could literally build an EJB and automatically pop up the WSDL interface to it as you're building the entity. So, we have tightly integrated these things, and yet we're not dependent on Java syntax to create a Web service. And that's the piece where we think you would cross over the line and not be useful. There's been some technical argument about that, and not all of our partners in Java completely share that view. But I strongly believe that the rapid uptake of Web services has been partly a result of their universal appeal.
Back to top
|