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 Nov 11, 2008
SpringSource announced today the acquisition of G2One, the company behind Grails and Groovy. From the press release:
...With the acquisition of G2One, SpringSource will now offer global enterprise support offerings for developers and IT operations that utilize Groovy and Grails applications ... “Like Spring, Groovy has become a powerful cornerstone of today’s application infrastructure, driven by mass developer adoption worldwide,” said Rod Johnson, CEO of SpringSource. “The combined forces of Spring and G2One not only accelerate innovation, but also deliver SpringSource’s 24x7, global support network to the growing number of enterprises adopting Groovy at the heart of their applications.”...
InfoQ sat down with SpringSource CEO Rod Johnson and G2One CTO Graeme Rocher to discuss the acquisition. Johnson began by saying that Grails and Groovy are technologies that SpringSource believes in and therefore it made sense to invest in. SpringSource has noticed a significant growth in dynamic languages with the download numbers for Grails increasing 10x in the last 12 months. In terms of how the deal came together, both indicated that mutual interest had been present for a while and that an acquisition would allow them to work closer than if just a partnership had occurred. Johnson went on to mentioned that he is excited to raise the profile of Grails as well as being able to integrate Groovy/Grails across the SpringSource product line in technologies such as SpringSource dm Server. Rocher noted that he expects Groovy and Grails to be able to take advantage of SpringSource's experience in building Eclipse tooling support. In addition to an interview with InfoQ, Johnson also blogged on the acquisition headlining with "More Weapons for the War on Complexity". In the post he commented on why Groovy instead of JRuby:
"...There’s plenty of buzz around Ruby on Rails. Grails—of course, benefiting from the experience of Ruby on Rails—offers the same benefits, but without the many serious impediments to use in the enterprise that face RoR. With Grails, you can enjoy rapid application development and programming in a dynamic language without needing to throw away your investment in Java middleware; without the need to make inefficient web services calls to talk to functionality coded in Java; without losing the benefits of sophisticated O/R mapping; without the risk of hitting a wall with scalability or enterprise capabilities; without adopting an unfamiliar programming language for all your coding..."
Finally the company has posted a FAQ on the acquisition. Among the highlights are the fact that Spring and Groovy/Grails will remain Apache licensed.
Mobile and the New Two-Tiered Web Architecture
18 agile and lean practices for effective software development governance
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
Soon there will be groovy enterprise edition, for paying customers. And/Or grails enterprise edition, for paying customers.
What a pity :(
This solidifies Groovy's place as an industry standard. Spring's paradigm shift was one of the driving forces behind the design of JEE 5 and frameworks like Seam (although I'd argue Spring still wins in terms of capability). I expect Groovy will have the same impact.
This solidifies Groovy's place as an industry standard
An industry standard for what? For Groovy-like scripting languages?
Agree with Ron,
Can Graeme clarify what will be the direction and future support for Grails and Groovy ? Spring is about Enterprise, will Grails and Groovy eventually become "too enterprise/springy" that make it harder to learn and use ?
I disagree with Ron
SpringSource just bought the company and will hire 6 people from G2one inc.
Groovy and Grails will keep their Apache 2 License, and I don't see how one could make Groovy hard to learn. The community already offers strong support on Groovy and Grails.
It's a very good news for the Groovy language and Guillaume Laforge, groovy's author.
Please, read also Guillaume Laforge own comment about this :
glaforge.free.fr/weblog/
See also news arround this story (in French) :
Didier Girard's Blog
Le Touilleur Express
Spring is about Enterprise, will Grails and Groovy eventually become "too enterprise/springy" that make it harder to learn and use?
Grails has always been built on Spring, and demonstrates what a good basis Spring is for such a simplifying solution. I know that Graeme and his team will continue to make Grails even easier to use...
@geekcoder
There is a lot of information available about the direction and future in the FAQ at www.springsource.com/g2one
And on my blog at graemerocher.blogspot.com/2008/11/groovy-and-gr...
What I will emphasize is how thrilled I am that the acquisition has become a reality, both Groovy and Grails will get a lot of benefit from being part of the Spring family.
"Grails and Groovy eventually become "too enterprise/springy""
What I mean is whether the Spring will be more exposed and coupled to Grails's public API.
That's a good news to hear that Grails will retain its ease of use.
Graeme, thank for the info. Will read it up.
Congrats! I agree with Tom Nichols, this should solidify Groovy and Grails as an industry standard. It also might make it easier for me to convince our manager that we can use it on our clients who are scared of new technology!
An industry standard for what? For Groovy-like scripting languages?
Why such negativity?
Groovy is nice as standard scripting language in JVM.
I will take one thing that works over dozen promising but incomplete and buggy any day
An industry standard for what? For Groovy-like scripting languages?
Why such negativity?
Groovy is nice as standard scripting language in JVM.
I will take one thing that works over dozen promising but incomplete and buggy any day
There's no negativity about Groovy, it's a nice system. I just take exception with it being regarded as a the standard JVM scripting language. You might find there are a few other contenders (JRuby, Jython, etc) that will contest that claim.
Andrew
geekycoder, would you please edit your preferences page and put in your real name? We do not support aliases here as we feel it takes away from the culture we are trying to build on InfoQ. We may delete your posts in the future if we don't see any change.
thanks,
Floyd
An industry standard for what? For Groovy-like scripting languages?
In the same way Spring has become an "unofficial standard." Not in the strictest JSR-sense, but in the way the Spring framework filled the vacuum where there was no standard tool for simple enterprise development.
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.
14 comments
Watch Thread Reply