On Wed, Jul 28, 2010 at 7:15 AM, Steve Jones <[email protected]> wrote:
> > > > > On 28 July 2010 05:36, Nick Gall <[email protected]> wrote: > >> >> >> On Thu, Oct 1, 2009 at 7:35 AM, Alexander Johannesen < >> [email protected]> wrote: >> > In fact for me, REST eradicates >> > most needs for middleware, and I suspect this might be why some push >> > REST back into middleware (either through staying alive or lack of >> > understanding), but that's just pure speculation. >> >> Indeed. All the middleware you need for REST is already built into the >> web: web servers, caches, proxies, and client http libraries. The rest (npi) >> is the application. If middleware vendors want to be useful in a REST world, >> they should work on improving the ease of use and efficiency of web servers, >> caches, proxies and client http libraries instead of foisting huge chunks of >> software on top of or in between web elements. >> > > So why in 5 years hasn't this happened? Why haven't enterprises done this > in 5 years? Could this possibly be that because the "middleware" is just an > enabling piece (execution context from the OASIS SOA RM) and the real > challenge is actually on the two ends of the communication engagement and > the tooling and pieces that go around the "huge chunks of software" are > actually the things that make it operationally useful? > Lots of enterprises ARE doing it, ie using more REST and less WS-*. > > > >> >> I've pointed this out >> elsewhere<http://tech.groups.yahoo.com/group/rest-discuss/message/13336>: >> The difference in mindset between the RESTafarian and middlewareite camps is >> fundamentally the same difference in mindset between dumb network and smart >> network camps. Since the end-to-end debate has raged on for over 25 years, I >> see no reason why the derivative REST-KISS vs MIDDLEWARE-LIO (lard it on) >> shouldn't keep us entertained for just as long. >> > > Ummm its the old "they are too dumb to understand my really clever > approach" argument. That doesn't really gel with me as REST is > fundamentally not KISS as KISS is about the people and the process parts > rather than the technology parts in terms of efficiency of technology > delivery. REST has not demonstrated that it is a KISS approach from a > people or process perspective. > > Look at how long it took enterprises to give up on SNA, DECNET, etc. and embrace TCP/IP for their corporate backbone WAN protocol--a lot longer than five years. A lot of them STILL don't get the end-to-end argument. > KISS is Web Services, define an interface, publicise it, people can pick it > up, lob it in tools, use it. > LOL! That's the first time I've seen WS-* described as KISS, especially when compared to REST. I guess that's why WS-I is churning out interop profiles at such a blistering pace. :-) > > REST is complex. Make a call, infer the interface, infer the result, infer > what you do next, do all of this without decent tooling > REST, like all great architectures, is incrementally complex. You can start simple and add complexity as your needs and skills grow. > > Now arguably REST is more powerful and flexible but arguing it is simpler > makes the common techno-centric mistake of thinking that the complexity is > in the number of IT moving parts rather than in the number of CONCEPTUAL > moving parts. > Errr....the essence of REST is to minimize and standard the number of conceptual moving parts. It's known as the "uniform interface" constraint. It's WS-* that encourages conceptual proliferation and complexity, ie a custom set of concepts with every new WSDL interface we create.
