Categories: Home | Project Blog Year 3 and 4 | PALET Project Overview | Project Blog Year 1 and 2
![]() |
PALET - The Programme Approval Lean Electronic Toolkit Project | ![]() |
||
![]() |
![]() |
Holy Grails - A Groovy Solution
One of the main PALET project requirements was to create a single source of course data that can be reused across our corporate systems. This will provide students with a consistent view of programme and module descriptions irrespective of which system they are using e.g. school web sites, prospectus, VLE, printed handbooks and so on.
To achieve this we firstly extract, transform, and load data from our student records system to our data hub giving us a clean and simple structure to report from.
To allow access to this information it was decided to use a Representational state transfer (REST) architecture to provide standard web services. These can be used by schools to reuse the data as they wish, and allow other systems to consume the data.
Development of the RESTful service was undertaken in house using Grails (http://grails.org/). This is an open source web framework, which uses the Groovy programming language (which is in turn based on the Java platform). Grails incorporates Hibernate and Spring frameworks under one umbrella. It is intended to be a high-productivity framework by following the "coding by convention" paradigm, providing a stand-alone development environment and hiding much of the configuration detail from the developer.
It has been a challenge to get Grails to work with a legacy database. The framework works best when you allow it to control the database design and constraints. Once the framework ‘understands’ our database design, the process to create the services and map URL’s is very easy. Building functionality so that users can switch between output formats e.g. html, json, xml works very well.
The architecture used in this project is the first of its kind in Cardiff University and is rapidly becoming the standard to produce a whole catalogue of data services, which are robust and efficient.
© Dr Sarah Williamson. Powered by Apache Roller 4.0.1-dev.
| « May 2013 | ||||||
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 | |
| Today | ||||||
Tags
alt approval assessment blog camel cardiff change charter collaboration connections curriculum description design digidol enagement flexible handbooks hea information jisc lean mwe palet programme quality stakeholders students technology university webserviceNavigation
Links
- Bolton University - Co-Educate
- Cardiff University
- Cluster Group Tweets
- Course Tools website
- Joint Informations Systems Committee (JISC)
- MWE
- Open University - OULDI project
- PC3 project at Leeds Met Uni
- PIP project at Strathclyde University
- Staffordshire University - Enable Project
- Design Cluster B Blogs - Netvibes






Are you doing any kind of authentication or registration of data consumption? I'm thinking less about security here and more about managing change. My institute had some open access webservices and found that making changes to them was impractical because developers didn't know who to communicate to about the change.
Posted by Cal Racey on October 28, 2011 at 09:48 AM BST #
As this is an open services with no security we have decided that we will control changes by using version numbers in the URL. Additions to the schema will not effect the end user consumption in our case. If fields are removed or renamed then a new version of the service will be created and this will then be communicated to the user community for them to implement in their own time.
I hope this helps, Simon
Posted by Simon Bleasdale on November 01, 2011 at 08:48 AM GMT #