There’s an interesting CNet article that discusses some issues I’ve been lamenting for some time now:
This is interesting because it’s coming from the more mainstream computer press rather than from the developer community.
Standards and new service functionality are popping up at such a rapid pace it’s becoming increasingly difficult for all but the most involved developers to keep up with the technology. Web Service were supposed to be a simple technology but with the addition of all the new specification that’s been popping up it’s becoming anything but simple, both in terms of how you need to implement and even more so in simply having to decide which protocols and service implementations you want to support.
.NET actually has kept things pretty straight forward in terms of ease of use. The recently released WSE 2 kit makes using a number of the new standards fairly straight forward, although it’s nothing as simple as using say the standard Web Reference mechanism that the full VS.NET using plain Web Service provides. But the functionality of the new security and routing protocols are relatively easily accessible.
However, the problem doesn’t lie with the latest tools and technologies and add-ons that might be available for the newest and greatest from the big vendors, but with existing applications that might be running on older technology. For example, for Microsoft – the SOAP Toolkit has not (and apparently will not) be updated to this latest round of technology enhancements. This means if you use the new tools in .NET today you are potentially locking out a large group of potential Web Service clients. The same is true for a host of non-Microsoft soft client tools. In the Java world tools abound too, but even if you have the tools it still requires awareness of the latest tools and understanding that a Web Service is no longer just a Web Service but that it must conform to certain specifications.
This sort of lock-in to the latest technologies is very bothersome especially given the pace at which it is happening. Web Services as a spec have been around for 4 maybe 5 years and really haven’t gotten a solid toe hold until 2 years ago maybe even less. Now two years later we’re off to a new spec that basically is incompatible with the older spec IF you use any of these new technologies. Worse because these protocols are a lot more complex it’s much more difficult to create a customized version or hack and to fake the functionality if you have to work with it in spite of lack of tools.
In addition what’s happening is that these tools get rolled out ‘as it becomes available’ instead of in a consolidated block. This means there’s more and more fragmentation of versions that work with each other. Microsoft especially throws out new tools that have not even made it through the standards process which only aggrevates these problems.
The article above also makes an interesting point, that I’ve been making for quite a while and that is that in many situations, especially in internal environments Web Services are overkill in their functionality and only cause extra overhead. Because of the protocol complexity and parsing incompatibilities Web Services inherently have a fair amount of overhead and using plain XML based transfers can often provide better performance with similar results without having to worry about the complexities of constantly changing standards. It might be more work but with a handful of simplified tools it’s easy to perform XML parsing even in an automated fashion. After all, DataStructure parsing in .NET is fairly easy with Serialization of types and data structures (like DataSets) that can make short work of
This is especially for older technologies. The SOAP Toolkit from Microsoft for example is not able to deal with objects of any sort without some nasty pre-configuration that in most cases is more work than just parsing XML. The advantage of Web Services in this common scenario is quickly lost of the Web Service interface cannot deal with complex types.
The same is also true for newer technologies like .NET in scenarios where the .NET client is accessing a Web Service it can’t properly parse (usually a Java based service – and I’ve run into a few of these. Granted these services had issues with funky namespaces, but…). The most important issue that ties Web Services together is compatible but to this date this goal is elusive at best. Before we go off extending protocols and make the whole interop process more complicated let’s get focused on making the various technologies work properly with each other. It doesn’t do to dream up new technology if that technology can’t deliver on its most important aspect: Interoperability.