eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
When people talk about “conversational” Web services, I wonder if theyre familiar with conversational Klingon. In that fictional language from the Star Trek universe, theres no such thing as a greeting: the closest thing to “hello,” its said, literally translates to something like “What do you want?” A finer point of usage is that Klingon conversations dont begin with small talk such as “Nice day today,” but with something more like an agenda: a statement of the points to be made.
That notion of a Klingon conversation sounds a lot like a Web services exchange to me.
Im not comparing Web services designers and developers, themselves, to Klingons, although its interesting to speculate on the kind of things that one might hear during a Klingon code review. My favorite is No. 5 on a Top 10 list that I encountered: “Specifications are for the weak and timid!”
I am suggesting, though, that so-called “conversational” Web services might do well to borrow some ideas from human conversation. It seems to me that on public networks, when services are owned and operated by different entities, an exchange could most usefully begin not with “what do you want?”—but rather with something closer to “How are you today?” Given the chance, a Web service might answer, “Not so well, actually,” or “Really busy right now, can we talk later?” The initial service requester would then be able to make a situation-specific decision as to whether it should press on and tolerate a degraded or delayed response, or seek an alternative service provider or reschedule a transaction.
I dont mean to trivialize the proposals that others have made under the label of “conversational” Web service design. IBMs experimental “Conversation Support for Web Services,” now listed as a “retired” technology on the IBM alphaWorks site, offered the equivalent of “Whats up with you?”—that is, a model in which one service could ask another if its message formats or other minutiae had changed, and accommodate any updates rather than breaking a tightly coupled protocol. BEAs notion of “conversation” preserves service state so that a client and service can have a series of exchanges without starting over, or a service can gracefully handle concurrent interactions among multiple clients. Any service thats going to be more than a great demo, or a useful mode of coupling in a controlled environment, needs that kind of resilience.
Web service designers are being challenged to meet the needs of more users, on more types of client, doing more ad hoc and real-time things on the Web—getting driving directions, for example, rather than just paying bills online. Thats going to require routine attention to quality of service, perhaps in the context of a QoS stack thats considered just as important as the protocol stack.
Its not enough, though, for services to encounter each other with nothing but lists of demands, treating their own state of health as private information. Its in the best interest of the user for services to be more social.
Feel free to tell me what you want at [email protected]
Check out eWEEK.coms for the latest news, reviews and analysis in Web services.