In-Depth
Web Services Reflections: Q&A with Eric Newcomer
ADT's Jack Vaughan recently sat down with Iona's CTO Eric Newcomer to discuss SOAP, CORBA, and more.
Q: Some people say Web services are CORBA for
the Web. Is that a false analogy?
A: Well, I think it's true from the point of view of the architecture because Web services are primarily about providing descriptions of services and tying them together over a transport. And you have a service requester/service provider architecture that's very similar to CORBA at the high level. When you get down into the details, that's where things are different. Web services are based on XML and HTTP, which are Web technologies, so it's more of a marriage. Web services are not a direct descendant of CORBA, the way you might call CORBA a descendant of DCE or something like that, because there's this traceable stream of concepts and technology in the distributed computing environment up to CORBA. Web services represent a break because they're based on a markup language rather than a programming language, and it's a different way to accomplish the same thing using different technologies. So, a lot of the concepts are similar, but the technologies are very different.
Q: Will it look like CORBA by the time the
add-on standards groups are all through?
A: It could become overly complicated. I think it's virtuous that it's simple, easily implemented and it's a low-cost solution to a lot of integration problems. I think people want to take it in that direction, but that may not be the best direction to take it. A lot of people, and I think it's an easy trap to fall into, say 'What is Web services good for?,' 'What is SOAP good for?'. It helped bridge .NET and J2EE. That's in the biggest customer development environments. If you want to integrate those, you can do that. But when you look into it, it's a very small subset of those technologies that actually exist in Web services. And then, very quickly, people say, 'Well I'm comparing Web services to .NET and J2EE, and there's all this stuff that's missing, let's add it in,' without thinking about what it is we can really do with Web services today that's of value and useful.
Web services are not development technologies. You don't sit down and develop your custom application using Web services. What you want to do is interoperate and tie together existing applications. What you want to do is put an XML overlay on top of all your systems so that you can integrate them. And you want to do that in a more loosely coupled way than you would if you were developing an application in J2EE or .NET, or doing an order-entry system.
Q: In some camps people think of Web Services as
'Java and XML.'
A: It is natural because Java is one of the most popular languages, and the most popular language for using with Web services. We just have to remember that somebody on the other end of the connection that you're talking to might be using COBOL, PL1, PerlScript, PHP or any of a number of other languages that support Web services equally as well as Java. We don't want to constrain our thinking to an app server technology. It's a generic technology, the way that Web servers are, the way HTML is generic.
We are also saying that the architecture of Web services is different and distinct from the architecture of app servers. The app server architecture is based on a classic three-tier architecture, the purpose of which is to optimize the use of resources for a shared database. So with the app server architecture, you're trying to multiplex a lot of connections down to a shared database and make that much more efficient, which is a great architecture for that kind of purpose. But now, when you're talking about Web services, which are very loose-grained, large messages that are sent over wide-area networks across all kinds of disparate software systems, you want a different architecture. You want much more of a peer-to-peer architecture and you want a service-oriented architecture that's a little bit different from the way app servers are designed. So app servers are not really architected the right way to support Web services.
Second of all, there are a lot features in app servers designed around an architecture, the EJBs in particular, the entity beans and the object-relational mapping, that are designed to support the idea of multiplexing a lot of clients through a shared database, and you don't need those things for Web services. Web services is all about sharing XML data. You don't want to carry around the extra baggage of app servers that were designed for another purpose when you're working in Web services. You want to abstract that out and provide a fit-for-purpose product that has just enough in the runtime to handle the features and functions of Web services, which, as we've been talking about, is a lot less than what's in J2EE or .NET. We have the ability with our adaptive runtime to configure a runtime that's just the right size for Web services features and functionality.
Q: In terms of the .NET platform, how are you
supporting Web service bridges today and in days to come?
A: I guess it's not a big surprise that Microsoft would have its own flavor of SOAP and WSDL and discovery specifications. What we do is recognize the differences in Microsoft versions of those things in our Web services toolkits so that when we import a WSDL file from a .NET environment, we can generate the appropriate SOAP message to interact with .NET applications automatically. I think that's what most vendors do -- recognize that the .NET version of Web services is a little bit different, and you need to recognize that in your products. When you get a WSDL from a .NET environment, you can handle it.
Q: Now there's a way to do this in XML and in a
binary method to come?
A: Binary interoperability with .NET we already do through a COM-CORBA bridge. We'll be upgrading in the future so we can support things like bridging transactions and bridging security. We bridge transactions already from Unix to the mainframe; we know how to do it from Unix to Microsoft, and we want to do more complicated data type mappings and structurings and have better performance to be able to binary bridge. That's kind of a general statement for what we're doing with Web services as a company; we're going in the direction of the pure, standards-based product, and we're providing a product that fits more into what you might call the enterprise service-bus category, where it does some of the things faster, better and additional that aren't in the Web services standards but that people still need when they're interoperating. We give you a choice: Interoperate with .NET using standard Web services, or go through a faster binary protocol that might have some things that aren't in the standard but that you may need for your app.
Q: Where do CORBA customers stand on Web
services? A: I'll give you a good example. I had a chance to meet with the chief
architect at Credit Suisse, who's one of our major customers. They have
developed, over the last five years, a service-oriented architecture based on
CORBA. They have about 680 services running from the mainframe to the desktop,
and its all tied together using CORBA.
I talked with him about Web services, and he said, 'Well, if we hadn't gotten started with CORBA five years ago, I could see using Web services for the same thing -- to build our service-oriented architecture.' We think the value is in the architecture. We have the ability to do a service-oriented architecture because you can reuse your systems and tie them together more easily once you have a common way of accessing all your applications and describing them. He said that now that they have that working, they don't want to go in and invest again in the same kind of solution, but he saw Web services as being very applicable to external applications.
When they needed to go outside the bank and publish their services for external consumption, he saw a big role for Web services. And here again is something that highlights one of the differences between CORBA and Web services and maybe gives an example of the power of Web services and what's so important about them. They anticipate the emergence of standard financial transactions that every bank will have to support. I think of it like an ATM. You go up to any ATM in the world, and it has your basic transactions: your deposit, withdrawal and transfer, and they can do it across any number of banks. That means that the banks in that network have to adapt their systems to whatever that ATM is using for a protocol for an application environment.
And in the future, when you get to Internet banking and Web service-enabled banking, people will access those same kinds of functions through standard interfaces at the bank. Somebody will define for the industry the way in which people interact with banking services over the Internet, and that means that companies, like Credit Suisse, will have to have a way of transforming their internal applications into the external format that's published on the Web. That's where Web services excel.
For more XML news, go to ADT XML Page.