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. Question: What are (for you) the most important properties of the resulting architecture when you design a large scale integration architecture? 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. 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/ __________________________________________________ >> >
