RPC won't wash with SOAP

Using RPC (remote procedure call) to link web services is one of the things that "could actually kill Web services adoption," writes Gordon Van Huizen, even though it's what many developers are doing today: "RPC-style Web services are quite easy to develop and very well supported by today's Web services tools ... Unfortunately, RPC-style Web services are fundamentally flawed as an integration approach."

The correct use of SOAP is to expose "document-based Web services, also known as 'messaging style' Web services," he explains, proceeding to list three important reasons why this approach is superior. The article is a useful primer on why RPC should be avoided — something I've always felt was the case, without being able to succinctly explain why (until now).

Gordon, it must be said, can always be counted on to bang the drum for web services messaging, as he is VP of product management for Java messaging vendor Sonic Software. His article goes on to argue for a robust infrastructure to underpin web services, which of course is also something that someone in his position would say, wouldn't he? But the fact that he has a vested interest in saying these things, doesn't invalidate the message.

A useful complement to Gordon's column is an interview with XML pioneer Dave Hollander, coincidentally also published yesterday on ZDNet. It's a helpful introduction to concepts like XML Schema and Namespaces, and why they're important. Here are two excerpts that I found illuminating:

• "Whether it's documents or B2B, to me the biggest issue turns out to be a transformation problem ... In order to do a transformation [for example] from "rue" to "strasse," I have to understand the fundamental transformation that this is a street, and whether it's a street or highway or road needs to be differentiated. In order to make meaningful transformations, you have to understand the semantics of the information."


• "One of the Web's guiding principles is partial understanding. If I get a message I don't completely understand, I still deal with it. In business, or commerce, if [you] don't understand the whole message ... you return it until we have an understanding ... The question is: Are web services going to act more like a commerce transaction, or is there no presumption of how things are set up ahead of time and you do your best with how the information is presented? For those who think about it in terms of commerce, schemas are the way of making that contact. Send me this information and I will respond with another information set."

posted by Phil Wainewright 1:52 AM (GMT) | comments | link

Security breeds complacency

Participating in a big, digital network creates opportunities and threats for all of us. Opportunities to publish our data, ideas and artworks in a way that multiplies their value; and threats that others will use our digital property in unintended or unauthorized ways. In yet another thoughtful essay, Ray Ozzie examines attitudes to control of shared information, and the inadequacy of most PC security measures: "As a designer and vendor, controls — real and illusionary, discretionary and nondiscretionary — are a tough issue ... At Groove ... we've made huge investments in trying to build complacency-immune security into the product."

Ray's essay makes clear that digital rights management (DRM) is an issue for all of us, not just as consumers of the output of big media, but also as publishers of our own digital assets. When I send an email, should I be able to control whether the recipient can forward it elsewhere or copy-and-paste its contents into a separate document? Our sense of natural justice tells us that certain emails (to our family lawyer, for example) should be subject to such controls. But while there may be some protection in law, there is in practice no protection on our PCs.

Nor will any technology system ever give us total security. In a previous posting, Ray cited a marvellous interview in the Atlantic Monthly with computer security expert Bruce Schneier. "If you think technology can solve your security problems," says Schneier, "then you don't understand the problems and you don't understand the technology." The whole article merits careful reading, but it's worth highlighting one of the key points that comes out of it:

All security systems eventually miscarry. But when this happens to the good ones, they stretch and sag before breaking, each component failure leaving the whole as unaffected as possible. Engineers call such failure-tolerant systems "ductile." ... Secrecy ... is a prime cause of brittleness ... Conversely, openness provides ductility."

The implication is that effective security systems are distributed (ie they rely on many small, autonomous components) and they minimize their reliance on secrecy (ie they reveal so much information that it overwhelms any attempt to break the system). I think that implies that Phil Becker is right in asserting that digital identity will play a key role in effective DRM.

But that brings us back to Ray's message about complacency. To complete the circle, we have to make sure users understand the limitations of security systems, otherwise they will become too complacent about safeguarding their digital identity, and then we'd be back to square one. The objective should not be to build complacency-immune products, but to nurture complacency-immune users — people who, to quote the title of former Intel CEO Andy Grove's autobiography, recognize that Only The Paranoid Survive.

posted by Phil Wainewright 2:13 AM (GMT) | comments | link

