What I’d really like is a simple way to generate a sample SOAP message, grab the raw XML of the message, put it into template form, and allow very easy and hopefully very high performance filling in of the template values. Then you get a very light and fast WS stack.

“Be conservative in what you do; be liberal in what you accept from others.”
（大意 : 自分がすることには保守的であれ。他人から受けとるものには寛容であれ。）

これはジョン・ポステルという人が言…

“It’s the concept that’s opaque.”

I would rather say “superstitious” than “opaque”.

Web Services, as understood and implemented by the software industry, is a re-run of EDI standard directories, segment definitions and code list tables for … what you call SOA (yet another buzz around the good-old hyperlinked application made of a web of stateless functions).

Web Services standards like RDF or SOAP are all about inter-operability in a network of peer applications, precisely like a Service Oriented Application The promise of seamless interconnection in a web of application components, something like “instant universal web API”.

If the experience of X12, UNEDIFACT, EDI/XML or SOAP are to be considered, the Web Services standards promoted face a grim future of diverging proprietary extensions, standard fragmentation and obsolete implementations. Actually, schemas, RDF or SOAP 1.3 make inter-operability and development of web SOA neither simpler nor faster.

People do stick to a proven LAMP stack:

URI as simple interfaces, XML as REST response
for PHP/MySQL, Perl/Postgres, Python/BSDDB or any other similar pair
XSLT, CSS and/or JavaScript for display

eventually an XML/RPC API emerges once the application is stable, and grows as more services are added.

It works for front applications, there is no reason to use another stack at the back to connect with peer applications, trading partners, syndicate directories, etc.

So, maybe the pair

Kid/Python

which fits very in the stack well between

…/JavaScript/XSLT/HTML/CSS/XML

and

Apache/SQL/…

can provide a better development environment for LAMP based back-offices integration than a J2EE or .NET monster.

Even if we were to stop looking for a new platform, a new infrastructure, and adopt your approach (which, by the way, makes absolutely perfect sense), Web Services would still remain problematic. Basically, the very idea that you could set up your business on the premises of deductive reasoning is faulty to the core. Regardless of the underlying enabling technology.

It’s the concept that’s opaque.

SOA, on the other hand, is much clearer, and for it your proposal makes a very nice fit. I’m absolutely buying it!

SOA players are the first class citizens in the information exchange matrix. They communicate with each other via complex messages — a perfect scenario for what you’re describing above. I see no problem with that at all (and frankly I see lots of potential problems with those bus architectures; but hey, them enterprise consultants need to make a living too!)