Distributed computing in Persevere and Jsponic

[Kris Zyp]

Some of the key ideas behind the Jsponic and Persevere architecture:

• High degree of interoperability - There are certainly more optimal communication protocols, but I can utilize JSON and JSON (emerging) standards: JSON-RPC, JSONP, JSPON, JSONPath, REST/HTTP to do just about everything needed for fairly efficient and highly capable distributed computing. This makes it easy to have Jsponic interoperate with other client technologies, or Persevere interact with other server technologies. There are decoupled through these standards. Like I said, I am hoping that interacting with the server is so simple just using regular REST, that anyone could create a JS client to talk with it (or server). Of course Persevere gives you all the bells and whistles, but anything could use it as a web service. I have actually been talking to someone who wants to use Persevere for a Ruby on Rails framework he is building (http://scaffold.jupiterit.com). This had led me to strip away a lot of the extraneous stuff in JSPON, basically relies on plain REST commands to do everything now, so that it will hopefully work with RoR. All of our discussions around referencing have also caused me to change the way referencing is done in JSPON to make it simplier and more flexible, to allow for both id and path referencing (yes I did compromise).
• Ease of programming - I have tried to keep the data access agnostic of the storage medium. That means SQL db tables, XML files, and OODBs (which are all included plugins) are all mapped to regular JavaScript objects. Programming can deal with normal JS objects, modifying and accessing them without needing to know what is used on the backend. You can literally swap out a SQL table with an XML file without changing your application code. This works very nicely for distributed computing, one simple model (just regular objects really) is used everywhere, and even transient objects can be transferred and dealt with the same way as persistent objects. For example, I can do an RPC with parameters including a new object, a reference to an object mapped to an sql row, and an object from a remote server all in one object. And I as mentioned, to further provide a transparent distributed computing experience, Jsponic and Persevere both implement the same peristence model and the same API (in Rhino in the server environment). When an RPC is invoked, they both are dealing with the same |this| object, and the same objects can be used through referencing. And with persistence mapping involved, if a client modifies a persistent object, and then does an RPC to the server, the persistent object modification is sent to the server and then RPC is sent, so persistence helps keep the remote environments in sync without having to transfer the entire environment/object graph with each RPC, just references (and any changes). This permits the scalable levels of efficiency.
• While it is designed that any agent can participate in the computing environment through REST commands and RPCs, there are certain technologies that permit an extra level of transparency in distributed computing. One is the use of continuations. If you want a truly pure transparent distribution, continuations are critical for doing things like transparent lazy loading in property access, and making methods calls that are executed as RPCs, but do not require a callback. Now continuations are certainly an optional feature, but they do allow the highest level of transparency.

Here is some examples of how you could build a simple app and work with it in Persevere and Jsponic

Persevere client JavaScript actions	Resulting HTTP communication
// get the root of the object database root=pjs.load('root');	GET /root <--- {... root data...}
root.recipes = []; // create a recipes array, no need to create a table, just do it with JS!	PUT /root.recipes []
// query a foods SQL database table (assuming it is plugged into Jsponic) oatmeal=pjs.load('foods/[?(@.name="oatmeal")]')[0]; // query using JSONPath cookie=pjs.load('foods/[?(@.name="cookie")]')[0];	GET foods/[%3F(@.name="oatmeal")] <--- [{"id":"foods/34",  "name":"oatmeal",  "calories":77}] ...
oatmealCookies = {ingredients:[oatmeal,cookie]}; // just mix oatmeal and cookie, right? root.recipes.push(oatmealCookies);	POST /root.recipes {"ingredients":[{"$ref":"foods/34"},{"$ref":"foods/47"}]}
recipeApp={calcCalories:function(recipe) {     var cals = 0;     recipe.ingredients.forEach(         function(ingredient){             cals+=ingredient.calories;         });     } }; recipeApp.calcCalories.runAt="server"; root.recipeApp = recipeApp; //attaching it to a persistent object will persist it	PUT /root.recipeApp {"calcCalories":{"function":"function(recipe){....","runAt":"server"}} (this is the convention I use to pass functions so that it stays pure JSON)
var cookieCalories = recipeApp.calcCalories(oatmealCookies); // this executes the RPC, the function will be executed on the server (in Rhino) cookieCalories --> 290	POST /root.recipeApp {"id":"call1","method":"calcCalories","params":[{"$ref":"/root.recipes[0]"}]} <--- {"id":"call1","response":290, "error":null}
// lets load a recipe from a different server, we are now a mashup! foreignRecipe = pjs.load('http://foreignrecipes.com/sushi');	http://foreignrecipes.com:  GET /sushi <--- {"ingredient":[....]}
//and stick it in our array/table of recipes root.recipes.push(foreignRecipe);	POST /root.recipes {"$ref":"http://foreignrecipes.com/sushi"}   a get on root.recipes would now return [{"ingredients":[{"$ref":"foods/34"},{"$ref":"foods/47"}]},{"$ref":"http://foreignrecipes.com/sushi"}]

I didn't include it in the example, but the PUT and POST operation return the newly created objects, with their new ids, which can be used for referencing, which is safer for concurrent DB modifications. If you download Jsponic, the examples-persisted.html gives a good example of distributed computing, there is a call to method that searches through customers on the server. Anyway, that is an overview of my approach to distributed computing.