Tim Bray: reachservices is a good example of what
the SOA deployments of the future will look like. I think that if
there are any protocols, technologies, or standards that turn out
not to be necessary for this project, then maybe they’re not
that necessary at all.
220.127.116.11 A client application which avails of the IAM service
MUST generate complete HTTP 1.1 POST requests and MUST receive and
interpret entire HTTP 1.1 Response messages. Not that
necessary: HTTP GET
18.104.22.168 All traffic to the IAM service MUST (and all traffic
from the IAM service WILL) be encoded using US-ASCII (7 bit)
exclusively and encode common non-US-ASCII characters as empty
<Unicode ch=”xxxx” > element, where
the ‘ch’ attribute MUST be encoded using Unicode 3.1
code points. Not that necessary: UTF-8
22.214.171.124 The <MessageType> element is the primary
identifier by which the IAM service processes the message.
Information entered into this element controls the validation,
processing, transformation and routing rules, which are applied to
a message. This element MUST be present in all Reach envelopes and
it MUST only be present once. Not that necessary:
I think you are looking at an older, (possibly) less relevant document. Looking at the Reach Interoperability Guidelines (RIG) documents, in particular the XML 1.0 Profile you find "In order to be RCF (Reach Canonical Form) compliant an XML document:
1. Must be a well formed XML document compliant with [XML 1.0] [CF]
2. Must be encoded in UTF-8 and compliant with RIG 5..."
Similarly, the ReachEnvelope has a MessageType, but it is now the RIG number of the message payload. and URI's are a central feature, at least in the majority of the Public Services Broker Phase 1 Functionality and Architecture documents. As far as HTTP GET not being that necessary, I couldn't find anything that specifies the use of HTTP POST to the same level of detail, but the Broker Architectural Model document says "the full list of (transport) 'adapters' to be supported has not yet been determined but will include http...". It is hard to envisage an http 'adapter' that did not include support for GET that wasn't fundamentally broken.
Consider using the recommended mnemonic names in RCF1 for common characters found in the ISO8859 repertoires. E.g. '<eacute/>'. These will be round-tripped through RCF unchanged and provides a mechanism for avoiding any non-US ASCII UTF-8 characters.
The details of the HTTP transport adapter have not yet been finalized. There are likely to be multiple options as a consequence of the industry not coalescing around one way to do reliable messaging over HTTP. Sigh.
This will be in RIG 7.
Rest (over even REST:-) assured that all HTTP adapters will feature GET :-).
Wouldn't those reliability standards maybe be one or more of WS-Addressing, WS-MessageDelivery, WS-ReliableMessaging, WS-Reliability - i.e. one or more of those that Tim thinks the world could do without?
I get the feeling a lot of the critique about the WS-Mess focuses on the wrong issue: Of course there's far too many pseudo-standards in the Web services are, but that doesn't mean that there is no need for a standardized solution to the problems they address.
A couple of things. SOAP is not a pre-requisite for reliable messaging over http. We would like to settle on a single SOAP based mechanism as one of the provided options. To this end, it would be great if all the variations on a theme called Reliable Messaging in WS-Complexity coalesced. Oh, and don't forget ebXML's ebMS which is also SOAP based. Then there is Biztalk's SOAP 1.1-with-a-twist method...I could go on.
As well as that though, there are mechanisms that use plain vanilla HTTP and a simple pattern e.g.: [link] [link]
I don't know about anyone else but I find it horrifying and depressing that in order to make document oriented XML workable, it requires months of work from one (or more) XML gurus/gods to write up the specs (or perhaps more accurately pare down the specs)! What hope is there for us mere mortals? No wonder people gravitate the other way.