Ok, time to geek out and talk about the technology behind APPLEBOX. Whilst we think our model for the local DVD store is a winner (we’ve reduced store overheads, embraced the Internet and kept a strong sense of local community even from the web) we also completely love the technology! Forget Rails, we’ve got a J2EE web stack that we think is second to none. Check it out:

• Our architecture is SOA (Service Oriented)
  All our application calls are SOAP, which from the ground up creates an API we will give public exposure to at a later date. For example this call returns a movie profile.
• Our storefront is Serverless AJAX
  The Web 2.0 movement has swept AJAX into the mainstream. We take that one step further and deliver our complete application as Serverless AJAX that makes stateless SOAP calls to our backend.
• Our development process is Model Driven (MDA)
  Rails gives the Ruby community productivity. For us, MDA gives J2EE a similar shot in the arm. Our complete stack with stubs for all business methods and web services, a default CRUD service layer, and all the J2EE XML config files are generated from a UML model. We can iterate from UML through to database and service layers in a matter of minutes. The MDA generator we use is AndroMDA.
• Our J2EE components are
  Axis (Web Services), Acegi (Security), Spring (Transactions), Hibernate (ORM), MySQL (Database) and JBoss (App Server).

The key to everything we do is the Serverless AJAX. As I mentioned in a previous post, we take the Single Page Application model, and chain multiples of them together as iframes within the browser. These SPAs are housed within a JavaScript controller that moves between each SPA as the application requires it. This is standard MVC, but the C and the V are in the browser, rather than on the server. So we’ve got:

• Static delivery of htm/js SPAs to the browser (no dynamic markup). All SPAs can be downloaded at startup or on request
• A stateful htm/js client where UI components persist until the app is closed
• Full containment of the view & controller in the browser
• A JavaScript controller that binds multiple SPAs together all with interfaces that can be called directly from other SPAs or from the main controller. With a pub/sub mechanism each SPA can publish and subscribe to global application events as well.

This is good because:

• The static htm and js resources can truly act as an application client, cached in the browser for next use. Cache headers are set to never expire, with versioning controlled within the URIs themselves (configured from a non-cacheable boot script).
• Each UI keeps its own state. For eg, when the user manipulates a page (eg magnifies the poster art, or respositions a cover strip), when they come back to that page it’s the same as when they left it.
• UI widgets don’t need to be rebuilt when navigating back.
• The complete JavaScript framework and model remain in memory. No reparsing thousands of lines of JavaScript to reload the object model that was there an instant ago.

Additionally:

• This scales well as repeat app use hits the server only for data. No pushing out reams of html, and app navigation is much less server bound.
• We build our backend as an application API from day one. We can re-use the same application services for other clients. Eg, our catalogue services are used in the public storefront, in our in-house administration systems, and from our testing framework. As SOAP services, we can also call these from Flash, Silverlight, or a native Win or Mac client if we wished. We can also choose to freeze a subset of the API and offer them publicly.

This stack works for us and delivers great productivity. To see it all in action, just click through to applebox.com.au and hit ‘Browse DVDs’!

Posted December 5th, 2007 under Technology and Coding.
Comments Feed: RSS 2.0. Responses are currently closed, but you can trackback from your own site.