On 08/12/06, Stuart Charlton <[EMAIL PROTECTED]> wrote: > > > > > > > > > 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 agree, but not that it is against loose coupling, having formal interfaces helps loose coupling as it clearly defines the boundary, without that formalism there is much more cohesion and coupling required to understand how things should work. > > 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. True enough, but WSDL and XSD (and OWL, WS-Policy, WS-* et al) are a good start. > > 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. No-one appears to be able to point me at the standard way of doing this in REST, paticularly the earlier publishing of the info to consumers. > > 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?) So you can only do it on live running services? > > 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. What is the standard formulation of this so I can consume it within tools? > > 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? The trouble is that this sounds like wishful thinking rather than any sort of formalism, its "developer" centric rather than commercial centric which I have an issue with. > > 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/ ____________ _________ _________ _________ > > >> _________ __ > > >> > > > > > > > > > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > >
