eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
If Web services will be the model for a majority of new applications in the next few years, as Gartner research released this fall projects, then it would be good if we could build those services on the lessons of the past instead of repeating past learning processes.
What seems to work least well, when we try to do things in loosely coupled ways over long-distance links, is our handling of intermittent and inconsistent connections. Request A, made at time T, and request B, made at time T+e, may or may not reach the granter of those requests in the same order; answers to successive requests may or may not be consistent with each other if other requesters are contending for the same, or some of the same, finite resources.
Without proper controls, you might receive a payment without my account being debited by the same amount, or (worse, if I may say so) I might be debited without you being paid. I might pay for something that Im unable to receive, because a finite supply was exhausted in the time between one step of the transaction and another. A poorly implemented transaction protocol might assume, however, that what was available at the time that I made my payment was handed over to me at the next step of the transaction.
There need to be mechanisms that ensure that a single logical operation (like an exchange of money for a good or service) is either completed or canceled, in the latter case with no side effects from having been interrupted. On the Net, new issues of privacy also arise that have not always been part of past discussions of electronic transaction methods. “Atomicity,” or an “atomic operation,” are the formal terms for these goals, although they sound like jargon from a completely different field when one tries to use them with people who arent IT professionals.
Thinking about atomicity brings to mind the challenge of being a soccer referee. American football seems much like 1970s IT: you set up the play, like a deck of cards in the IBM reader; you run the play, calling out signals at the line like Job Control Language instructions; you watch for thrown penalty flags and instructions to go back and do it over, with the same apprehension I used to feel that I would come back for a ten-page printout and instead find a fifty- or hundred-page error dump.
Running a soccer game is more like working with Web services. The ball can go in any direction at any time, just like the flow of control among a confederacy of services running on any number of different machines. The players can move the ball with feet, chests, or heads, but not hands–rather like a Web services developer who can use e-mail, http, ftp or any of several other protocols to move data, but who should not handle it directly with platform-specific mechanisms or low-level code.
Specifically, Web services development reminds me of a rule in soccer that confuses the heck out of novice soccer spectators (like most young players parents). Im talking about the offside rule, designed to prevent a team from parking someone right next to the other teams goal to receive a pass and take a quick shot into the net.
The rule says that there must be at least two defending players as close to, or closer to, their own goal than an attacking player who receives a pass, at the time that the ball is played by the attackers team mate. There are exceptions: you cant be penalized for being offside in your own half of the field, for example, and I beg the indulgence of fellow soccer referees if they feel that Ive failed to mention an important subtlety. Were all still learning this stuff.
The key point that I need to make is this: spectators often scream, “Offside!” if a player sprints ahead of the next-to-last defender, receives a beautifully aimed pass, and kicks in the ball for a goal. Theyre seeing where the player was when he got the ball, not where he was when it was played: if he passes the defender while the ball is in the air, after his teammate kicked it, the play is good. Thats the atomic nature of the play that referees have to learn to recognize, for example, by learning to hear the sound of the ball being kicked while theyre watching the players who might be in position to receive it.
Web services tools must also cope with the challenges of loose coupling and asynchronous interaction. What was the state of play at the time that a request was made, as opposed to the situation at the time that it was granted? And how should any difference be resolved?
Web services practice must evolve in the direction of handling these questions reliably, and processing transactions fairly, if theyre to move into the World Cup class of robust applications.
What new rules would you write for tomorrows development games?