Reaching out to users

The point of web services is to connect people. Connecting computers happens to be an essential intermediate step, but it's not the final objective. The way that all the enormous potential of web services will be realized is by opening up and automating connections between people, enabling them to share knowledge, collaborate on projects and do business with one another.

This presents us with something of a challenge, since technologists are not that good at connecting with people. They build great infrastructure, and then expect the rest of us to get on with it. They don't recognize what a world of difference there is between supporting a capability and making it accessible.

Dave Winer described the size of that gulf earlier this month when commenting on moves to mandate the purchase of open source software by the state of California:

"They're out of their minds. Open source needs commercial developers to finish the job they start. Open source is very good for infrastructure, very bad for sweating the user interface details. People have to be paid real hard cold cash to work for users at that level. No one volunteers for that kind of work, and rightly so, because it's pretty thankless stuff, and explains why most open source stuff is so unusable. It's real work to get stuff usable. Lots of looping, trial and error."

All that work "sweating the user interface details" adds absolutely nothing to the capability of the software, it simply makes the existing capabilities accessible to users — users who are quite capable of figuring out how to program the functions themselves, if only they could be bothered, as Dan Bricklin noted in a great essay on the topic last week, Why Johnny can't program:

"This is not to say that many people can't get immersed in systems that require such understanding. They do in many parts of their lives. For example, lawyers and tax accountants routinely work with such complexity in their contracts and planning. Doctors work with an untold number of variables. Someone planning a big party has to work out the food, matching paper goods, favors, invitation list, entertainment, etc. Yet, all of these people rarely program computers in addition. It's just that people who aren't professional or hobbyist programmers usually don't want to get so immersed in something that is infrequently done and not part of the rest of their lives."

No wonder this is thankless work. As far as your peers in the programming world are concerned, you're not inventing anything new. And you're doing it so users can get on with stuff that's more important in their own lives, like writing contracts and party planning. Now you can understand why this is a job people only do for money. Dan again, this time writing Amy Wohl in the email exchange that prompted him to write his essay: "There is a reason programmers are well paid. Not everybody can or will do it. Programming is a very error-prone business. Most systems are very intolerant of errors (typos included) and most people don't know how to debug nor have the patience to do it."

Dan's article concludes with a useful hierarchy of programming accessibility, starting off with raw programming languages at the bottom of the scale, all the way up to spreadsheet-like systems, followed by forms and dialog boxes, and finally direct visual manipulation (eg drop-and-drag) at the top. Users will will trade off a certain amount of accessibility in return for greater flexibility or power (for example, going to a spreadsheet metaphor if they need more choices than they're offered in a form-driven system). But all users — even programmers — will adopt the more convenient methods at the top of the hierarchy, so long as they allow them to do what they need to do.

So while some programmers get on with the glamorous work of building the standards, platforms and infrastructure of web services, others are quietly perfoming the hard, heroic slog of sweating the user interface. Their work will have its reward in the end, because convenience is something people will pay for. It deserves recognition too, because the web services grid is only as powerful as the number of nodes that can productively connect to it. Once the infrastructure is in place, the next great challenge will be to make all that connectivity and automation effortlessly accessible to the great mass of users.
posted by Phil Wainewright 4:04 AM (GMT) | comments | link

BPM convergence beckons

BPMI.org has welcomed IBM and Microsoft's new business process management specifications in a position paper (PDF, 55k) published late last week. The positive response augurs well for a convergence on broadly-accepted BPM standards. When IBM, Microsoft and BEA jointly announced BPEL4WS last week along with two supporting standards, the potential for conflict with BPMI.org's own family of specifications loomed large.

Four main points emerge from the single-page position paper:

• It emphasizes the common roots and similar model shared by the new BPEL4WS (Business Process Execution Language for Web Services) specification and BPMI.org's own BPML (Business Process Management Language), "therefore opening the door to a convergence of standards in the BPM industry around a common model shared by leading organizations."


• It notes that BPML has certain features that BPEL4WS currently lacks: "Beyond these areas of commonality, BPML supports the modeling of real-world business processes through its unique support for advanced semantics such as nested processes and complex compensated transactions."


