X
Business

Could application servers be overkill?

The way Cape Clear CEO Annrai O'Toole tells it, app server vendors like IBM, BEA, Oracle and Microsoft are trying to sell you the Brooklyn Bridge. He says XML-based services don't require full blown app servers. Oracle vice president John Magee says O’Too
Written by David Berlind, Inactive

If you believe Cape Clear Software Inc. chairman and CEO Annrai O'Toole, the major Web services vendors peddling their respective application servers-- IBM (WebSphere), BEA (WebLogic), Oracle (9iAS), and Microsoft (.Net). - are trying to sell you a bill of goods.

"The truth," said O'Toole, "is that if you want to take some new or legacy code and turn it into an XML-based service that talks to another XML-based service [aka: a services oriented architecture or SOA], then you don't need a full-blown application server like all these vendors are saying you need."

That's right. O'Toole thinks we're heading back down the path of complexity that Web services, and the application servers that supposedly power them, were supposed to eliminate in the first place. The result, according to O'Toole, is an absurd amount of aggravation and expense that could be easily avoided if only IT managers and developers decide to make the document, rather than the application server, the center of their attention.

O'Toole doesn't necessarily mean "document" in the literal sense. An advocate of Web services and services oriented architectures, O'Toole said that putting an XML interface on any digital entity --- be it a document, a Java component with business logic, some data, or even a mainframe terminal session --- basically gives that entity a document metaphor.

"The document metaphor is very exciting," said O'Toole. "It will have a profound effect on the way people think about documents and collaboration." The problem, according to the CEO of the Ireland-based software company, is that the application server providers are trying to convince everyone that a service oriented architecture isn't complete until it can handle the sort of complex messaging and choreography tasks that are characteristic of the older, monolithic transaction-oriented, database-driven systems. If we buy into all that complexity to make an SOA work, O'Toole says, the cost of Web services implementation will be disproportionate to 99 percent of the collaborations waiting to be "developed."

To some extent, the document-centricity of which O'Toole speaks sounds much like Microsoft's pitch for XDocs. The difference, however, is that the document mentality applies to everything -- not merely to Microsoft Office. But converting static digital entities into services that can talk to each other still requires wrapping those entities in a service layer that can send, receive, and advertise itself on a network. Enter Cape Clear.

Instead of using a full-blown application server, Cape Clear takes a more stripped-down approach. O'Toole says Cape Clear's namesake solution employs the open source based Jetty, the development of which is maintained by Mort Bay Consulting. With little more than some HTTP serving and Java servlet technology, and using Cape Clear's development tools (Cape Clear Studio), O'Toole claims, developers can have documents (again, metaphorically speaking) talking to each other in a matter of hours or days, instead of weeks or months.

Cape Clear can take any existing applications or entities, even ones based on Cobol or CICS, and turn them into Web services. In the case of mainframe applications, Cape Clear can wrap a 3270 terminal session, but a third-party terminal emulator is needed first. Once you have a document representation of those applications and entities, Cape Clear uses XSLT to integrate that "document" with data coming or going from or to other XML sources and Web services.


Reader Resources
Web services
ZDNet White Papers

I asked O'Toole if he expected Cape Clear's customers to proceed blindly with developing Web services that are devoid of any notion of orchestration or transactional state. O'Toole claimed that complicated protocols like the Business Process Execution Language for Web services (BPEL4WS) or the Web services Choreography Interface (WSCI) are extra baggage and that any functionality that those specifications are designed to handle is easily covered by something found in virtually every system: JavaScript (also known as ECMAScript).

The idea of maintaining workflow and transactional integrity with JavaScript seemed to me to suggest a giant step backward from the proverbial new world of Web services programming. In the world of business process management, designing complex business routines and workflows is supposed to be a simple drag-and-drop process accessible to mortals like business managers and analysts. The oft-hailed benefits of this paradigm include the reduced amount time it takes to design a new business interaction as well as the reduced need for intervention from software developers. Referring to high-level drag and drop-like programming tools like these as "stickman" products, O'Toole said the idea is a pipe dream.

"I've seen it work for simple interactions," he said, "but in the real world, where something has to be choreographed, this sort of programming simply won't do. You're going to need good programmers, and JavaScript can handle just about anything beyond the basic functionality that's provided by the Simple Object Access Protocol (SOAP) and the Web Services Description Language (WSDL)."

Is O'Toole on to something? Oracle 9iAS product marketing vice president John Magee doesn't think so. Magee acknowledged that not everything that could be wrapped in a services layer requires the enhanced funcitionality found in application servers like Oracle 9iAS. But, he adds, every company has some business logic that must be developed in a traditional language like Java or C#.

"Some developers are going to develop new applications, and when they do that, they'll need tools, fault tolerance, load balancing, and security," said Magee. Cape Clear's claims, he continues, "remind me of the early days of XML where people were saying that you're not going to need traditional servers anymore and that they'll be replaced by XML servers. The reality is that XML has to be baked into all the other technologies that are out there. The idea that there isn't going to be any business logic is fallacious."

I asked Magee what he thought about O'Toole's claim that any need for business logic can be handled with JavaScript. "It's highly unlikely," he said, "that any developers are going to toss out their existing development tools."

But Magee's biggest criticism of Cape Clear concerned the cost issue. With Cape Clear's cost of $10,000 per CPU, O'Toole claimed that customers will spend 10 percent of what they'd spend with one of the big application server providers. Magee's response? "Well, compare that to what we announced today. Instead of spending $10,000 per CPU for Cape Clear, you can spend $5,000 per CPU with us and get Oracle 9iAS, which includes full J2EE 1.3 support, support for clustering, the TopLink object relational persistence framework, and five licenses for our Oracle 9i Jdeveloper integrated development environment."

Another caveat: Cape Clear 4 isn't all standard. In the process of wrapping other applications and data in a Java-based service layer, the solution also wraps them in a proprietary Web service management interface accessible by a central console that maintains a view of an organization's entire Web services farm. Proprietary as it may be, it's 100 percent XML-based and the interface is published so others can access it.

What do you think? Is Annrai O'Toole on to something? Are the big application server vendors feeding us a line by telling us we need their big bad and bloated application servers? Share your thoughts with your fellow readers by using ZDNet's TalkBack below, or write to me at david.berlind@cnet.com.

Editorial standards