Interview with Hugh Grant, CTO of Cape Clear, Part 1
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Alex: Please explain what Cape Clear is.
Hugh: At Cape Clear, we're committed to web services. We think web services have the potential to be disruptive, and the benefit is going to be realized only if [this technology] is brought to a wide audience, so we're about ease of use. We look at the kind of real-world problems that people have to deal with regarding web services, and right now it's about integration. It's exposing your existing technology as web services so a wider audience can reach that technology over the web, whether that's the corporate web [intranet] or the Internet itself. We're making that integration seamless—basically providing tools that will automate the generation of WSDL files, mapping technologies—whatever you need to get your legacy systems onto the web, the legacy systems being EJBs, CORBA components, or just plain Java classes.
In parallel with that kind of integration technology, we've been working on a product we call Cape Studio, which is our toolset for developing web service applications. One of the things people have to deal with is mapping incompatible XML formats. A lot of people haven't used SOAP, but have used things like XML-RPC [Extensible Markup Language/Remote Procedure Calls] or FPML [Financial Products Markup Language], various financial formats, or whatever vertical format has been standardized for their industry. They'd like to use SOAP, and, since it's all XML, the natural thing to do is use XSLT to do this mapping. However, XLST turns out to be quite hard to use in practice, so we've developed a set of graphical tools to enable people to generate these mappings automatically; people who aren't XML experts can actually sit down and work out how to map the data formats used in different parts of their organizations. We think that's key to getting wider adoption, because there's a lot of stuff out there already that needs to be integrated if web services are to be successful.
Alex: Describe the profile of your ideal customer.
Hugh: Typically, our customers are already users of some distributed object technology such as CORBA or EJB. A growing number of customers are really just Java users who have built existing Java systems and want to expose components of those as web services, so we're typically involved with people who aren't coming from a complete green-field environment. They're looking to integrate existing systems, or maybe systems from other vendors. In the future, [we want to] build on our ease of use and provide tools for less-technical developers and for business analysts or corporate developers who will be looking at tools for web service assembly and composition. That will take time because, clearly, until there are a lot of web services out there to assemble, there's a limited need for these tools. We believe strongly that web services will become pervasive, and this kind of web services design center is going to be key in the future.
Alex: Your tool includes an optimized SAX parser and an optimized SOAP parser. Are there performance concerns that customers should be aware of with the standard SOAP or SAX processor?
Hugh: Anybody using SOAP or XML is [going to be affected by] the overhead of processing parsing. Because SOAP is based on XML schemas for its datatypes, it depends on the complexity of your data. When designing the data for sending over SOAP, [you should avoid extensive nesting]. If you can do a transformation to convert from a highly nested and complex internal type to the raw information you need on the web, that can actually improve your performance. But, in general, parsing technology and the XSLT processing technology is improving dramatically and very quickly. It won't be an issue for very long.
Alex: Your product uses a SAX parser, which can't modify the XML documents. What happens if the user needs this functionality?
Hugh: That's where we have our interceptor architecture, based on the standard interceptor pattern, which allows people to do two different types of modification. At XML level, they can run XSL transformers automatically. This is the most common form because it's simpler, it's easier to integrate, it's easier to deploy. If you have existing XML data formats you want to map into SOAP, or you want to modify a SOAP message and convert it from one form to another, you might as well just use XSLT. On the other hand, once we've parsed it, we have an internal representation in Java that people can plug into, so you can actually access the datatypes in a parsed form. If you're taking that data and making a call, say, to an Oracle database, it makes more sense to do it that way. You don't have to get involved in XML parsing.
Alex: Your ideal customer is someone who has already adopted a technology such as CORBA. Let's assume that I'm already a customer of Iona, IBM, or BEA. What additional functionality do your products provide?
Hugh: It comes down to ease of use at the core. These other vendors are not pure SOAP or web service vendors. They're providing a bridge from their technologies into the world of web services, so they're more heavily API-focused. Using their technology will typically involve writing some code—maybe writing some marshalling and unmarshalling classes. We're focused on just generating everything, so we use Java reflection to process whatever components you have (or maybe parsing CORBA IDL files), and we generate all the code and all the mapping for you. You don't need high-end developers to do this work. Developers just run their components through our tools and then generate everything they need to run as a web service.
End of Part 1. Part 2 of this interview will appear at InformIT next week.