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 Scott Delap on Jul 26, 2007
...My sense of it is that on Java, too many web frameworks - think JSF, or Struts 1.x - consider the Web something you work around using software patterns. The goal is get off the web, and back into middleware. Whereas a framework like Django or Rails is purpose-built for the Web; integrating with the internal enterprise is a non-goal...
Coté then proceeds to explain the abstraction levels of a typical Java web application in a somewhat sarcastic-al tone. Summarizing his points:
Coté does go on to say that some abstractions such as file systems, sorting algorithms, collections work well for Java. However in general he feels:
- By the time you’ve written your abstraction layer, you’ve essentially written your own framework. Chances are, you’re not a good framework writer, and it’s going to suck, and you’re going to realize that one or two versions down the road and re-write it.
- New frameworks and ways of building applications will come along that you want to use (web applications, clustering, Ajax, mobile access) that don’t readily map to the metaphors, idioms, and expectations of your abstraction layer. At this point, you’ll get upward leak as the new things you want to do are bolted onto your abstraction layer.
- The chief reason it’s crap, and to Bill’s point, is that you’ll always be sacrificing fully taking advantage of things you’ve abstracted away, or making them harder.
The theory is then suggested that developers using technologies such as LAMP, Ruby, and Django see themselves as building web applications. Java developers on the other hand are more of the mentality that they are building an application which happens to have a "view" of the web.
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
Monitor your Production Java App - includes JMX! Low Overhead - Free download
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
Agile Practices to Improve Project Management Organization (PMO) Effectiveness
18 agile and lean practices for effective software development governance
To me, it seems like the Java Web Frameworks were built by Java Developers, whereas PHP, Ruby and Python frameworks were built by web developers. Java frameworks target Java developers, the others target web developers. It'd be cool if a Java web framework targeted web developers, but that may be difficult to do.
The only point that I got from this article is that when programming in Java *people* tend to abstract things too much. In case of JSF that's certaintly true.
But look at Spring MVC. It's the most powerful way to plug into any part of the HTTP request/response lifecycle along the lines of the MVC pattern. And yet it's pretty intuitive to use since you can ignore the intersection points you're not interested in.
As far as I understand Rails and Django also implement the MVC pattern.
I guess I don't get the point of this article, at all.
I guess the topic of replaceability of the underlying technologies was already discussed multiple times and I guess this article raises it again, when author considering replacing technologies usecase as irrelevant I strongly disagree, because of different development environments, different OSs and flexibility we gain from these abstractions.
When you look at things like RoR it's like they were designed to build prototypes... No referential integrity? Who needs it anyway? We won't ever need more than one way to do x, y, or z, so let's make it really hard to do it any way but the way we've hard-wired in. That's more like using Microsoft (our way or the highway) tools.
Sure, abstraction can be taken too far *cough*JSF*cough* but it's put in there for a reason, because we've seen these needs before and we don't want to paint ourselves into a corner.
I guess the topic of replaceability of the underlying technologies was already discussed multiple times and I guess this article raises it again, when author considering replacing technologies usecase as irrelevant
I don't know what camp Michael Coté is from, but even Guido van Rossum (as in Python creator) expressed his concern about the web framework technology lock ins.
bests,
./alex
--
.w( the_mindstorm )p.
________________________
Alexandru Popescu
Senior Software Eng.
InfoQ TechLead&CoFounder
Java plain sucks for web apps.
The only thing that'll save it is Grails.
That'll be 25 bucks.
--Johnny "Article Writer" Bravo
When you look at things like RoR it's like they were designed to build prototypes... No referential integrity? Who needs it anyway? We won't ever need more than one way to do x, y, or z, so let's make it really hard to do it any way but the way we've hard-wired in. That's more like using Microsoft (our way or the highway) tools.
Sure, abstraction can be taken too far *cough*JSF*cough* but it's put in there for a reason, because we've seen these needs before and we don't want to paint ourselves into a corner.
Jason, c'mon. The FUD is a bit much. There's nothing in Rails that negates referential integrity, and I haven't heard anyone (realistically) say there's no need for it. And, last I checked, it's in the database, where Rails can neither dictate its absence nor presence. Nor is Rails "really hard" to do many, many things that are defaulted.
Webwork is great - I have a commercial site on it. But other things can be good too. And lastly, Rails never proposed to be the end-all be-all. It's SUPPOSED to be for the one corner you seem so afraid of being in. Granted, some zealots have tried to make it be a lot more than that, so blast those zealots, not the framework.
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.
7 comments
Watch Thread Reply