Future of Computing
2005-05-05
Web Services, XML and SOA - David Orchard
A Bottom-Up Success Story Dave Orchard Weblog - WebServices.Org: "Q: There's been some concern about performance issues with Web services. What's the BEA take on this?
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. XML beans 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 XML beans 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."
ZapThink :: Research - Services: Build, Buy, or Repurpose?
ZapThink :: Research - Services: Build, Buy, or Repurpose?: "However, one of the significant shifts in thinking that SOA introduces is the notion that business logic is not engrained in programming code, but rather in the declarative metadata that describes a Service and how it interacts with other Services. In essence, SOA advocates a movement away from code-centric development to configuration-centric composition."
