Alexander Johannesen wrote: > Hi, > > On 12/14/06, Dan Creswell <[EMAIL PROTECTED]> wrote: >> OO is about calling methods and not knowing how they are implemented >> underneath. > > It's *meant* to hide implementation details. Is this true, though, in > your opinion? (My reply to SteveJ goes into more detail, though) It > may solve one problem but introduces abstractivitis, a disease I find > far more disturbing, IMHO. > >> Further methods on an interface don't have to be synchronous/blocking - >> you can model callbacks, queues etc if you choose to do so. > > Event models, declarative patterns, etc, so yeah, sure. Everything > WS-* can do, REST can do to. Everything REST can, WS-* can do to. This > really isn't about who can do it, but who can do it with less amount > of pain, I think.
And how much pain you suffer with each technology is also significantly influenced by how well you use and understand the technology not too mention it's suitability to the design you've created. > >> "Technology that's been around for yonks" - can you be more specific >> about what technology you're referring to? Web servers? Databases? >> Something else? > > UNIX pipes, HTTP, HTML, all stuff that's been around a long time > before WS-* entered the loop, all stuff that's proven, and technology > that - at least in my opinion - adhores to the principles of > simplicity, modularity, and more of both UNIX and Web technology > principles. > One would expect Unix Pipes to adhere to the principles of Unix surely? Being around a long time does not equate to well-proven. And well-proven doesn't equate to "use it everywhere for everything". HTTP and HTML are well suited to some problems as Unix Pipes are to others and they certainly exhibit nice properties when considered from a purist design perspective. You could argue and I might even agree that WS-* is in poor taste but that doesn't mean that web-technology is the best candidate or even a candidate to succeed it. That's because technology is suited to problem spaces and the jury is out on whether web technology problem space intersects with WS-* problem space. >> For me service orientation is not about technology so I don't understand >> your statement about "technology is specifically much much larger". > > I've never stated that SOA (which I've talked quite little about, come > to think about it) is about technology, so I'm a bit puzzled to what Sure, you've not said it explicitly but you have made a link between technology and architectures: "Based on technology that's been around for yonks, and is proven to a large extent in terms of reliance and scalability, and the technology specifically is much, much larger than service orientation alone (if you're into WS-*, you're into service orientation" Actually, I can be into SOA and not be using WS-* and I would argue there are an awful lot of people using WS-* in a non-SOA way. Technology and architecture are independent of each other and thus stating that some technology is bigger than some architecture as you do above, makes little sense to me hence my prompting for clarification. > you're saying here, but SteveJ said the same thing, so maybe it is my > communication that fails. SOA isn't about technology; it's about > service orientation, and using that as a model for architecture. What > I *am* saying is that if you're doing WS-*, you're at least in part - > large or small, right or wrong - doing service orientation, but I > would say this about ROA as well. In fact, I'm not sure I even > understand (well, "agree with") the distinction. But when we talk > about REST we're talking about technology that isn't focused just on > service orientation; WS-* is designed around services (as in web > services) so all the technology is there to try to address service > model and pipeline problems. REST has been solving service orientation WS-* can also be used for things other than SOA implementation. Databases can be used to store pretty much any kind of data. Any technology can be bent to solve any problem. Thus I'm not prepared as yet to buy your bigger scope argument. > *and* very different problems, and as such has greater scope to the > amount of people who knows about it (even though admitedly most don't > know they know it :) and the problems it sets out to solve. And this, > to me, is very assuring as a proven technology, as opposed to a stack > that has spent 10 years getting to where the web was 10 years ago. > IMHO, of course. :) > > > Alex Dan.
