A Taste Of InfoGrid
by InfoGrid.org on Jul 06, 2009
- 11,563 views
Statistics
- Favorites
- 5
- Downloads
- 22
- Comments
- 0
- Embed Views
- Views on SlideShare
- 11,431
- Total Views
- 11,563
-
rrahulhansuka
1 year ago
-
Lucas Thompson
, Software Architect
at Teachers Media International Inc.
Tags nosql graphdb infogrid neo4j
2 years ago
-
lenyabloko
Tags nosql
2 years ago
-
abielk
2 years ago
-
satake akira
, students
at Univ of Keio
2 years ago
A Taste Of InfoGrid — Webinar Transcript
- A Taste of InfoGrid™ This presentation contains 6 slides (with build-ups). Please listen to audio as you go through the slides, or read through the notes. July 2009 infogrid.org
- How Do You Build Your Web Applications? Ruby on Rails J2EE Python PHP .NET … infogrid.org
- RDBMS-Centric Architecture Browser Browser Browser Browser Browser Browser Browser Browser Browser Application Application Application Server Server Server RDBMS infogrid.org
- RDBMS-Centric Architecture Browser Browser Browser Browser Browser Browser Browser Browser Browser Major problems: 1.RDBMS joins don’t scale. Application Application Application Server Server Server RDBMS infogrid.org
- RDBMS-Centric Architecture Browser Browser Browser Browser Browser Browser Browser Browser Browser Major problems: 1.RDBMS joins don’t scale. Application Application Application 2.Tables are not web native at all. Server Server Server RDBMS infogrid.org
- RDBMS-Centric Architecture Browser Browser Browser Browser Browser Browser Browser Browser Browser Major problems: 1.RDBMS joins don’t scale. Application Application Application 2.Tables are not web native at all. Server Server Server 3.Most of the data important to applications lives elsewhere. RDBMS infogrid.org
- High-Level InfoGrid Features • (Blob) Store abstraction w/ a variety of implementations • RDBMS joins (e.g. files, MySQL, Hadoop, S3…) and automatic mapping don’t scale • Conceptual model/schema w/ run-time enforcement • Tables are not web native at all • Most of the data important to applications lives elsewhere infogrid.org
- High-Level InfoGrid Features • (Blob) Store abstraction w/ a variety of implementations • RDBMS joins (e.g. files, MySQL, Hadoop, S3…) and automatic mapping don’t scale • Conceptual model/schema w/ run-time enforcement • Graph traversal instead of joins • Tables are not web native at all • Most of the data important to applications lives elsewhere infogrid.org
- High-Level InfoGrid Features • (Blob) Store abstraction w/ a variety of implementations • RDBMS joins (e.g. files, MySQL, Hadoop, S3…) and automatic mapping don’t scale • Conceptual model/schema w/ run-time enforcement • Graph traversal instead of joins • All data objects automatically have a URL (REST-ful); • Tables are not multiple output representations for each URL web native at all • Most of the data important to applications lives elsewhere infogrid.org
- High-Level InfoGrid Features • (Blob) Store abstraction w/ a variety of implementations • RDBMS joins (e.g. files, MySQL, Hadoop, S3…) and automatic mapping don’t scale • Conceptual model/schema w/ run-time enforcement • Graph traversal instead of joins • All data objects automatically have a URL (REST-ful); • Tables are not multiple output representations for each URL web native at all • Objects can change type(s) at run-time • Most of the data important to applications lives elsewhere infogrid.org
- High-Level InfoGrid Features • (Blob) Store abstraction w/ a variety of implementations • RDBMS joins (e.g. files, MySQL, Hadoop, S3…) and automatic mapping don’t scale • Conceptual model/schema w/ run-time enforcement • Graph traversal instead of joins • All data objects automatically have a URL (REST-ful); • Tables are not multiple output representations for each URL web native at all • Objects can change type(s) at run-time • Cached in memory until not needed any more • Most of the data important to applications lives elsewhere infogrid.org
- High-Level InfoGrid Features • (Blob) Store abstraction w/ a variety of implementations • RDBMS joins (e.g. files, MySQL, Hadoop, S3…) and automatic mapping don’t scale • Conceptual model/schema w/ run-time enforcement • Graph traversal instead of joins • All data objects automatically have a URL (REST-ful); • Tables are not multiple output representations for each URL web native at all • Objects can change type(s) at run-time • Cached in memory until not needed any more • Most of the data • XPRISO and Probe framework automatically make important to external data appear as local/native applications lives • Automatic/adaptive, incremental updates w/ events elsewhere • Library of Probes infogrid.org
- High-Level InfoGrid Features • (Blob) Store abstraction w/ a variety of implementations • RDBMS joins (e.g. files, MySQL, Hadoop, S3…) and automatic mapping don’t scale • Conceptual model/schema w/ run-time enforcement • Graph traversal instead of joins • All data objects automatically have a URL (REST-ful); • Tables are not multiple output representations for each URL web native at all • Objects can change type(s) at run-time • Cached in memory until not needed any more • Most of the data • XPRISO and Probe framework automatically make important to external data appear as local/native applications lives • Automatic/adaptive, incremental updates w/ events elsewhere • Library of Probes Plus: GUI template framework, complex traversals and events, ability to distribute P2P-style, modules, identity awareness and much more… infogrid.org
- Why InfoGrid Matters (We Think) Makes a lot of development work unnecessary ➡ faster development ➡ higher application quality ➡ higher deployment flexibility ➡ lower development cost infogrid.org
- Why InfoGrid Matters (We Think) Makes a lot of development work unnecessary ➡ faster development ➡ higher application quality ➡ higher deployment flexibility ➡ lower development cost No more: Database sharding in the application layer, O/R mapping, custom data import, code for event detection and generation, spaghetti code mixing data access/storage/refresh/GUI, total rewrites for S3/Hadoop/... infogrid.org
- This concludes: A Taste of InfoGrid™ For more information: infogrid.org infogrid.org
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.