You have human nature at work here. I suppose that Dan Diephouse is more comfortable with RESTful techniques and technology to want to learn and use SOAP. People go with what they are familiar with. To change is more effort up front, even if the benefits are higher long term, the effort to change still deters. Same goes for Steven Martin, why change screw drives when the one you have still works fine even though someone else is using something cheaper and easier to use. This does remind me of the COM vs CORBRA battle. Look for a third alternative to arise which will make the UDDI vs REST choice another useless debate.

DragonMist: your comment makes me laugh. I've written not one, but TWO SOAP/WSDL frameworks from scratch (the second one with several others beside myself). If anything, I wish I wasn't so comfortable that I knew the horrors that arise from various implements inside companies :-)

It doesn't matter whats on the wire per se, what matters is how distributed systems are built. People such as Steve Vinoski (and many others) have written a number of great articles on why such RPC systems are a bad idea for distributed systems. I think you'll find that if you dig in a bit it goes a lot deeper than preference and into things like scalability and evolvability.

Seriously, all of COM, CORBA, SOAP, REST, and everything else needs to go.

For text-based formats, s-expressions and m-expressions are far more efficient, and JSON and YAML are worlds easier to parse and process. For binary formats, COM is an overbloated mess (XPCOM shows just how bad it can get) and CORBA is a joke to everyone who's tried to use it. So why not use messaging protocols like those built into Erlang or Objective-C? They're far more useful, far more flexible, and far easier to implement and use.

1. The idea of Dan being too scared to learn SOAP is entertaining. He, like me, has the fear of SOAP that comes from building SOAP stacks, from attending interop fests, from fielding support calls about WS-Security or the various attachment hacks.

2. REST works well with JSON. It makes for URLs that are easier to read when you are debugging

It seems to me that this article didn't really address UDDI at all. It simply defended the SOAP/WSDL stack with a bunch of interop examples that all involve Microsoft tools.

The specific complaints that Dan Diephouse cites (complexity of UDDI, fragility and lack of agility vs REST methods) are based on his experience with SOAP. I was expecting a similarly experience- and example-based response.

Actually both articles do not really address UDDI as a registry of services. Both articles get into the religious wars of SOAP vs REST, which just another war technical geeks like to have, COM vs CORBA, WIndows vs Linux, JAVA vs .NET vs. Ruby vs Erlang vs any other language.

While UDDI is not the best specification it does provide a consistent data model to advertise the existence of services. The problem is that without some type of registry to advertise these services then no one will find them. Think about the internet without a search engine, how would you know where anything exists. You can create all the new repositories that you want that are flexible, but once you start changing the data model of the repository it is no longer interoperable across an enterprise or worse outside the enterprise. Take a look at all the repositories that are out there: IBM, HP, SoftwareAG, Mule Galaxy, none of them are interoperable because all the data models are different. How I discover a service in one repository is different from another. At least with UDDI as the underlying data model I can get some information out without having to understand each data model.

MSFT completely ignored Dan's fundamental point about UDDI: "A lot of effort has been spent on seldom-required use cases. For instance, it's often recommended that people use it at runtime to dynamically look up services. In reality, this is often dangerous, and hardly ever done. You can easily end up with a service you don't want, whether it's because the functionality is slightly different, the service is slower, or it lacks redundant backups."

Of course no one will use UDDI this way. It makes about as much sense as running your apps "in the cloud" without knowing who is providing the compute capacity (and backups, and data security, etc.)

"The problem is that without some type of registry to advertise these services then no one will find them" is true, but that implies a design-time registry, not a runtime one. A design-time registry can be as simple as a web page listing the available services.

I would say trilogy rather than trinity and as for being holy or otherwise, what has any of this got to do with religion?

The discovery of REST is nothing short of a revolution and a RESTful solution to replace the present trilogy would really open things up and bring on equally another revolution. I agree with the appeal from Dan as well as the justification from Martin, even if it didn't seem to address some of the specific issues Dan raised. I would qualify the statement that the trilogy should be dispensed with only once the RESTful solution has been successfully invented and universally adopted, and there I believe that it will surely happen, eventually.

I don't agree with the comment on the risks of dynamically looking up services as it seems to me that's a important benfit of the registry, to be able to dynamically switch to another provider if needed. Not that the risk isn't there, but it can (and this is a must for critical services) be handled by adding QoS parameters as an integral part of the services interface.

I also agree that the specific issues with UDDI were not addressed. I enjoy hearing both sides--I feel it provides the most education about a particular topic. Is there a way Steven Martin would provide a more specifically-UDDI-based response?

Much thanks,
ED