SAU, Window.Name, JSON-RPC

Tuesday 23 March, 2010 by moschel

A few weeks ago, I went out to Chattanooga to give 3 days of JavaScriptMVC training to Southern Adventist University.  I was blown away by the university's technology expertise.  To my shame, I wasn't expecting a small college to have such sophisticated engineers.   But, it wasn't that small! There are 66 sister school associated with SAU.  SAU's problem was that each of those sister schools had their own way of doing things.  There was almost no reuse.  SAU's challenge was to create an architecture that would pave the way for reuse, where one school could leverage the application of another.

Fortunately, their architecture choice was light-years past what many cutting-edge technology companies might try.  This article describes the architecture, why it kicks ass, and how I and JMVC helped them.

SAU is working on, what I call, a "Thin Server, Window.Name, JSON-RPC" architecture.  Let me break that down.

Thin Server Architecture

Thin Server Architecture generally means having the client do as much as possible, especially creating HTML on the client with templates like EJS.  The server simply exposes reusable services that a client (a JavaScript enabled browser) can consume.  

Window.Name

Window.Name is a Ajax-y transport mechanism that allows secure cross domain requests.  This technique was first made well known by a friend of Jupiter's, Kris Zyp, in a SitePen article.  It uses the window.name property and iframes to send data to other domains.  To make it work from your server, you just have to have your server send back JSON data wrapped like:

<html>
<script type="text/javascript">
  window.name = document.getElementsByTagName("script")[0]
    .innerHTML.match(/temp\s*=([\w\W]*)/)[1];
  temp= {foo:"bar", // put json data here
        baz:"foo"}
</script>
</html>

And send requests with a good window.name transport like WNT.

JSON-RPC

Json-RPC is another project worked on by my hero Kris Zyp.  It is a standard for calling methods on your back-end services and has a proposal for exposing service descriptions. 

A service description of a create method might look like:

work_order: {
  "SMDVersion": "2.0",
  "contentType": "application/json",
  "envelope": "JSON-RPC-2.0",
  "methods": {
    "create": {
      "envelope": "JSON-RPC-2.0",
      "parameters": [{
        "name": "attributes",
        "optional": false,
        "type": "array"
       }],
      "returns": "string",
      "transport": "POST"
     }
}

And here's what data you might send and get back to that service:

--> { "method": "create", 
      "params": [{'name': "bathtub"}], 
      "id": 1}
<-- { "result": "{'id': 5}", 
      "error": null, 
      "id": 1}

Putting it all Together

SAU's plan is to create a JSON-RPC service for tables and databases across their 66 sister schools.  By using introspection on the database and tables, they can expose basic CRUD services for any database without writing additional code.   

SAU also allows cross-domain JSON-RPC requests through the Window.Name transport.  This means that any engineer can manipulate their services securely (after logging into that service).  They can even use these services from web-apps running on the filesystem.

How Jupiter and JMVC helped

I created a JSON-RPC model and custom scaffolding for SAU.  Using the scaffolding, they could generate a basic CRUD interface to any of their tables.  This let SAU develop against these services immediately. 

Why this Kicks Ass

This architecture elegantly solves their core problem and hopefully will dramatically improve their development times.  First, it benefits from Thin Server Architecture:

  • Reusable services
  • Parallelized development
  • Separation of concerns

But by using a custom scaffolding and window.name transport, anyone in their development team can create a new app that mashes-up existing data in mere seconds.  They simply have to scaffold their data sources and get presented with the following:

Sae

This is an image of a real app connecting to temporary database data vai JSON-RPC and window.name.  

I strongly suggest checking these technology choices out.  It can greatly enhance development time, and make your IT support guys' lives a lot easier.

Subscribe to:

Related Content

Copyright ©2007-2010 Jupiter IT.