We are re-architecting the RAFT application to accomplish the following:
- Make it easier to add new features
- Make it possible to unit test the application
- Make it possible to functional test the application
- Make it easier for new developers to understand and work on the code
- Make the code more modular
- Prove that a modular, extensible skeleton based on a known JavaScript MVC framework (Can.js in this case) can make application development fast, simple, repeatable and manageable.
- Try to discover the required documentation needed for a software development project: what is needed for project management, requirements, design, development, testing, and help.
The RAFT application basic security configuration and application structure is:
Security is initiated by sending users from the app to a Shibboleth login. If the user successfully authenticates, they are routed to a php file that begins a RAFT session and authenticates every subsequent call against the Shibboleth token. After that, every AJAX and http call is routed through that php session and checked for the Shibboleth token. If it is not there or has expired, the call is refused. Every 10 seconds, the front-end makes a "heartbeat" AJAX call to the middle tier. If the database layer is down or the person is not authenticated the heartbeat call will return this message and end the user's session.
- 3-Tier View: The html the user sees is coded in a JavaScript single-page-application framework called CANJS (http://canjs.com). This framework is loaded via one page, app.html. That page bootstraps the entire front-end Model-View-Controller framework, which in turn makes AJAX calls to the REST stack.
- This middle-tier REST stack is implemented in the php framework called Zend. Zend also internally uses an MVC framework. This middle-tier calls Oracle PL-SQL stored procedures that represent the RAFT back end.
- Front end setup
- RAFT front end configuration