On 07/12/06, Jan Algermissen <[EMAIL PROTECTED]> wrote: > > > > > > > On Thursday, December 07, 2006, at 05:43PM, "Steve Jones" <[EMAIL PROTECTED]> > 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/ __________________________________________________ > >> > > > > >
