This issue has an emphasis on SOA, an area of application development that has gotten a life of its own over the past year. Service-oriented architectures are not only the rage of the age, but represent an approach sure to be on the front burner of enterprise IT managers and developers for many years to come.

An essential idea behind SOA is the idea that applications should support the requirements of users. This may look blindingly obvious, but is actually a subtle point that relates to still-burgeoning web usage by users as well as the ubiquity of distributed computing networks within organizations of all sizes.

The web services involved in creating a SOA-such as those offered by WebSphere-are loosely coupled and (in theory) highly interoperable. They reflect the idea that users are in control and need their data and interactivity now, and that usage may not be always predictable for every app within the enterprise.

Yet these loosely coupled applications need to be far more than simply interoperable. They need to present as unified a meta-interface as possible to users, whatever latency there is in the system needs to be consistently latent, and moving away from point-to-poiont application development should not mean even a slightly degraded user experience with any particular application.Since SOA is not a product, but rather a methodology, framework, or approach, it's easy for companies to jump on the SOA bandwagon and tout why one particular app development environment is superior to another. Many apples-to-oranges and apples-to-banquets comparisons occur.

Whether you are coming at things from, say, the XML or SOAP angle, from a higher-level workflow and business process angle, or from the very-high-level view of IT in the enterprise and its impact on revenue, growth, productivity, etc., the "TAO of SOA" must never stray from age-old concerns such as reliability, availability, and scalability.

Add in the severe compliance requirements of the age, plus increasing concerns about any manner of data integrity and security problems, and it is clear that development of a SOA strategy is in many ways no different than application development strategy has been over the past 40 years.

IBM has seized and maintained industry leadership in the web services application development space, and proudly notes this every time a new report from Gartner is published. Yet it faces challenges that will not abate. One of its prime competitors is touting a "blended" strategy that differentiates app development requirements by specific application rather than enterprise size. The company's blend is between open-source and what it calls "commercial" technology, as it distances itself from the dreaded word "proprietary." Another says it gradates its framework to accommodate needs throughout any size organization.

And speaking of open source, the threat from open source developers cannot be trivialized. Although it seems that organizations of a certain size, or applications of a certain criticality, seemingly need to be based on a relatively massive environment such as WebSphere, it behooves the market leaders to continue to point out exactly where their technology is most valued, and not only why they think it is valued.

Even though everyone likes to hear about streamlining, efficiency, even simplicity, SOA is not something that necessarily makes things simpler for developers or IT organizations. To dig down into the guts of the thing is to face new learning curves, new required skillsets, and to always remember that the end-user doesn't care if it's a SOA or a boa.

The system simply needs to work-quickly, consistently, and effectively. We hope this issue of WebSphere Journal enables WebSphere developers at least a little in their quests.