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 Abel Avram on May 13, 2009
In this interview Joseph Yoder talks about the Adaptive Object Model (AOM) architecture, a software architecture for easily adapting to changing business requirements.
Watch: Joseph Yoder on Adaptive Object Model Architecture (27 min.)
Yoder explains the difference between the classical object model and the adaptive one. Instead of modeling the entities of a domain and their behavior with classes, one can model them with descriptive information (metadata) stored, for example, in an XML file or a database. If the behavior or the entity attributes need to change, that can be easily done by deploying a new XML file without having to touch the code.
Ralph Johnson, Gang of Four patterns co-creator, explained the role of the metadata in the adaptive object model:
Metadata is just saying that if something is going to vary in a predictable way, store the description of the variation in a database so that it is easy to change. In other words, if something is going to change a lot, make it easy to change.
The problem is that it can be hard to figure out what changes, and even if you know what changes then it can be hard to figure out how to describe the change in your database. Code is powerful, and it can be hard to make your data as powerful as your code without making it as complicated as your code. But when you are able to figure out how to do it right, metadata can be incredibly powerful, and can decrease your maintenance burden by an order of magnitude. Or two.
The adaptive object model is not to be use anywhere, anytime. Yoder gives examples where AOM is used, talks about AOM patterns, the need for model validation and security.
"Metadata is just saying that if something is going to vary in a predictable way, store the description of the variation in a database so that it is easy to change. In other words, if something is going to change a lot, make it easy to change."
In another story from the famed magazine, "Obvious," apparently the sky is blue and water is (wait for it)... wet!
The trick to the whole shebang is recognizing the areas of variability. No framework will ever help with that, that's something the human taking the requirements has to recognize.
E-A-V can play into the persistence layer for this approach. I think he's including more than just the data layer; he's also discussing the mid-tier, which could be coded in an O-O language. In that case, there's more than straight EAV modeling, since you still want to employ the o-o features in the implementation.
People also refer to archetypes when describing this. See www.openehr.org/releases/1.0.2/architecture/ove... for another example implementation.
It's not all bad that we rediscover the same idea and approach. It helps validate that the pattern is valid and applicable.
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.
3 comments
Watch Thread Reply