eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
When you throw a bunch of chemicals into a pot, its common for something to happen. Sometimes the resulting reaction can be spectacular; sometimes it is more subtle.
In time, though, a reaction reaches a point where its products start spontaneously breaking back down into the original ingredients: where chemical equilibrium is reached, and things are going backward and forward at the same rate so that the concentrations of ingredients and products settle down to a steady state.
This notion of equilibrium came to mind when I saw the news about this months ongoing (or even proliferating) problems at PayMaxx, a privately held payroll service bureau in Franklin, Tenn. The companys Web-facing services, it appears, will be shut down indefinitely until numerous security issues can be addressed.
For both industry observers and application developers, the PayMaxx snafu may turn out to be an important symbol: It signifies the transition of Web services—in the general sense, as well as in the technical sense of XML-based open-standards protocols—from an energetic, forward-moving reaction to something more resembling equilibrium conditions.
No one can credibly challenge the importance of Web services technologies in enabling inexpensive, evolutionary, business process-focused application development. The resulting surge of Web services offerings, though, is perhaps now nearing a point where energetic early adopters start to find themselves outnumbered by bread-and-butter mainstream developers in the deployment of new Web services—and where the forgiving indulgence thats given to pilot projects must yield to the sterner expectations that are placed on an established workplace tool.
The technology must become usable by the less talented to produce results that are acceptable to the less forgiving. Thats no small challenge.
Developers who had built applications that consume the PayMaxx services must now confront the need for a fallback strategy. Its always been part of the Web services proposition that an application had to deal with dependence on resources that were not under the application owners control. That theoretical concern is now demonstrably real. Using tools such as UDDI to identify and engage alternative service providers, with or without an intermediate layer of value-added services support, looks like the next step in the process of Web services adoption.
For that matter, not all developers should expect to work with finely grained Web services, any more than all mechanical engineers need to work directly with issues of metallurgy or concern themselves with choosing standard fasteners. At some point, it becomes possible and appropriate to work with higher-level assemblies, even while enjoying the economies of lower cost and interchangeability of parts that come from underlying technical standards.
Emergence of new Web services tools at last weeks EclipseCon event in Burlingame, Calif., is an encouraging sign that the forward-moving portion of the Web services reaction is still quite active, thank you—but developers in an equilibrium environment must learn to look both ways.
Tell me how you keep moving forward at [email protected]