New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Mark Little on Mar 22, 2009
After the release of RESTeasy 1.0, Bill Burke spoke with Jack Vaughan on how he sees REST comparing to WS-*. In the introduction to the article, Jack starts by giving his views on the actual name: 'Web Services':
The ‘Web’ part of Web services was different, somewhat exploitative. The Web was a popular success, and you have to imagine someone thinking that if they named the latest software architecture after the Web, good things might happen. It wasn’t a big reach; Web services did tend to use the Web’s bread-and-butter protocol, HTTP.
In Jack's opinion (shared by many if previous InfoQ articles are anything to go by) some feel that REST is "truer to the spirit of the web than classic Web services employing XML and SOAP". According to Bill (and again, many others) "The value of REST architecture is that it takes better advantage of Web architecture" and that the reason behind this is rediscovering HTTP and "trying to understand how the web becomes so prevalent.”
Bill goes on to target the WS-* standards, saying that they're too much of a moving target:
Getting vendors to cooperate is hard – ask Apache.
(Let's ignore the fact that all standardization is hard and as a result takes time and effort, including Java and the work behind HTTP, or that efforts such as WSTF and Stonehenge show that Web Services vendors are willing to cooperate inside and outside of the successful standards bodies such as W3C and OASIS.)
But back to Jack, who says that irrespective of the struggles in standards suffered by WS-* (ignoring the fact that it hasn't exactly been plain sailing for the WWW) HTTP has "forged on" so that now everyone has some kind of HTTP support within their infrastructure, meaning that we don't need to worry about that aspect of interoperability. But ...
REST forgoes certain levels of interoperability, but that may have its advantages.
And Bill agrees:
What is cool about REST is you are focused on straight http. So instead of worrying about interoperability between vendors…you worry about interoperability between applications. You let http do the heavy lifting.
To conclude, Bill says that REST isn't anti-SOA (again something that others would definitely agree with), although it is "anti-WS-Star … and SOAP".
Mark:
the question that I generally see missing in this kind of argument is: "Is the Web a good model for Enterprise Applications?". In other words, can I model Enterprise applications as a set of resources with a uniform interface?
We have seen last week, that even Tim Bray can't do that. That's quite a setback if you ask me.In his post, he explained how he had to introduce a controller and model actions with verbs. Yacks... Tim's implementation of Sun's Cloud API opens quite a big can of worm.
So we can criticize WS-* for all kinds of reason, I don't mind -we both know how much politics there is baked in- I have no vested interest in it, but at the end of the day, the REST supporters are not using REST in a resource oriented fashion simply because enterprise systems look nothing like the Web and can't be modelled via a series of resources implementing a uniform interface.
So it is pretty clear how all this will end up. As they integrate more and more applications with it, people will first get URI template fatigue, then they'll realize how much of a mess having all these schemaless resource representations creates... so they will start creating all kinds of libraries to automate work that seemed cool to beging with, and we will have accomplished another middleware iteration.
In order to make sense of this discussion, we have to ask ourselves which part of web services we are concerned with – web or services? If the answer is web, then Rest argument about alignment with HTTP and Web in general does make sense. If the ahe answer is services (that will be my answer), then the world web is more historical, than practical and alignment with HTTP/Web is irrelevant.
There is merit to think about accessing enterprise data in a Web oriented way, but again the Web architecture never thought in terms of actions and events as this data gets updated in an orderly fashion, so trying to align that aspect -that I would qualify as Service Oriented and Event Oriented- with "the Web" is no just irrelevant, it is simply doomed to fail. Tim Bray seem to have come to that conclusion.
It is, IMHO, an error to oppose resource orientation to service orientation simply because 'WS-* standards ... are too much of a moving target'. If that's the problem, let's fix the problem. Ultimately resource orientation, service orientation and event orientation will have to coexist as none can be reified in the others' formalism.
Just to be clear Bill's comment 'Bill says that REST isn't anti-SOA' is not correct. REST is by definition anti-SOA since there are no "service" concept in it. There are no service boundaries, no contract, no way to define and monitor SLAs (on what? resources?), no versioning ...
The shift of one endpoint per service to one endpoint per resource is significant. Service Orientation is simply incompatible with one endpoint per resource.
I think Boris hits it on the head. There's two parts to web service, the web and the service. On one side you have people who wants services that can leverage existing infrastructure (WS-*), and on the other side, you have people who want the web as it exists, but consumable (REST)
Being a web service guy myself, I think the future of that path is with frameworks like WCF, that can leverage web services, but can really swap them for anything if needs be. The "web" part is just a convenient technology, but by no mean a centerpiece in its development. Its just "there", so we use it, but if it vanish, we won't lose sleep over it.
Thats why both REST and WS-* need to stay, and why the argument as a whole is irrelevent...they answer totally different business needs.
Francois, it seems to me that the amount of existing infrastructure you can leverage when using RESTful HTTP vastly exceeds the stuff available in the WS-* ecosystem.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
6 comments
Watch Thread Reply