What They Don't Tell You in the SOA Owner's Manual
Most enterprise IT departments consist of a heterogenous computing environment, with applications running across the gamut of operating systems - mainframe/midrange, solaris or other unix, linux, and windows.
A great deal of the buzz generated around web services is not necessarily commercial entities providing open APIs to their public applications, though there are very popular examples in services published by Google, eBay, Amazon and the like. The rubber meets the road in enterprise IT, where J2EE and .NET applications running on unix/linux/windows need to communicate with legacy applications running on mainframe/midrange.
Web services at first blush appear to be the holy grail of loosely coupled messaging, opening up immediate possibilities to allow integration between older mainframe apps and their newer J2EE/.NET counterparts.
If you're working in this kind of environment, there are myriad potential stumbling blocks to be aware of, and not necessarily those caused by the litany of WS-* or OASIS standards (though this is an area of concern). A major stopping point resides in the way legacy mainframe apps tend to be architected - where other external applications (generally other mainframe applications) are called via subroutines in a large, serial batch cycle.
Depending on the amount of back-end processing involved, web services in general have sub-second response time; say, an average of 300 milliseconds for argument's sake. Mainframe batch jobs can make tens of thousands of serial subroutine calls, and generally expect responses within minutes. See the disconnect? While mainframe COBOL apps can be written to run in parallel, most aren't - meaning your usual five minute processing time for 10,000 subroutine calls now adds up to fifty minutes of processing time for that shiny new web service. Most mainframe batch cycles will ABEND (the COBOL equivalent of a runtime exception) if asked to wait that long for a response.
Web services can be the solution for interconnect between legacy and modern applications, though consideration needs to be made not only for the transfer protocols and the message formats, but for the underlying architectural decisions which drove decades of mainframe development as well. If you're looking to web services as the layer to integrate your enterprise applications, it can be the right solution, but make certain there is willingness within your organization for a certain amount of refactoring in your legacy apps to accommodate communication via web services (or other SOA implementations) in a real-time process, rather than as a component in a batch cycle.