Proprietary UDDI

The UDDI standard was initially misconceived, then neglected, and now it's on the verge of fragmenting into multiple implementations with limited interoperability. Often overlooked as something of an irrelevance, UDDI may end up becoming the vital missing link in web services standardization, undermining advances made elsewhere in ensuring interoperability between vendor implementations of SOAP, WSDL and the WS-* family of standards.

On the day that the guardians of the UDDI Business Registry (UBR) released beta implementations of the upcoming UDDI V3.0 specification, Line56 ran an interesting article about how UDDI is shaping up in live deployments. For early adopter E2open, UDDI is an essential tool for co-ordinating its constantly-shifting supply-chain universe: "One of the biggest reasons for the SOA is change management for inter-company business processes," E2open's VP of solution engineering Rob Barrett tells Line56. "Deploy an enterprise solution and you control your own destiny, but working with partners is much more challenging." UDDI provides a mechanism for offering alternatives, migrations and upgrades without breaking existing applications or workflows.

But UDDI doesn't do that 'out of the box', warns AMR analyst Eric Austvold: "... see what E2open is doing: They say, let's cut all the crap, put a framework around it, take out the ambiguities and made it easier to understand. But in that sense the challenge is that it moves away from being an open standard to one that is proprietary." In a separate quote, Stencil Group's Brent Sleeper seems to imply that UDDI.org is actually encouraging this kind of mix-and-match approach: "They said, 'Use us for part of the registry lookup but we'll interact with other protocols that are gaining adoption.'"

The article ends with E2open's Barrett predicting an assortment of private, semi-private and public registries that will somehow be "attuned," while pouring cold water on the notion of a universal public registry like the UBR: "We have not seen two companies interact with one another in the same exact way to date. With that in mind you have to have a flexible solution that allows you to manage the different process deviations that every business relationship has."

If the attunement predicted by Barrett is to come about, it will be up to the Web Services Interoperability organization (WS-I) to make it happen. WS-I last week released its first Basic Profile, which provides guidance on how to implement the various core web services standards so that they work with each other. Some valuable insight into how they work this out comes from a SearchWebServices article published this week.

Achieving interoperability basically seems to be a matter of deciding which bits of the standards to leave out and how to use the rest. For example, use XML Schema and not SOAP encoding ("We just carved out that whole section of the SOAP spec and said, 'Let's not go there,'" says one of the committee members). As for WSDL, "there were 'a lot of creative interpretations' by vendors." What's more, completing this task for the entire web services stack will take a minimum of ten years, they predict. In the meantime, vendors are free to implement functions outside the WS-I approved profile, "'but when you do, you're on your own' in terms of interoperability with other products."

So where does this leave interoperability of UDDI V3.0 implementations? For the moment, in a backwater. With few live deployments of UDDI, there's little immediate pressure to tackle those big interoperability challenges that will surface once enterprises start extending their web services implementations outside the firewall into complex B2B environments. But by that time, as we noted when covering UDDI in a Loosely Coupled feature article earlier this year, they will already have deployed the various implementations that vendors are building into this year's crop of web services tools and application platforms. Overlooked and unloved today, will UDDI one day wreak its revenge when the ticking timebomb of its non-interoperability finally wins our attention?
posted by Phil Wainewright 4:19 AM (GMT) | comments | link

Say what you mean

Why are we programmed to use meaningless flags? Last night, I was working on the member database of a voluntary organization I belong to. As with all such organizations, some members take the lead, others are very willing to help out, and some give a hand from time to time. The rest pay their subs and you rarely ever see them. The membership secretary had started color-coding members according to which category they fell into, but had lost her work on saving the Excel spreadsheet in CSV format (to keep it portable, we save the raw database as a comma-delimited CSV file).

"The trick is to add a new field and use it as a flag," I told her.
"Oh, you mean 1, 2, 3?" she said.
"Yes, or pink, yellow and green, since you were using those colors in the spreadsheet," I replied.
After some more thought, I said: "Maybe active, willing and helpful would make more sense. Computer technology's moved on — we don't have to save on memory these days. Why not make the flags say what they mean?"

As I strolled home later on, I started wondering how we'd managed to get to a point where it's commonplace knowledge that, if you want to add some extra information to a computer database, you deliberately pick a completely meaningless token?

It's all about performance, the purists will say. Using whole words instead of a single number or token adds extra bits that'll slow you down each time you search the database. What they forget is that the raw database performance is just one small part of the whole picture. Shaving a few milliseconds off the query response time isn't going be much help if the user's forgotten what "2" means, or if you have to add some application logic to translate it into something meaningful.

