WebServices dot org

Making the Common Thing Easy – Part I

We live in a world where management is obsessed with the bottom line. So it’s not surprising that many CIOs’ favorite acronym after ROI is TCO. This is particularly true in organizations that don’t spend a lot on IT. Early adopters see IT as an “investment” in gaining a competitive advantage and often spend 12-15% of revenue on IT. But the rest of the world (the majority) spend 2-4% of their revenue on IT and often focus it on finding ways to reduce costs and improve operational efficiencies. Software developers in those “pragmatic” IT departments need to continually measure the TCO and keep it as low as possible at all times. And unfortunately, many believe that by adopting “open standards”, they will do just that. If only that were true . . .

When Standards Go Wrong

Sadly, I watch with horror that so many standards (or recommendations, or whatever they are called) actually increase the TCO for developers.

Take for instance, one of the most widely used W3C standards, the XML DOM. The two most common tasks that any programmer ever does when creating content with the DOM are:

1. Create a new element as a child of a reference element

2. Create a new attribute in a reference element

The people who gave us the W3C DOM did this in such a way that you must use several function calls to do each task. Each of these functions can return a NULL, which means, if you are writing production-quality code, you need to check for this condition. It turns out that in order to write robust code that has a hope of failing gracefully on an over-used, under-horse powered system, you need up to a dozen lines of code for each of these activities that you do. The more code you have to write, the greater the likelihood for errors to occur.

The people who framed this standard would have done the world a great service if they had defined a method that allowed you to create a new element and append it to, or insert it before a reference element, in one step. Another useful method would allow you to create a new attribute and set it to the named attribute map of a reference element. These would have increased (slightly) the complexity of the DOM processors, which would do the NULL pointer checks on behalf of the developer, but that cost would have been hugely offset by the gain in productivity of thousands of developers writing millions of line of DOM code.

Here is an example of a method that creates a new element as a child of a reference element:

static public Node appendElement
(
Node contextNode,
String elementName,
String textValue
)
{
Document doc;
Element  element;
Text  text;

// append element
if (contextNode.getNodeType() == Node.DOCUMENT_NODE)
{
doc = (Document)contextNode;
}
else
{
doc = contextNode.getOwnerDocument();
}

element = doc.createElement(elementName);
if (null == element)
{
return null;
}

if (textValue != null && textValue.length() > 0)
{
text = doc.createTextNode(textValue);
if (null == text)
{
return null;
}
element.appendChild(text);
}

contextNode.appendChild(element);

// return element
return (Node) element;
}

Of course, there are still cases where one would want to have the flexibility to create a “disconnected” element or attribute and move it around. You would have 2 ways to do the same thing, but I can assure you that most developers would avoid the “disconnected” approach unless they had a good reason to do so. Unfortunately, the “disconnected” approach is the only one available with the current DOM.

I have trouble understanding the thinking that goes on in these standards bodies. There seems to be a failure to understand the TCO issue or at least a failure to give it priority. Is it because they are technical purists who don’t identify with monetary issues? Is it some academic dislike for having two ways to do the same thing, or worse still, a love of complexity for complexity sake?

Let’s Have More Standards – Not!

Don’t get me wrong, I am the first to stand up and promote open standards that improve interoperability, productivity, and performance. But does anyone else think that there are just too many standards bodies and too many standards, not to mention all the “vendor consortiums”? It’s not easy for a software developer to:

• Figure out which set of standards apply to his projects

• From this set, decide which ones actually will bring value to his project and not cost more than the value they bring

• Further filter out which set has actual implementations that he can use in his lifetime, and that will interoperate with anything else out there

Of course, the assumption of any standards document is that if you’re reading it, you need it. They don’t always do a good job of explaining when and why you would want to use the standard in the first place.

As an example, look at Tim Bray’s commentary on WSDM, at:

http://www.tbray.org/ongoing/When/200x/2005/03/12/WSDM-Disapproval

We Need More Simplicity

Few have said it better than Adam Bosworth in his Nov 18, 2004 Web log which extols the virtues of the KISS philosophy, and reminds those leaders in technology that their intelligence should be used to accommodate really simple user and programmer models, not to build really complex ones.

And Tim Bray, Director of Web technologies at Sun Microsystems (and co-inventor of XML), had a similar take at the Applied XML Developers Conference in October 2004. Bray encouraged developers to create solutions based on the MPRDV (Minimum Progress Required to Declare Victory) approach and add functionality only when you have to, and based on real experience. I particularly enjoyed it when he said, "Committees going into rooms do not invent the future."

