I agree Anne, but my definition of an ESB was always more in the mediation place than a platform place. To me what XML gateways and the proxy servers are is what ESBs pretty much SHOULD have been in the WS-* world.
Its still middleware and the level of intelligence (particularly around format mediation) in the "traditional" HTTP server is going to go up. Hopefully this will create the sort of balance that wasn't going to be available with vendors punting ESBs as development platforms. Steve 2009/10/1 Anne Thomas Manes <[email protected]> > > > You can put proxies (e.g., policy enforcement points and transformers) > right into the HTTP processing pipeline or into traditional proxy > servers. You can also use appliances like XML gateways which are > turning into super proxy servers. In other words, ESBs don't add a lot > of value to RESTful HTTP communications. REST is a significant > game-changer to the middleware market. The key middleware server in a > RESTful world is your trusty HTTP server with its built-in pipeline > processor, and you rely on the traditional Internet system (DNS, > redirectors, proxy servers, WAM, etc) rather than a whole 'nother > layer of middleware. > > I find it ironic that Noelios and Microsoft felt compelled to develop > a "bridge" between Restlets and ADO.Net Data Services > (http://www.infoq.com/news/2009/09/restlet-extension-microsoft). That > tells me that either Java still has very poor native support to > consume RESTful services (aka resourses exposed via URLs), or ADO.Net > Data Services (ADS) isn't particularly RESTful. (most probably both) > ADS uses a very complex URI-embedded query pattern to name resourses. > No doubt this bridge helps format the URI query string. > > Anne > > > On Thursday, October 1, 2009, Steve Jones > <[email protected]<jones.steveg%40gmail.com>> > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The question on middleware is (for me) pretty much null and void. in the > WS-* world I saw the ESB as being purely about mediation, something that is > liable to be still required in the REST world (hell a proxy is part of that > isn't it?). If what you mean is a logic centric middleware solution then > I'll agree, if you mean that every client connects directly with every > server and there is no ability to put mediation in between then I'd > disagree. > > > > REST clearly isn't "middlware" in the same way as WS-* wasn't > "middleware" that doesn't mean that something doesn't sit, or indeed often > need to sit, between the client and the server. > > > > Steve > > > > > > 2009/10/1 Alexander Johannesen > > <[email protected]<alexander.johannesen%40gmail.com> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Heh, > > > > The only thing that didn't make sense was Steve thinking he was a > heretic. :) > > > > There's always been a semantic wall between those who push pure REST > > and those who push some implementation of it. I like the idea of an > > architectural framework for doing things RESTfully, but I don't see it > > as something that fits into the middleware; to me, if clients and > > servers are RESTful, your job is done. 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. > > > > Alex > > -- > > Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps > > --- http://shelter.nu/blog/---------------------------------------------- > > ------------------ http://www.google.com/profiles/alexander.johannesen--- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
