Disambiguation and Homnyms
It didn't ask me what I meant by "jaguar", or provide a "did you mean" option. Maybe someday.
« July 2006 | Main | September 2006 »
It didn't ask me what I meant by "jaguar", or provide a "did you mean" option. Maybe someday.
Essentially everyone, when they first build a distributed information system, makes the following eight assumptions about the data. All prove to be false in the long run and all cause big trouble and painful learning experiences.
Roy Fielding: "With the JSR170, and what's currently JSR283, we're trying to take the same engineering principles and architectural principles that we apply to the web, and try to see what's applicable to inside the application server, or inside the server based implementation of server based applications"
[the podcast entire is highly recommended for people who want to get some background history on the Web and REST architecture.]
Zope/ZODB is the most mature implementation of JSR170 I know of. The JSR170 content model is hierarchical, just like ZODB (and any interesting content model built on top, like CMF and Archetypes).
Here's the diagram from the JSR170 spec:

Anyone who ever had to explain Zope will be familiar with that kind of picture. The desirable characteristic about a tree based model is that you can store any data format in it, without hardcoding domain models and rulesets. By extension you can do this also with labelled graphs, which is how RDF gets to claim its high flexibility, being a graph based model. In an RDBMS you need to know the domain model to define tables and then you need to know the rulesets to decide what are integrity constraints and what are application specific concerns. To get a sense of the engineering work involved in trying to make an RDBMS flexible read Scott Ambler's Agile Database Techniques. It's possble, maybe, but not cheap to do. To be clear - preferring to manage content *as content*, instead of lossy extraction of domain entities is about preferring flexibility and independent evolution of systems. There's plenty of room for an argument that says RDBMS is suboptimal for managing content. And good luck with versioning or translation on top of relational databases while trying to manage the form and flexibility of the content over time. Yes, you can do it, but it's highly specialised and diffiicult work.
I doubt the backend storage is easily commoditised for tree based content. Like JCR, ZODB is ultimately an API but physical storage is difficult to abstract away for hieriarchal content models. It's not clear, at all, that RDBMS can sanely support a hieriarchal content model for the long haul. RDBMS is the gold standard for enterprise data management and JCR170 as a Java API plays squarely in the enterprise space. "Everyone" wants an RDBMS backend - not for the data itself, but for operational simplicity, enterprise IT rationalisation, and the predictable performance characteristics. It's tough to know what the right tradeoff is. Ignoring RDBMS tech suggests not taking enterprise concerns seriously and risking IT ops and predictability in systems design and management. Ignoring the content and data longevity concerns suggests you end up preferring expensive non-repurposable silos than allowing the business to function well. I think these are not mutually exclusive positions, but getting the balance right is tough.
Amazon Elastic Compute Cloud (Amazon EC2) - Limited Beta:
"Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale computing easier for developers. Just as Amazon Simple Storage Service (Amazon S3) enables storage in the cloud, Amazon EC2 enables "compute" in the cloud. Amazon EC2's simple web service interface allows you to obtain and configure capacity with minimal friction. It provides you with complete control of your computing resources and lets you run on Amazon's proven computing environment. Amazon EC2 reduces the time required to obtain and boot new server instances to minutes, allowing you to quickly scale capacity, both up and down, as your computing requirements change." Amazon EC2 changes the economics of computing by allowing you to pay only for capacity that you actually use.
"Dad, will you turn on Google. I want to play miniclips"
Flickr image roll:


"There's a Google Summer of Code project for that"
I hope all those projects work out ;)
* I remember Pat Lightbody asking this a few years back; Pat works on WebWork :) RestfulActionMapper is very cool if you don't get hung up on parameter ordering. For example, JIRA 4 might be able to stop using .jspa extensions and have cacheable ticket queries and Confluence's feedbuilder could use this to produce clean URLs.
Quick, somebody parallelize ispell. Suffice to say, Google aren't using dictionaries.
You are viewing a mobilized version of this site...
View original page here