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.

Comments

  • Cal Racey

    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.

Leave a Reply

Your email address will not be published. Required fields are marked *