A Taste Of InfoGrid
by InfoGrid.org on Jul 06, 2009
- 13,562 views
Statistics
- Likes
- 5
- Downloads
- 41
- Comments
- 0
- Embed Views
- Views on SlideShare
- 13,430
- Total Views
- 13,562
rrahulhansuka
2 years ago
Lucas Thompson, Software Architect at Teachers Media International Inc.
3 years ago
lenyabloko
3 years ago
abielk
3 years ago
satake akira, students at Univ of Keio
3 years ago
A Taste Of InfoGrid
And if you’d like more than a taste, go get seconds at infogrid.org.
I’m sure you know some developers who are almost religiously convinced that their language of choice is vastly better than some other languages on this chart.
But the truth is that all of these approaches are much closer to each other than it might look, because they all use the same architecture.
The RDBMS-centric architecture assumes that there is a single relational database for the application. This database is accessed by one or more application servers in the languages we discussed, and serves so many concurrent users with web browsers.
The RDBMS-centric architecture was well established long before the web, and has been essentially the same for the past 40 years. But in the age of Web 2.0, it is showing its strains:
But today, with RSS feeds, web services, social networking, internet identity like OpenID, outsourcing relationships, dashboards and the like, much of the data in our applications comes from elsewhere and is managed elsewhere. Often the maintainers of that data don’t even know that our application exists. Nevertheless that data must be accessed by our application, processed, cached, updated, integrated and reconciled with data from other sources, and much more; the dirty secret is that an RDBMS-centric architecture cannot help us with that at all.
These are some of the reasons why we designed the InfoGrid platform. Applications built on InfoGrid don’t run into these problems.
What the developer sees is objects that are instances of a conceptual model or schema. These instances may be typed and may be related to each other, so together they form a graph with nodes and edges. If you are familiar with conceptual information modeling or object modeling like the UML, or semantic modeling with OWL or the semantic web, you will feel right at home. The model or schema of any InfoGrid application is automatically enforced by InfoGrid at run-time.
For example, if you defined a type called Customer for your InfoGrid application, and one called Order, and a relationship that expresses that Customers Place Orders, InfoGrid makes sure that only customers can place orders. If you wanted somebody else to also be able to place orders, you would create another allowed relationship. If you said that customers can be in one of good standing, late or delinquent, that’s all they can be unless you change the model. You get the picture.
It’s important to understand that because of this, the performance characteristics of InfoGrid applications are different from traditional web applications. Many InfoGrid graph traversal operations are exceedingly fast, and can be parallelized much more effectively for high-volume applications than they could with a relational model. However, some are slower, such as, say, ranking all customers by sales volume. It’s important to understand that tradeoff.
Going slightly beyond REST, InfoGrid supports multiple output representations per URL. For example, all objects can be edited with a PropertySheet that comes with InfoGrid. Application developers can add as many representations as they like, whether using different MIME types like HTML, XML or JSON, or different formatting within the same type like an overview, or detailed form. One of their customers doesn’t like the way some object is formatted? Give them their own version.
Again, this is a very web-centric view of the world: given a URL, over some period of time, all kinds of data might be served at that same URL. Conceptually, in InfoGrid, a single object resides at that URL, whose types may change over time.
You might say: many people have done that. True. But what they usually have not done is to keep the local copy in sync with the external copy after the initial import. When the external information changes, InfoGrid detects that and incrementally applies the detected changes on the local objects, just as if those changes had been made locally. Application developers don’t need to write code to figure out what to do when external information changes, which is a major expense and quality issue in many applications built on a traditional architecture.
Naturally, InfoGrid developers have a great amount of freedom in defining when updates occur. Timing is very configurable, just like everything in InfoGrid. And before you ask, yes, information can also be automatically written back to the external data source.
So any kind of external information can be treated as if it was a graph of local objects in InfoGrid. InfoGrid provides a library of Probes for common formats, but it is straightforward to build new Probes. We should mention that InfoGrid also caches all external information, so an InfoGrid application doesn’t need to go down just because some web service invocation failed – a scourge and major expense for applications built on less powerful foundations.