On 29 July 2010 05:13, Nick Gall <[email protected]> wrote: > > > 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-*. >
References? I've dealt with a bunch in the last few years and see REST a couple of times and always limited to the web side. Meanwhile I've seen huge, massive WS-* programmes in lots of different enterprises. On the references side there are stacks for WS-* but I'm still struggling to find REST enterprise integration examples, but I look forward to reading them. > >> >> >>> >>> 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. > But lots and lots did quickly, there is also a big difference in terms of cost of replacement when we are talking physical lines, switches et al against different ways of shifting XML in software. > 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. :-) > Err you do know why WS-* requires interop profiles while REST doesn't don't you? That isn't really a plus point for REST IMO. Again though you are confusing where the complexity really is. The complexity is NEVER in how you create the XML bundle its how PEOPLE build SYSTEMS that INTERACT. That is where WS-* is KISS. > >> 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. > Which should make it easier to adopt if that was true... yet the adoption remains very very small... Meanwhile the "complex" WS-* managed to have almost everyone using it 5 years after starting.... Now something about your statement doesn't quite ring true. > >> 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. > No, REST ignores the real problem and solves something that isn't an issue. Hence the reason that it has remained on the fringes. Steve > >