• The organization has other royalty-free specifications under development too, it adds: "BPMI.org is not only interested in the execution side of business processes ... but also their design by business analysts through the development of the Business Process Modeling Notation (BPMN), as well as their deployment, control, and optimization, through the development of the Business Process Query Language (BPQL)."


• It ends with a plug for WSCI (Web Services Choreography Interface), the specification announced in June by BEA, Sun and BPMI.org co-founder Intalio: "By offering 'out-of-the-box' interoperability across [BPML and BPEL4WS] as well as ebXML BPSS and WfMC's XPDL, WSCI has greatly contributed to the consolidation of a standard BPM stack," the paper concludes.

Despite the welcoming tone of the paper, its contents expose several potential bones of contention that will need to be resolved before achieving convergence. Of the two supporting specifications announced last week alongside BPEL4WS, the BPMI.org paper appears to be supportive of WS-Transaction, but makes no mention of WS-Coordination, which overlaps with WSCI, its own preferred alternative. (For a detailed executive overview of all three of the new specifications, see James Snell's write-up on IBM's developerWorks site).

The reference to royalty-free could also raise a red flag to IBM and Microsoft, who have shown themselves lukewarm on the topic of giving away the rights to specifications in other contexts. Finally, BPMI.org appears to be making a pitch to become the sole industry guardian of ongoing standards development for BPM, whereas IBM and Microsoft may well prefer to hand this role to their own creation, the Web Services Interoperability Organization (WS-I).

Nor are these the only two camps with a stake in the evolution of BPM standards. The UN-backed ebXML initiative has its own BPSS (Business Process Specification Schema - PDF file). It is co-ordinated by the OASIS standards body, which has also been developing its own business transaction specification, Business Transaction Protocol (BTP). The organization published a BTP primer in June (also available as a PDF), which Doug Kaye recently recommended as "an excellent introduction to transactions in a loosely coupled SOA."

Another interesting perspective from the ebXML camp comes in two new papers on a collaborative model for transactions based on the BPSS specification by Jean-Jacques Dubray, who is chief architect at precision lifecycle management company Eigner. He is also the author of an analysis of BPEL4WS published on his ebPML web site (currently as a draft, with a fuller version promised for the end of this week).

Other reactions to last week's announcement of BPEL4WS have been muted (perhaps a sign of growing fatigue with the torrent of prospective standards pouring out of the web services industry). The Stencil Group's Brent Sleeper wondered whether standards are running out of steam: "the higher up the stack this stuff goes, the more it intrudes on vendors' own product strengths and, potentially, customers' own business process expertise." CBDi Forum sensibly noted that the travel reservation scenario chosen to illustrate the application of BPEL4WS was "trivialised" compared to real life.

All such discussions will be academic in any case, so long as businesses remain ill-equipped for a service-oriented view of IT. "In the past six or seven years, I have seen only two IT organizations that are truly process-oriented," says Meta Group analyst Dan Vogel, quoted in a ZDNet article. "When companies move to a Web services model for internal as well as external functional integration, whether the IT organization has its process act together will become instantly apparent to everyone." Some thought-provoking advice on the groundrules to adopt can be found in The Seven Principles of Service-Oriented Development, by ZapThink senior analyst Jason Bloomberg.
posted by Phil Wainewright 2:23 AM (GMT) | comments | link

Alternative views

There are now two ways of viewing this weblog. For an at-a-glance view of the most recent postings — including the opening sentences from the three latest entries — continue to visit the default URL for the Loosely Coupled website, from where you can click through to the full postings. Alternatively, go direct to the main weblog page, which is now at http://www.looselycoupled.com/blog/, to see the current postings in full. The link quoted in the RSS feed for the weblog has changed (as of this posting) to point to the new main weblog page.

Although this is a new location for the main weblog page, all archive pages remain as before and the permalinks haven't changed. So you only need to update any link or bookmark if you specifically want to link directly to the main weblog page, rather than to the at-a-glance view on the new Loosely Coupled home page.

Introducing a home page provides a more comprehensive overview of new content on the site, in a format that loads much faster than the main weblog page (some other changes are in the works to improve the load time still further). What's more, it paves the way to the introduction of some extra content pages that are currently under development, which will be featured on the home page alongside the weblog links — so watch this that space!
posted by Phil Wainewright 6:38 AM (GMT) | comments | link