by David Orchard
This article is a reprint of a Q & A session held at www.webservices.org.
David Orchard works in the CTO office on the standards team and represents BEA in the W3C and other committees. Within the W3C, he represents BEA on the WSDL 2.0 Working Group and WS-Addressing and W3C Advisory Committees. Outside the W3C, he participates in a variety of core messaging specifications, including WS-Eventing, WS-ReliableMessaging, and WS-MetadataExchange.
I work in the CTO office on the standards team. I represent BEA in the W3C and other committees. Within the W3C, I represent BEA on the WSDL 2.0 Working Group and WS-Addressing and W3C Advisory Committees. Outside of the W3C, I participate in a variety of core messaging specifications, including WS-Eventing, WS-ReliableMessaging, and WS-MetadataExchange.
We are spending a fair amount of time working on WS-Addressing, which has gone to the W3C for standardization. It's a core web services infrastructure piece, and other specifications are dependent upon it. We are also big believers in WS-ReliableMessaging, as well as WS-Security, a core set of enterprise messaging specifications. We're working to get them in good shape with a stable specification, interoperability, availability on royalty-free terms, and descriptions of those specifications through WS-Policy.
We're trying to get to a software development and deployment model in which services are built and deployed and are easy to describe, and for developers and deployers to mix and match these facilities together in a composable manner. One of the main reasons why people are interested in standards is investment protection. They want to make sure that if they build a system using something like WS-ReliableMessaging, they are going to be able to talk to other people using WS-ReliableMessaging. The whole point of standards is so that they can choose from a variety of toolkits and vendor platforms and still be guaranteed interoperability.
I think the complexity issue is overblown. There have been a fair amount of naysayers on the web services specifications for some time. In comparison to other architectures, web services is not as complicated as some people are making it out to be. For example, look at the average web site. The Web is not nearly as simple as some people think. There's going to be HTTP, TCP/IP, SSL, cookies, CSSs, multiple versions of HTML, potentially mobile device support, internationalizations, potentially multiple languages, password authentication, maybe XML, and Dynamic HTML with the use of DOM. There's also templates and a whole bunch of graphics and graphics formats that are involved in deploying a fairly run-of-the-mill web site. Yet, you don't hear the naysayers saying that the Web is too complicated.
Compare WS-Addressing to HTTP, which is a very large and heavy specification. WS-Addressing covers two basic areas: 1) how you identify services, and 2) how you pass headers around. HTTP has many more options than WS-Addressing: cache control, transfer codlings, an authentication protocol, a description exchange protocol, use of an options header, built-in extensibility, and targeting of intermediaries. The web services specifications split these features into a large number of very finely focused specifications.
We could have written a "WS-Everything" spec and put everything in there the way HTTP does. There's a gazillion different optional pieces in HTTP, and it doesn't differentiate between whether some things are required or not required. We could have done that, and maybe that would have been more palatable to some people. But we wanted to ensure web services is composable, with the specifications split into fine-grained, small, specific areas.
Through a bottom-up approach. Look at some recent examples of successful architectures. TCP/IP, DNS, and the Web itself are examples of where bottom-up architectures have been very successful. They addressed very low-level needs. IP helped identify computers on the network to send messages. The very first version of HTML was very simple. There were no images or forms, just text documents. These approaches were successful because they focused on very small problem areas and showed concrete value. We applied this bottom-up approach to web services, introducing things such as, "how do we send a message?" or "how do we format a message such that we can add in extensibility hooks later on?"
I have spent a fair amount of time with the WSDL 2.0 Working Group, and there are a large number of improvements that are in WSDL 2.0 compared to WSDL 1.1. WSDL 2.0 makes it much easier to describe services. There are things like interface inheritance, where you can define an interface and then reuse that definition in another interface. One of the problems with WSDL 1.1 is you don't have interface reuse; you have to cut and paste if you want to deploy an operation across multiple interfaces. Also, the SOAP binding for WSDL 2.0 is much simpler, and it's easier to write bindings than with WSDL 1.1. The HTTP and XML binding in WSDL 2.0 also has been improved.
There is no question there is a bit of controversy about the use of features and properties in WSDL 2.0 compared to WS-Policy. If you look at the WSDL 2.0 Last Call documents, you'll see that some folks objected to features and properties because of overlap with WS-Policy. There are also others who say that the features and properties of WSDL 2.0 actually don't go far enough, that it needs more of the things that are currently roughly in the scope of WS-Policy.
I don't think the features and properties in WSDL 2.0 will be deprecated in favor of WS-Policy. Maybe WS-Policy will end up moving to the W3C in a short timeframe and deploy one technology in WSDL 2.0 and rationalize that with WS-Policy. Maybe there will be a way of rationalizing the two in a layered manner so that you deploy WSDL 2.0 features and properties and then make use of that with WS-Policy. I'm not sure what's going to happen, but I agree that it is a bit confusing that there are these separate extensibility models.
Extensions are a double-edged sword. They can lead to a lack of interoperability, because one person's extension might conflict with another. But the extensibility model made things like web technology successful. When HTML was first deployed, it had an extensibility model built in that enabled third parties to do extensions, and those extensions gained support. HTML 1.0 did not have the image tag but has it today because of HTML's extensibility model. Yes, it can hurt interoperability. But if we have a core specification that covers foundational needs, and we allow the extensibility model on the top, then we can actually have an incredible breadth of investment and research and development. Eventually, some extensions are going to win and survive and perhaps get adopted into the standard itself. In a bottom-up architecture, we don't preclude people from doing extensions; we don't have this model where the BPEL committee knows all and is the almighty overseer. We allow third parties to do extensions because there's a whole host of innovation that can happen.
BEA has been incredibly active in the process orchestration area. We've been an active author and participant on BPEL. We're committed to BPEL and working on it from both a standard development and a product perspective. We have people whose fulltime jobs are working on BPEL standards, and we are involved in almost every issue that comes up. We implement BPEL in our products. We've also led in integrating BPEL with Java, and we're incredibly excited about that.
There's network performance and there's computing performance, and both are affected by web services. There are a variety of things that we've been working on to address this. For computing performance, we offer a number of innovations that increase performance in developing and deploying XML componentry. We were the spec lead for the Java pull parser, so you can asynchronously pull parts of a message out. XMLBeans is another example of an excellent performance technique that is available. Instead of taking an entire message, and converting it all to Java for a binding as each message is received, a client can simply use XMLBeans to pull out the parts of the message that it needs.
For network performance, one of the things that we struggle with is the trade-off between interoperability and performance. Those are two diametrically opposed goals. For each application deployed, there is an optimal network size available for encoding that message as a binary protocol. The problem is that a binary protocol probably wouldn't work for somebody else's application. XML is the exact opposite of that binary, highly optimized performance network protocol. What we got with XML, for better or for worse, is a language that guarantees interoperability but at the expense of optimization. XML is a heavyweight in terms of size and encoding size. We've come up with a binary format we call Token Stream. We've also worked with Microsoft to support the transmission of SOAP messages with binary attachments like images. But we're taking a cautious approach when it comes to some of the XML optimizations.
Premature optimization of software or network architectures is something we're careful to avoid. I've been an architect on a number of projects in the past, and one of the things I've found is that by optimizing early on, we didn't optimize for the right interactions. We want to make sure that we do optimization right for web services and messages and find out where the problems are. It may turn out, for example, that introducing better XML parsers or messaging architectures may take care of half the problems of XML and web services performance. It would be foolish, then, to introduce two or three different new binary formats for XML to solve that problem, because we would lose a lot of interoperability. For that reason, we believe in a bit of a go-slow approach. Interoperability is the most important priority. If we have two or three new formats, we're never going to get there.
Document literal formats are another performance area we're working on. Document literal involves exchanging coarse-grained documents. Instead of exchanging names and addresses, for example, you exchange a purchase order. Our software supports both fine-grained and large-grained interactions from a message perspective, but we advocate coarse-grained interactions for better performance.
Another way to achieve high performance systems is through an asynchronous architecture. In a synchronous architecture, when the application sends a message, it ends up waiting for a response, which could potentially be unbounded amounts of time. An asynchronous architecture can lead to very high performance. We have championed the use and deployment of asynchronous architectures and web services. That's why we're involved in WS-Addressing and WS-Eventing, which use asynchronous messaging. But we need to educate people that asynchronous, coarse-grained, loosely coupled messages are the right way to go to deploy high-performance web services.
SOA is incredibly important to BEA and one of the main reasons why I work here. SOA is all about loosely coupled computing, which means we build and deploy services and can flexibly change those services. Everything we do is around enabling SOA or loosely coupled computing. That includes our efforts around integration, such as Liquid Computing. We're working to make it easier to develop and deploy services, to integrate with services, and to consume other peoples' services. We work heavily on standards because they facilitate the ease and ability to plug new components and change the implementations of SOAs. We're making large investments in our tools to make them easier for developers to use and deploy. An example is our Project Beehive, which consists of XMLBeans and is a flexible way of talking to XML components from Java. Project Beehive includes Java web services and Java page flows, which make it easier and faster for customers to build, deploy, manage, and consume web services applications. You can see this across the BEA product line. Everything we do is around enabling easier customer access to services and development and deployment of services in a loosely coupled and flexible manner. We want to continue to lower the bar for customers to get involved in building and deploying these services.
David Orchard is a technical director in BEA Systems' CTO Office, focusing on Web services standards.