A couple of my own opinions, if I may make a naive interjection... I haven't figured out how to do interleaved quoting properly in the new Yahoo! mail interface, so I'll just do it this way...
1. "A successful system that can be managed effectively and which has a high degree of formalism around its interactions." On the former, sure, I agree. On the latter, that (to me) sounds like the antithesis of loose coupling. The major lesson learned in large scale (in terms of peer participants) distributed systems design (cue Waldo's "A Note on Distributed Computing") is that most remote interactions are various degrees of "wishful thinking". Formalism, to me, is really about being precise about expectations, and perhaps letting the computer sort out a lot of that precision through some kind of machine readable language. I have no problem with that notion, but I will suggest that there have been very few successful machine readable & declarative ways to formally describe an interface in all of its glory (relationships, invariants, pre/post conditions, etc.). Most of the time we can only describe such things in one of five ways a) an imperative programming language (perhaps with mobile code) - pretty common b) human readable documentation - pretty common c) human readable formal notations (e.g. Larch, BNF notation, etc) - rare except in low-level system engineering contexts d) declarative description languages (e.g. IDL, WSDL) - common enough e) declarative rule languages (e.g. OWL, RDF schema, Topic Maps, parts of Relax NG or XSD for syntactic constraints, Java or Eiffel assertions, XACML rules, WS-CDL, RuleML etc.) - rare enough. The point -- Neither WSDL nor XSD are very useful once we get into describing semantics, extensiblity, or versioning.. All they give me are a crutch for a WS stack to code-generate API stubs and data bound object graphs. I still need a "big thud" of human readable documentation to be precise about my capabilities & expectations, extension points (and policies), and versioning policies. REST isn't much different, except that such policies & descrptions are often included as hypermedia associated links that are associated with the machine-readable interface itself. 2. "How do I document and formalise to a consumer how they get an invoice or place and order? What format do I use to describe the URI, Request, Response, pre-conditions, post-conditions and invariants of the invocation? How is this description then versioned, published and managed. Saying REST is simple means that this should be simple...." It is (relatively) simple, though requires one to really believe that loose coupling is a good thing. You GET a URI of hypermedia to access the description of the interface. This may be done by a developer, a deployer/administrator, or at runtime, depending on the anticipated stability of whatever resources you're accessing and how robust your actual software is (i.e. how brittle is your software? does it expect one and only one, unchangable, interface/media type? or can it tolerate extensibility?) This hypermedia document contain a mixture of human & machine-readable information, or may link to one or more hypermedia documents that contain machine-readable, descriptions of specific interface versions, perhaps interleaved with human readable documentation. Such machine-readable descriptions might be (for example): - HTML FORM (if you want to POST a multipart/form-data document), - XForms (if you want to POST a schema-defined application/xml document and perhaps want a human viewable binding to this schema), - an Atom publishing protocol Service Document (if you want to PUT/POST/DELETE resources in an Atom workspace) - WSDL (if you want to POST a schema-defined XML document as multipart/related or text/xml or even application/soap+xml) - an XSD or RelaxNG schema (an interesting idiom might be that if you GET the URI, you get a schema, if you POST to it, it will process an instance of that schema) Alternatively, one might consider eschewing a machine-processable interface description and just provide just a human readable description with schemas, notable URIs for POSTing, the URI design for PUT/DELETE/GET requests, etc. This approach seems to be pretty common with API's like AWS or Flickr or Zimbra. It's arguably can be just as formal as the prior approaches (use Larch if you really want to.. ;) but doesn't have the ability to code-generate an API for you. You could always just provide this to people (AWS provides toolkits for popular languages, for example). If you want to enforce the pre-conditions at the client-side in an automated fashion, you can link to some kind of mobile code. JavaScript, for example, could to this, but so can XForms' built-in functions, if you can handle those media types. If you want to enforce pre & post conditions automatically on the server-side, you'd do this as you would expect to in any kind of web application. For post-conditions on the client side, likewise. One can return a valid response and/or error messages (and an appropriate HTTP response code) in whatever hypermedia format is appropriate (HTML, custom XML, SOAP Fault, etc.). Such a format can be negotiated between client & server (via HTTP request headers such as Accept:, and response codes such as 300 (Multiple Choices) and 406 (Not Acceptable). Note that the response content type is polymorphic - it is any valid MIME type that you suggest in your Accept: header on the request. Some side notes: - If one has a problem with how informal the REST way of interface discovery seems, it is exactly how most interfaces are discovered in the WS-* world too! While one could use UDDI to discover an interface description, one is more likely to use the idiom of HTTP GET on the SOAP endpoint URI with the "?WSDL" query string... or ".vsdisco" appendix, or whatever idiom suits your WS stack. - HTML FORMs are absolutely machine processable. Libwww-perl for example. Or one of the numerous HTML parsers out there for Java, Python, C#, etc. - Getting data from one source to another is a transformation problem. One has to ask how complex the data structure needs to be. A dictionary of simple strings could suffice with an HTML form interface. A more complex data structure could use JSON. Or XML with a schema. I think the big issue with the REST model is that it is at odds with the way WS client bindings are typically generated in .NET or Java. Such stacks treat WSDLs and XSDs like an RPC interface and generate stubs or proxies out of them. These are often brittle little things, and don't tolerate modern type system concepts like parametric polymorphism or dynamic return types. Our web browsers have a dynamic content type registry - why don't our integration stacks? Cheers Stu ----- Original Message ---- From: Steve Jones <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, December 7, 2006 1:10:07 PM Subject: Re: [service-orientated-architecture] ROA is not SOA - (was Alternatives to WS Standards) On 07/12/06, Jan Algermissen <algermissen1971@ mac.com> wrote: > > > > > > > On Thursday, December 07, 2006, at 05:43PM, "Steve Jones" <jones.steveg@ > gmail.com> wrote: > > >Interface definition is a fundamental requirement for professional > >engineering IMO. Having a standard way of describing these things is > >a base requirement for complex environments. > > Experience with the Web shows that the best you can get (for internet scale) > integration projects is a single interface on all components. That is what > REST's uniform interface constraint is all about. Oh boy.... > > Question: > > What are (for you) the most important properties of the resulting > architecture when you design a large scale integration architecture? A successful system that can be managed effectively and which has a high degree of formalism around its interactions. > > The question to this should guide your choice about what style to choose for > your architecture. > > REST guarrantees certain properties (at the expense of decreasing others of > course) and if you want your system to have these properties, pick REST if > you don't, pick someting else (that gives you the properties you want). > > The most important properties that are induced by the REST style are > evolvability, extensibility and simplicity (which leads to better > maintainability) . Personally, I think they are *very* important to have in > large scale (including enterprise) integration so I'd use REST or a style > derived from REST. Okay taking "evolvability" and back to the actual question (which no-one appears to have a consistent answer to) How do I document and formalise to a consumer how they get an invoice or place and order? What format do I use to describe the URI, Request, Response, pre-conditions, post-conditions and invariants of the invocation? How is this description then versioned, published and managed. Saying REST is simple means that this should be simple.... > > Jan > > > > > > > >> > >> > > When you browse a URL, what does it mean? When you use a SOAP > service, > >> > > what does it mean? When communicating on this mailing-list, what > does > >> > > it mean? I think you're stretching the term "meaning" here ... :) > >> > > >> > No I'm not. When I use a SOAP service I have the name of the SOAP > >> > endpoint and the port as well as the schemas that define the > >> > documents. There is the concept of this being published upfront in a > >> > standard way, with Service names and ports having sensible and > >> > descriptive names. > >> > >> All you have through this is your connection points, schemas, API's > >> and so forth. This is *not* meaning. Meaning is what you make of it. > >> Full automata of services is a pipe-dream, no more realised with WS-* > >> than anything else. In the end, there's developers like you and me > >> deciding what to connect to where and how to use it. > > > > > >Meaning is exactly what I make of it, and when I have all the WS-* > >information available them I'm able to make a hell of a lot of meaning > >(correctly) out of the provided artefacts. If using REST I'd need to > >do the same, but REST doesn't appear to have a standard way of > >publishing this information to consumers. > > > > > >> > >> > > The *meaning* of a URL is whatever we make it. There's guidelines > >> > > which says we should make URL's as meaningful as possible, but > there's > >> > > no requirement to do so. But if we can, we should, just with any > other > >> > > URL out there; REST builds on some nice human principles of > >> > > exploration that I find very attractive. > >> > > >> > Hang on you said it was Opaque and now saying it should be > >> > meaningful.. .. which is it? > >> > >> *I* certainly didn't say "opaque" ... I'm much too simple to use such > words. > > > >Sorry it was Jan who said that. I get confused easily with all the > >contradictions coming in this thread! > > > >> > >> > > Sounds like you're trolling... > >> > > >> > Not at all, having an approach which is "call it and see" isn't really > >> > viable commercially. > >> > >> Why not, exactly? > > > >1) It might not have been built yet > >2) I need to publish the information to the consumers > >3) That information acts as a formal contract between the two areas > >4) Call it and see cannot be viable for full traversal (I can't > >guarentee full coverage as I don't know what I'm looking at) > >5) Communicating change via "it is now broken call it again to work > >out how it works now" isn't viable. > > > >I could go on, but having an integration project (which is what REST > >and WS-* are) without formal interfaces is (IME) project suicide. > > > >> > >> Alex > >> -- > >> "Ultimately, all things are known because you want to believe you know." > >> - Frank Herbert > >> __ http://shelter. nu/ ____________ _________ _________ _________ > _________ __ > >> > > > > > <!-- #ygrp-mlmsg {font-size:13px;font-family:arial,helvetica,clean,sans-serif;} #ygrp-mlmsg table {font-size:inherit;font:100%;} #ygrp-mlmsg select, input, textarea {font:99% arial,helvetica,clean,sans-serif;} #ygrp-mlmsg pre, code {font:115% monospace;} #ygrp-mlmsg * {line-height:1.22em;} #ygrp-text{ font-family:Georgia; } #ygrp-text p{ margin:0 0 1em 0; } #ygrp-tpmsgs{ font-family:Arial; clear:both; } #ygrp-vitnav{ padding-top:10px; font-family:Verdana; font-size:77%; margin:0; } #ygrp-vitnav a{ padding:0 1px; } #ygrp-actbar{ clear:both; margin:25px 0; white-space:nowrap; color:#666; text-align:right; } #ygrp-actbar .left{ float:left; white-space:nowrap; } .bld{font-weight:bold;} #ygrp-grft{ font-family:Verdana; font-size:77%; padding:15px 0; } #ygrp-ft{ font-family:verdana; font-size:77%; border-top:1px solid #666; padding:5px 0; } #ygrp-mlmsg #logo{ padding-bottom:10px; } #ygrp-vital{ background-color:#e0ecee; margin-bottom:20px; padding:2px 0 8px 8px; } #ygrp-vital #vithd{ font-size:77%; font-family:Verdana; font-weight:bold; color:#333; text-transform:uppercase; } #ygrp-vital ul{ padding:0; margin:2px 0; } #ygrp-vital ul li{ list-style-type:none; clear:both; border:1px solid #e0ecee; } #ygrp-vital ul li .ct{ font-weight:bold; color:#ff7900; float:right; width:2em; text-align:right; padding-right:.5em; } #ygrp-vital ul li .cat{ font-weight:bold; } #ygrp-vital a { text-decoration:none; } #ygrp-vital a:hover{ text-decoration:underline; } #ygrp-sponsor #hd{ color:#999; font-size:77%; } #ygrp-sponsor #ov{ padding:6px 13px; background-color:#e0ecee; margin-bottom:20px; } #ygrp-sponsor #ov ul{ padding:0 0 0 8px; margin:0; } #ygrp-sponsor #ov li{ list-style-type:square; padding:6px 0; font-size:77%; } #ygrp-sponsor #ov li a{ text-decoration:none; font-size:130%; } #ygrp-sponsor #nc { background-color:#eee; margin-bottom:20px; padding:0 8px; } #ygrp-sponsor .ad{ padding:8px 0; } #ygrp-sponsor .ad #hd1{ font-family:Arial; font-weight:bold; color:#628c2a; font-size:100%; line-height:122%; } #ygrp-sponsor .ad a{ text-decoration:none; } #ygrp-sponsor .ad a:hover{ text-decoration:underline; } #ygrp-sponsor .ad p{ margin:0; } o {font-size:0;} .MsoNormal { margin:0 0 0 0; } #ygrp-text tt{ font-size:120%; } blockquote{margin:0 0 0 4px;} .replbq {margin:4;} --> __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