Not only do committees going into rooms not create the future, sometimes I think they can get in the way, especially if they go in there too soon, before anyone really knows what it is we need. The result is invariably a standard that defines a solution, looking for a problem to solve. When you finally go to do some real work, you find yourself trying to apply the standard, but it doesn’t necessarily fit what you are trying to do.

I like the MPRDV approach and have instinctively pursued it for most of my career. It fits my mantra. . .

A Simpler Web Services Stack

It’s time we applied KISS to Web services. For example, I don’t need to support PHP (PHP: Hypertext Preprocessor), JSPs(Java Server Pages), ASP (Active Server Pages) or any other specific tool in order to provide a Web services listener. Yet, many vendors who offer Web services products assume that you are going to take their (or someone else’s) massive, difficult to administer and secure, Web server and use it to accept very focused HTTP POST commands that contain a SOAP payload and pass that on to an application server or transaction processing engine. These Web servers do far too much, and expose far too large a security and administrative footprint. The cost of maintaining and securing them is too expensive for a Web services server, in my opinion.

The answer? Divide and conquer! You should have a server that does your corporate Web site, and a separate one for your B2B applications. If it is internal-only traffic, it shouldn’t be on your corporate Web server at all! The server for B2B traffic should provide focused services, and have a security model focused on Web services, not serving up files and scripts.

While you should be able to call into any application server that your enterprise might have, you should not require an application server to support Web services. Why are you forced to assume that all your legacy applications are written in EJB? Or .NET? Again, like a Web server, an application server is a large, complex component, and in all likelihood does way more than your Web services require.

How Do We Do This?

In order to simplify our complex world, there are a number of things that we need:

A Standards Roadmap

First of all, we need a roadmap to the standards that clearly identifies what standards are in a usable state, when and why they apply, and how to access them. This roadmap needs to be driven from a requirements perspective. Do you need to route the same document to multiple parties, and encrypt/protect different parts based on who processes it? Then you need WS-Security. Ideally a user could go down a checklist, matching it to their specific requirements, and see what will answer the need. The same checklist would allow the user to examine whether the standard was finished, how significant the vendor and user adoption has been, what price point the solutions reside in - the kind of information that tells you if you’re going down a valuable path, or a slippery slope of spending too much money and then finding yourself the only serious participant on the block.

Easy-to-use Abstractions for Developers

We also need to shield developers from the implementation details of the standards, while letting them gain the benefits of these standards, with the least lock-in to proprietary components. If you cannot see how your tool of choice is using Web services or XML standards under the covers, then you are probably abstracted “too far” from your solution, and will be locked into the vendor for ever. While there are times when you really need that low-level access to the technology, to do something that the vendor didn’t think of, if the tool expects you to do all the heavy lifting, you might as well not have a tool at all! You are looking for a product that does a delicate balancing act, giving you a strong boost where you need it, but letting you do tricky stuff where necessary.

A Web Services Stack for the Masses

When PCs first came out, they were the ultimate in composability. A vendor would not bat an eyelid at letting a novice buy a system without getting the ‘basics’ such as a hard drive, floppy, memory, keyboard mouse or monitor. It was up to the purchaser to be an expert, or have one at their side when they placed the order. Better vendors would help you out on this front, but many assumed you knew what you were doing and let you make some bad choices.

Today, you cannot buy a PC that does not have a basic level of functionality, typically comprising a motherboard, a video card, IDE controller, mouse port, and numerous other things. Beyond that, you really do want composability, but 99% of consumers who buy a computer really consider these features to be ”table stakes” today..

In the Web services world, too many products are still in the stage where PC’s were 20 years ago. Like PC manufacturers, they assume a level of sophistication that is out of step with all but the fortune 1000 early adopters. For the bulk of users who will want Web services, there is a basic set of functionality that they really need to have available, “out of the box”. Users should look for vendors that do most of the time-consuming grunt work for them but still allow the very sophisticated user to develop custom code themselves, if they wish.

Critical Mass

The standards balloon has reached critical mass. There are so many already (and more coming all the time), that there is no way you can implement them all, anyway. Some don’t work together; some overlap and some even conflict with each other. In some cases, you have competing standards from different sources. The ones from true standards bodies seem to rarely win these days because they just don’t get the support from the vendors who want standards that best exploit their technology.The ones that do get “endorsed” often require too much complexity for some of the most common tasks. As a result of this, the adopter loses!

I don’t really see this ending any time soon. It’s a bit like spam. We’d all like to get rid of it, but until we figure out how, we mitigate it with solutions that are incomplete but better than the flood of trash you’d get otherwise. Until such time as this problem rights itself, the answer for the typical user is to focus on their requirements, insist on standards bodies giving “references” for use of their standard (if they can’t do that, you don’t want to be a pioneer), and go for the least complex solution you can find that solves your business problem!