This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

SOAphisticated

Stefan Tilkov,

Smart stuff from Tim Ewald:

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.

I guess the recipe here is to stick to the basics to reach the maximum number of possible participants, and narrow it down more and more as the number of partners is reduced and control increases:

  • HTTP + XML, preferably REST-based, for Internet-scale communication patterns
  • Plain WSDL + SOAP + HTTP + some accepted WS-* standards for B2B communication in closed groups or market places
  • Experimental WS-* and proprietary SOAP extensions for internal, EAI-like usage
On January 19, 2005 1:59 AM, Mark Baker said:

Or just do the most general thing everywhere. 8-)

But seriously, there’s been a history of technologies migrating from the more general scenario (Internet) to the more specific (Intranet), but AFAIK, none going the other way. Consider TCP/IP - born on the net, yet crept onto the Intranet and eradicated a myriad of proprietary LAN protocol on its way. Email too. And the Web, of course.

Even if you don’t by that argument, I suppose one could say that if you can reasonably forsee that the Intranet based system you’re developing will need to be exposed to the Internet, then you’re probably best off building with an Internet scale approach.