Why Hugh Grant Picked SOAP Over XML-RPC: An Interview with Cape Clear's CTO (Part 2 of 2)
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Alex: Your products include two features called SOAPDirect and UDDIDirect. Can you elaborate on their features?
Hugh: The goals of those tools were to provide developers with an ease-of-use library. We built a lot of our initial clients and demos using things like Apache SOAP and the IBM SOAP toolkits. While they're effective, they're quite complex. You need to be a pretty good developer to use these things to their fullest, and we thought, "Hey, we've got all this mapping technology. Why don't we actually just roll that out as a client toolkit?" The goal of SOAPDirect is to re-create in Java what Microsoft has done with Visual Basic—basically, make it really trivial to write SOAP clients. You don't need to know what types are being used; you can just pass arbitrary Java objects and the toolkit will work out on-the-fly what the correct mapping is from those types into SOAP. [The Hello World application] can run through a couple of hundred lines of code, if you're using something like Apache, and our goal is to have it down to 10 lines of code if you're using SOAPDirect.
UDDIDirect does the same thing for UDDI. It's basically a specialization of our SOAPDirect API, with some ease-of-use wrappers around the UDDI specs, because UDDI is quite complex. A lot of developers aren't going to be that technical. Web services are going to be [deployed to] a much wider audience than your usual Java developer, and so we want to make it easy for those people to access the key services.
Alex: Your products currently work with stateless session beans, but let's assume I already have an application that has a combination of stateless session beans and stateful session beans, along with entity beans. How would the migration work?
Hugh: Customers who have done this typically use either a wrapper or a Factory pattern and basically create a level of indirection between their stateful code and the system. A stateless session bean looks up the Factory or has a direct connection through to the back-end object or a component, and that works pretty well. We're restricted to a stateless model because of the way SOAP works. People who directly support stateful session beans or entity beans are doing it in proprietary ways, and you don't have interoperability at that level; we believe it's better (in the Java domain) to just write a wrapper to give you that functionality.
Alex: One of the key selling points of your products is ease of use over the existing toolkit. Can you elaborate on why XML-RPC didn't catch on, and SOAP is so much more ubiquitous?
Hugh: XML-RPC has quite a following at an open-source level, but it was never really picked up by any of the vendors. What's driving SOAP is the fact that you've got IBM, Sun, Oracle, and Microsoft for the first time on the same platform, saying, "We'll support this standard." The value of SOAP is its ubiquity. The ease of use is really shared with any other XML approach, so what's driving SOAP is Visual Studio .NET, J2EE 1.4, Oracle's SOAP support.
Alex: Are there any inherent technical limitations of XML-RPC that made it inferior to SOAP, or too limiting, so that it didn't become ubiquitous? Why did vendors decide to standardize on SOAP?
Hugh: The SOAP specs are more detailed and XML-RPC is more lightweight and generic. People like the extra depth they find in the SOAP specifications, and the fact that it's being filled out to include specifically how [XML] schemas work and different bindings; in the future, we'll see asynchronous support. The vendors invested in developing the specification, whereas XML-RPC was the work of a couple of people in the open source community—very good work, but it just didn't have commercial backing.
Alex: The web services model has several pieces: creation, consumption, registration, and deployment. Your product helps on consumption, creation, and to some degree registration. What deployment features does Cape Connect provide, since the existing standards don't currently address this issue?
Hugh: When people deploy web services, they usually follow quite a complex model—maybe something like the EJB deployment descriptor model. We wanted to make it easier. With Cape Connect, everything is dynamic and based on [Java] reflection. If you want to deploy a web service, you just have to register the WSDL file with Cape Connect, and then it knows how to do [the mapping].
The goal is to make deployment as easy as development. It's just a pushbutton exercise: You point our tools at your components and they're deployed. There's nothing extra you have to do. Internally we'll be running on top of whatever platform you're using—CORBA platform, J2EE platform. Internally, things will be CORBA components or Beans or Java classes. What we do is basically put a wrapper around that to insulate the user from all the details of how that's deployed. We do the hard work, so the user gets to have a really simple experience deploying web services.