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.
Let's read the fine print:
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.
Let's read the fine print:
<Unicode ch=”xxxx” >
element, where
the ‘ch’ attribute MUST be encoded using Unicode 3.1
code points. Not that necessary: UTF-8I 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.
RIG0002, section 9, paragraph 5:
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.
Where is <eacute/> defined?
Robert,
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 :-).
Sean
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]