It’s just data

Excellent Driver

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:

Hmmmm.


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.

Posted by robert at

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?

Posted by Sam Ruby at

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

Posted by Sean McGrath at

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.

Posted by Stefan Tilkov at

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]

Posted by Sean McGrath at

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.

Posted by robert at

Web service reading

Tim Bray finds an Irish webservices standard and likes it. His description does sound good, rather RESTful and all, but...... [more]

Trackback from Notes from Classy's Kitchen

at

Add your comment