"Make it easy for people to pay you"

During my keynote at last fall's Applied XML DevCon, I told people about my stepfather's advice to me when I was a young man just starting out in the industry: “Always make it easy for people to pay you”. That is very good advice, and is, I believe, the essence of Web services. After years of struggling with distributed object systems (CORBA, DCOM, RMI, .NET Remoting), XML and HTTP popped out as a great way to wire up network apps. SOAP and WSDL made it easier to build standard tooling that helped bring those protocols to the masses. In short, we hit a sweet spot that provided made it easy to maximize reach. That is, you can build a service and (if you're careful) it can be consumed by pretty much anyone anywhere. Depending on the tool you use and the tool they use, they might have to do more or less work (this is part of the free market of WS tools and infrastructure). But it's not that hard to make it work.

My first post of the year addressed about standardization and pondered the more practical question of how useful the features offered by vendors in next-generation WS plumbing are going to be. These two issues are actually very closely related. Standardization helped make HTTP, XML, SOAP, XSD and WSDL (okay, SOAP 1.1 and WSDL 1.1 are only de facto standards) ubiquitous. If you use that basic foundation, your services will have reach (and it will be easy for people to pay you). But as I observed Friday, the timelines for standardization and next generation infrastructure don't align, which means that alot of the fancy WS-* functionality will ship based on published specs, but not standards.

Does this matter?

It depends on how hard it is for lots of vendors to implement them. The value of the standardization process is that it digs issues - architectural, security, reliability, scalability, etc. - and addresses them. It also makes the language more tighter and less vague. Specs generally improve as standards, WSDL 2 not withstanding. Without standardization, building interoperable implementations is harder because the specs they are built to are often vague or incomplete and the only real definition of what's supposed to happen is “whatever the other implementations do“. If that lowers the uptake of the specs such that there are fewer implementations, that means that using them in your system will by definition limit your reach (and make it harder for people to pay you).

Does that mean that we shouldn't be doing WS-*? Absolutely not. Does it mean that we should be standardizing all of WS-*? Ideally, yes, but the reality is that it would take a very long time and people are itching to proceed. So I think the practical reality is that we'll end up with a spectrum of services. Inside my org group, department, or maybe company, I'm likely to have more of an opportunity to standardize on a smaller number of kits that offer more advanced functionality. I'll leverage that for stuff I'm building for internal consumption. For anything I'm offering to partners and the world - where there is no agreement on what kits to use - I'm likely to eschew those more advanced features and settle for application-level solutions so that reach is not restricted.

My comment about features in next-gen plumbing should be viewed with that split in mind. For external facing stuff where reach is critically important, protocols need to stay simple. For internal stuff, that's less of an issue and there I think a lot of the new more advanced features will be very useful.

Of course time will tell.