On Fri, 2006-12-08 at 20:41, Steve Jones wrote: > On 08/12/06, Andrew S. Townley <[EMAIL PROTECTED]> wrote: > > On Fri, 2006-12-08 at 15:27, Steve Jones wrote: > > > On 08/12/06, Andrew S. Townley <[EMAIL PROTECTED]> wrote:
[snip] > I guess I'm an old school engineer, formalism is a good thing, > formalism reduces costs due to miscommunication, formalism enables > things to be defined up front. If I am agreeing approaches and > interfaces between 9 different parties then I want something formal > that is at least partly binding rather than 9 different approaches > which are all informal. [snip] > In terms of "formally specified" what is the standard approach for > making that formal communication in REST? [snip] > > Because your service interface description says what they mean. > > What is the standard service interface description language for REST? [snip] > Expecting to not have to work at the protocol level and to work at the > application level is NOT IMO an unreasonable expectation in 2006. > Still having people shoving ASCII/Unicode down ports doesn't sound > like we have move forwards much in the last 30 years. [snip] > But you need a formal way of description the interaction, which is > what I'm asking... what is the standard way of describing interaction > in REST? [snip] > A decent WS-* implementation isn't bound to a remote object... and > here I get confused again. Firstly to claim that rest is working at > the exchange level (rather than invocation level) you have to have a > way of describing that. Secondly there have been claims that a REST > URI refers to a specific resource instance, thus implying a close > binding to a specific object instance (not just a class). Ok, I deleted a lot of stuff, but the basic things I'm going to address is the formalism you're looking for in defining REST interfaces. I also want to say up front that I'm not a REST expert (Mark and Jan are much more qualified than I am in this regard), and that what I'm going to use as a primary example isn't REST, although it does have similarities as far as the uniform interface goes. What I'm going to try and illustrate (without hopefully going too long) is that what you're really arguing as formalism boils down to a question: "can I point a tool at it and get some sort of code generated that is based on a formal specification?" If this isn't your biggest issue, please accept my apologies in advance and you can delete the email before you read the rest... ;) 5 min backgrounder/refresher on the REACH project: I didn't design the overall architecture, but I was responsible for it for 2 years. Reach uses a concept of a business level envelope called the Reach Envelope (http://sdec.reach.ie/rigs/rig0100) that encapsulates messages independently from a given transport. These messages have several properties, but the most important ones are: * The message source (not necessarily the message sender) * The message destination (not necessarily the message receiver) * The message type * Some identity information * Correlation & transaction identifiers * The message body Additionally, all communications in this architecture are fundamentally asynchronous. Each service interface is defined by an identifier which is also used as one of either the message source or destination, but that identifier does not represent a physical location. If you send a particular message to a particular destination, you're interacting with the service. This same message will be transferred from source to destination over one or more of RRMTP (http://sdec.reach.ie/rigs/rig0007/), JMS or BTF 2.0 (BizTalk Framework), but the transport is totally abstracted from the service implementations. They (should) deal only in terms of the Reach Envelope and the messages contained within it. This allows implementations of a given destination interface to be actually isolated in different physical locations based on transports, e.g. an implementation communicating via JMS and another implementation of the same destination identifier that communicates via RRMTP. Mapping of the logical identifier to the physical location was the responsibility of the integration framework. End of background/refresher This was our version of the uniform interface: send messages (somehow) to a destination, and, based on the service interface application protocol defined by that destination, one or messages would be delivered back to the original message source via whatever transfer mechanism made the most sense. The formal definition of the service interface application protocols are expressed as documents. An example of one of the core ones is here: http://sdec.reach.ie/rigs/rigm029/. To me this looks like a formal enough specification, even if it could be improved in some areas. As a service provider or a service requester wanting to implement either end of the service, you read the specification, download the message schemas and write your software. If you want to stub a client or server implementation as a raw JMS, sockets, HTTP or in-memory method call, that's up to you, and is certainly possible. If you want a more REST-like (in the sense that it tries to really follow the semantics of HTTP and uses more of the verbs) formal specification, RRMTP is an HTTP application which provides the business service of reliable message delivery. In my view, it's just as much of a service as m029, but what they provide in business terms is very different. More people than just me have been able to implement clients and servers that have been able to interoperate quite nicely. A formal definition of something that I would say is "real REST" is the Atom Publishing Protocol (aka APP and found here: http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-11.txt). Like Reach, it makes use of a domain-specific envelope, and it allows for open content models contained within that envelope. You can use APP as the basis for interacting with all sorts of business systems (even the classic buyer/broker/seller). For a generally available Web service, you may not care if prospective clients can do anything with the data or not, but most likely (and especially for a B2B scenario), you would still have a formal document that referenced APP as the means to get to the information, but then described when, how and why the information would be where it was so you could use it in the context of solving a larger business problem. You won't be able to use either of these three types of specifications to autogenerate code any more than you can auto-generate the code of a TCP/IP stack based on processing RFC 793 with something. Does that make them any less formal? If so, how? I agree with your point about needing to coordinate between 9 different business owners. That's why the SDEC and the RIGs exist, and it takes a lot of arguing and planning to come up with message schemas that leverage common, existing data models so you don't end up re-inventing the wheel. I know that some people on this list think that sort of effort is not only difficult, but nearly impossible to do, and certainly difficult to scale to large communities of interest. I don't think so, because if people are serious enough about it, it can be done. Why else would the IETF, OASIS, ANSI, ISO, W3C, etc. bother themselves (leaving out the less than pleasant socio-political reasons for the moment)? You're still going to need this agreement anyway if you're going to bet your business (or your partners') on your SOA, WSDL or not. What the WSDL provides to an SOA in my view is such a minor piece of the puzzle, I'm a bit surprised that you're so dead-set convinced that REST is not viable because there's nothing machine processable that's been specified and is in de-facto use. The business-level semantic agreement of both the messages and the interaction protocols is what's going to make or break the SOA, not the technical invocation mechanisms. WSDL describes a more complex invocation mechanism, therefore it has tools to help developers hide that complexity. REST has a straightforward invocation mechanism, so your toolkit can simply be XMLHttpRequest. What is it exactly that I don't understand about what you're saying? ast -- Andrew S. Townley <[EMAIL PROTECTED]> http://atownley.org