The trouble is, we human beings are hooked on symbols. We like puzzles. Whereas saying precisely what we mean is hard work, and not much fun. Our normal mode of conversation with each other is to blurt out the first words that come into our head and resolve any ambiguities as they arise. We're naturally programmed to pick any convenient symbol (as I did when I initially suggested "pink, yellow and green") and then pin down its meaning later on.

In the context of building a database, our natural inclination is to pick meaningless codes because we feel that's what we're supposed to do when building a database. Instead, we should be more disciplined, and think ahead to the context the database will be used in. We should think about the business context, not the technology context.

CBDI made a similar point recently in an analysis that compared Amazon's web services API to salesforce.com's sForce API:

• "If you look at AmazonWebServices WSDL you find a complete definition of the relevant parts of the Amazon business model. Services are named and organized as meaningful capabilities, that you and I would find useful such as AuthorRequest, AuthorSearchRequest, ArtistSearchRequest and so on ..."


• "In contrast if I look at Salesforce.com, what I see is an existing API has been opened up ... It appears that Amazon has actually thought about the services from the demand side, Salesforce has only thought about the services from the supply side — based on the functionality and structure of their legacy systems and databases."

Or, as Phil Windley memorably summed up, "Amazon.com's offering is 'service oriented' and salesforce.com's offering is merely lipstick on a pig."

Creating a meaningful set of service descriptions means doing some hard work thinking ahead to how the resource is actually going to be used, but it eliminates a lot of needless extra effort later on. Of course, there's still going to be plenty of scope for misunderstanding, but starting out by trying to define what you mean will cut out at least one layer of ambiguity.
posted by Phil Wainewright 8:42 AM (GMT) | comments | link

No way to treat a customer

Sterling Ball is the kind of customer who's an asset to any vendor. But he's had it with Microsoft. Three years ago, his company was raided by the Business Software Alliance, and then publicly humiliated, for inadvertently using unlicensed Microsoft software. Last week, he was a star speaker at the LinuxWorld trade show, telling how his company now thrives after jettisoning Microsoft and standardizing on open-source alternatives.

"I said, 'I don't care if we have to buy 10,000 abacuses,'" he recalls in an interview yesterday on CNET News.com. "We won't do business with someone who treats us poorly."

Ball's company is Ernie Ball, a world-class manufacturer of premium guitar strings, based in San Luis Obispo in southern California. He's a fair man who gives credit where it's due — even to Microsoft: "I couldn't have built my business without Microsoft, so I thank them," he says. This is the kind of customer whose word-of-mouth is a valuable asset to any vendor that delivers good products and reasonable customer care. But Microsoft and the BSA have squandered that opportunity. Instead, his story presents a litany of customer dissatisfaction that will strike a chord with every business person who has dealings with the mainstream software industry:

• Nuisance upgrades: "Each time something like (Windows) XP comes along, I save even more money because I don't have to buy new equipment to run the software."


• Functionality stuffing: "If you put a bunch of stuff on people's desktops they don't need to do their job, chances are they're going to use it ... The idea that if you have 2,000 terminals they all have to have a Web browser, that's crazy. It just creates distractions."


• Rapid obsolescence: "You've got Windows 98 not being supported, NT not being supported, OS/2 not being supported ..."


• Support overhead: "I can find out how many calls my guys have made to Red Hat, but I'm pretty sure the answer is none or close to it ... It just doesn't crash as much as Windows. And I don't have to buy new computers every time they come out with a new release and abandon the old one."


• Out of touch: "Microsoft is a growing business with $49 billion in the bank. What do they care about me? If they cared about me, they wouldn't have approached me the way they did in the first place."

All of this behavior is characteristic of a company in the midst of what business writer Geoffrey Moore describes as "the tornado". When customers are clamoring for your products, you don't have to pause to provide much in the way of support or customer service. You can even get away with suing them for non-compliance with your arbitrary and overpriced licensing terms.

But as Moore points out, one day the tornado stops and you end up on Main Street. The transition from undisputed 100-pound gorilla to brand-conscious, user-friendly market leader is a tricky one, and not every business gets it right. Main Street is there for Microsoft and the rest of the traditional software industry to lose, and one of the key vulnerabilities is the mistrust customers feel around software licensing and upgrade policies. If other vendors can add attractive branding and bundling to the open-source licensing model of Linux and related products, they'll be well placed to exploit that vulnerability. Already, Microsoft and the BSA have lost a key battle for customer hearts and minds on Main Street in San Luis Obispo.

PS: Apologies for the brief hiaitus in postings here since last week. I was doing a temporary office move over the weekend and have taken a few days longer than expected to get back up to speed. All's back to normal now.
posted by Phil Wainewright 3:47 AM (GMT) | comments | link