Eve concludes an
interesting post about DITA
with an observation on SOA;
The trend in distributed computing is towards service-oriented architectures (SOAs). Early in the life of this buzzword, some people said it should really be called a document-oriented architecture (except for the unpleasant acronym :-) because it’s really all about document-passing rather than a tightly coupled RPC paradigm, that is, if you want to be successful at reusing the components.
Document passing, yes! Hmm, anybody know of an existing system
anyplace that’s good for passing documents around? 8-) 8-(
Via Jef Newsom,
Clemens Vasters describes his current,
very cool project.
He writes;
In fact, the entire server will likely not put a single plain-text, XML 1.0 encoded SOAP envelope onto the wire, but will be rather REST-ish and POX-ish.
Who knew?! 8-)
Dave points to his
original piece
on
XML-RPC
back in 1998. Item number 30 includes some, erm,
interesting claims;
But RPC is important, no matter what format is used, because it allows choices
In allows choices by rejecting an architectural constraint which has been the
foundational constraint of large scale, loosely coupled, distributed systems,
since there’s been large scale, loosely coupled, distributed systems … for
about 40 years now.
you can replace a component with another one
Ah, substitutability. Note that you can only replace an XML-RPC
component with another one that has the same interface, at
least if interoperability is important. Compare that to a system where
every component has the same interface, where you can submit a document
to any component for processing. Now that’s what I
call substitutability.
Stuff I Find Interesting: Enterprise SOA Priorities
Go Yaron! “[…]largely ignoring WSDL and eschewing XML Schema[…]staying away from any spec that has a “WS” in front of it”
(
link) [
del.icio.us/distobj]
A small group of us just wrapped up a
ScheduledTopicChat
on the topic of the relationship between
RDF Forms
and the
SPARQL protocol,
as it relates to an
issue I raised
with the
DAWG WG.
Here’s the
chat description
and
discussion.
The end result is that
Dan Connolly
(DAWG chair) now gets what I’m talking about and realizes the advantages.
The downside is that the impact of the required change would likely be too
great at this time, so will have to be introduced later. Still, it’s nice
to finely get an esoteric point of Web architecture across to someone;
doubly nice too, that it was to one of my heroes of the Web.
The first in a series of articles I’m writing, covering XML based compound documents
(
link) [
del.icio.us/distobj]
Good advice from Julian; “Use REST not XMLRPC. Use XMLRPC not SOAP. Use SOAP not the whole WS* stack”
(
link) [
del.icio.us/distobj]
For those that might still care about the issue of WS-Addressing’s (and
possibly
SOAP 1.2’s)
abuse of the HTTP Request-URI,
some more information…
The semantics of Request-URI are unambiguous in RFC 2616;
The Request-URI […] identifies the resource upon which to apply the request.
Period. Over and out. Elvis has left the building. There are
dozens of commercial and open source implementations, and thousands of
deployed instances of those implementations, that count on that being
the case.
Now, if you buy the position of the WS-Addressing WG (and possibly even
of the XML Protocol WG in the form of SOAP 1.2), they’d have you believe
that the Request-URI identifies the next hop in the chain. Note that
this definition is different than the previous one.
Note to my friends; if you ever find me advocating a position that
attempts to redefine, in a non-backwards compatible way, a key part of
the most successful application protocol ever developed, you have my
permission to shoot me. Thanks.
Here’s a simple question for WS-* advocates; how does one take a SOAP envelope/infoset
generated by the WS-Addressing SOAP binding,
and send it via the
SOAP 1.2 default HTTP binding?
Should be trivial, right? Let’s see. Here’s an example envelope (from the WS-A spec);
<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<S:Header>
<wsa:MessageID>http://example.com/6B29FC40-CA47-1067-B31D-00DD010662DA</wsa:MessageID>
<wsa:ReplyTo>
<wsa:Address>http://example.com/business/client1</wsa:Address>
</wsa:ReplyTo>
<wsa:To>http://example.com/fabrikam/Purchasing</wsa:To>
<wsa:Action>http://example.com/fabrikam/SubmitPO</wsa:Action>
</S:Header>
<S:Body>
...
</S:Body>
</S:Envelope>
That envelope contains both a wsa:To and wsa:Action header, which are,
respectively, where the message is to be sent, and the action that is
requested be done. Now, off in SOAP/HTTP land, we have a set of properties
of the default binding which are required in order to construct a SOAP/HTTP
message. Amoungst these properties are
ImmediateDestination –
“where the envelope is to be sent” – and then either
Action
or
Web-Method
(or both – who knows?!) which define the – you guessed it – “the action that is
requested be done”. So, you’d think that WS-Addressing would have to define
how to populate those properties from a WS-A infoset, ideally as a function of
things like wsa:To and wsa:Action. AFAICT, it doesn’t.
And to think this think got to
CR?!
Egads.
The concept of a “SOAP binding” is prima facie broken because it necessarily
requires treating underlying protocols as transport protocols, as if the SOAP
envelope was actually a SOAP message
(hint: it isn’t).
WS-Addressing should either a) map the relevant part of its infoset to the property model
of the default SOAP/HTTP binding (e.g. wsa:To -> SOAP’s ImmediateDestination), or b) define a
new SOAP/HTTP binding that does the same thing, should problems be found reusing
the default binding.