So what's the problem? Well look at this on the front page of UDDI.ORG.
UDDI is the building block that will enable businesses to quickly, easily and dynamically find and transact business with one another using their preferred applications.this quote appears several times either exactly as written or slightly altered throughout the web site and in the white papers. The clear implication is that an application should be able to search UDDI, find a trading partner, locate their web services, connect to them and call the functions, all with no developer input. But it doesn't actually say this.
Indeed for all the issues that Clay and Dave have brought up, it's really pretty unlikely. However I can imagine one situation where this might become almost true. And that is where a specific SOAP interface is very widely implemented. In this case, it's feasible to imagine a programer or user doing a search for an example of the interface and then connecting to it and using it with no additional integration effort at all. This means that one vendor or developer group has been so successful that they have created a de facto meta-standard on top of all the other layers in the stack. It also means that that development group has coded up everything that needs to be known about that one interface so all that's needed is to find one.
So rather than argue the point, since I basically agree, let's look at the second issue here that Dave has brought up explicitly and Clay less so. That UDDI and WSDL are tainted by their association with big companies and just represent so much snake oil. Again. Well let's take the BigCos out of the equation and look at the efforts purely on their own merits.
WSDL - In order to use a web service as a programmer you need to find explicit documentation that is clear and concise and that describes the interface. This is no different from any other computing tool. But documentation is not one of the best things we do as programmers and even when the documentation is good, it's sometimes extremely hard to find it. All of this is an argument for a formal interface description language or IDL. It's the same argument that resulted in XML DTDs and Schemas. WSDL is one example of an IDL specifically aimed at SOAP. It's not required by UDDI to define a WSDL file for your service, but it's recommended. So for me the questions about it revolve around how open it is, how good a standard it is and how widely implemented it is. Not why it exists or whether IDLs are a good thing. Surely they are?
UDDI - Let's build a directory of all the web services that have been implemented on the internet. Let's give it a short set of SOAP interfaces so it can be used directly by applications as well as through a UI. Build a set of SOAP replication interfaces into it so that the index can be distributed across multiple sites. Publish all the interfaces and encourage people to build code that both uses it but also implements the index itself so that anyone can run an instance of it using a choice of code from several vendors. Build a reference implementation with two replicated sites. Is this all a good idea? Sure it is! Why are we even questioning this?
So lets get back to BigCos and LittleCos. There's a real disconnect here between web services that are aimed at trade and web services that are aimed at pretty much everything else. The thing is Trade is where the money is and that's why the BigCos are mostly steering web service discussion towards this. It's also why companies like SAP, BEA, Oracle and IBM are building SOAP, WSDL and UDDI support into their applications and platforms. But as long as SOAP/WSDL/UDDI remains open with no fees for using it, this means that lots of web services will get built that are accessible across the internet. This will surely open up all sorts of niche opportunities for new companies to exploit. At the low to mid end, Microsoft have a real chance of getting very large numbers of specific interfaces implemented. This will either be consumer orientated through their operating systems, or business orientated through commerce server. These de-facto standards then become rich open pickings for third parties.
Then what about "everything else". Well even here, if a particular interface (like Blogger's API) gets wide implementation then the next problem is finding an instance of it. UDDI as a standard would be useful here. And even if the MS/IBM/SAP registry is not an appropriate place to register the data, there's nothing to stop a competing cloud of UDDI based servers being set up to index non-trade services.
In summary, some of the benefits of SOAP/WSDL/UDDI have been over hyped, if not by the originators then by the media. But that doesn't mean that the ideas and standards embodied by them don't have merit. What isn't acceptable though is that these standards are patented, copyrighted or otherwise controlled so that developers that use them have to pay a license fee. My understanding is that all three standards can currently be used without any license. They may have been developed mostly by big business but there is no way that those businesses can force a license fee in the future. I could be wrong. And yes, of course there's more to integrating two applications with web services than just clicking on a link or pressing one button. Surprise! It involves programmers and analysts! But SOAP/WSDL/UDDI, good toolkits and lots of implementations should make it easier.
[ << Web Services Are ... ] [ The Syndic8 Project - Promoting RSS >> ]
[ 0 comments ] [ G ] [ # ]