SSG009: ESS Architecture Review
Phase 2: St. Andrews use of STUTalk for SITS integrationVersion 1.001/07/2013
SSG009: ESS Architecture Review
Phase 2: St. Andrews use of STUTalk for SITS integration
Version1.0
01/07/2013
Page 1 of 7
SSG009: ESS Architecture Review
Phase 2: St. Andrews use of STUTalk for SITS integrationVersion 1.001/07/2013
Contents
1Background
2STUtalk
3Overview of the Architecture
4Evaluation of StuTalk
5Conclusion
Document Management
Role / Unit / NameAuthor / Development Services,
IS Applications / Dave Berry
Analyst/Developer / Software Development team,
IS Applications / Ross Nicoll
Senior Analyst/Developer / Software Development team, IS Applications / Peter Pratt
Business Analyst / SACS, Academic Registry / Chris Giles
Project Manager / Project Services,
IS Applications / Franck Bergeret
Project Sponsor / Assistant Principal, Learning and Teaching / Ian Pirie
Version Control
Please document all changes to this document since its initial draft.
Date / Version / Author / Sections / Amendments01/07/2013 / 1.0 / Dave Berry / All / Initial draft
1Background
When building applications around the SITS student record system, a fundamental choice arises of how to build those applications:
- Within the SITS e:Vision framework itself
- In a separate application framework, using only the SITS database
To date, the University of Edinburgh has chosen the first approach whenever it has developed a new centrally-managed student record application. Other systems persist, such as PPMD for managing Post-Graduate progression and SMART for managing marks and exam boards, but these pre-date the adoption of SITS.
The University of St Andrews has taken a different approach for two of its major student record applications. It developed these systems using conventional programming languages, reading and updating data from the SITS database. This review looked at the implementation techniques used by the University of St. Andrews with a view to what we might learn for future development in the University of Edinburgh.
The review process consisted of a presentation and discussion led by Ross Nicoll, who was part of the St. Andrews development team. This was held on 22nd May 2013. Ross’s slides for this presentation can be found on the projects web site[1] and form the basis of the current document.
2Background
2.1Development technologies
There are substantial differences, as well as some similarities, between developing applications in SITS e:Vision and developing them with conventional programming languages such as Java, ColdFusion or PHP.
One major difference is that conventional programming languages have advanced support tools that provide facilities such as version control, test suites, automated deployment and test. These support tools assume that the source code for the programs is stored in text files on the computer’s main file system. The tools provide quality assurance, support multiple developers working together, and provide the ability to roll back to know versions. Another difference is that conventional programming languages also tend to simplify the task of adopting institutional standards for look and feel, and for usability and accessibility[2]. These languages are well known and there is a worldwide community of developers.
Applications build using e:Vision are stored in the SITS database itself. This makes the conventional support tools impractical and it is much harder to provide equivalent capabilities. The expertise required to write applications in e:Vision is a highly specialist areas with a relatively tiny community.
However, e:Vision applications have the advantage that they can use built-in SITS functionality, including SRLs and triggers. They also present user interfaces using the same methods as the rest of e:Vision, thus providing a common user experience across the set of e:Vision applications. By contrast, an application written outwith SITS might be unable to reuse certain functionality and will usually appear to the user as a separate user interface. A separate application will also introduce a dependency on multiple servers, adding a small risk to the overall availability of the system.
2.2STUtalk
When accessing data in SITS, there are two main implementation choices:
- Access the databases directly
- Use StuTalk Web Services and StuTalk XML
StuTalk is a Web Service interface to SITS, allowing programs to send and receive data encoded as XML from clearly defined interfaces and to run certain SITS processes. In theory, there are a number of advantages or using Web Service interfaces such as StuTalk, including:
- Data validation: Theservice (i.e. SITS in this case) willvalidate the data and store it in the correct place, without the application needing to know how to do this.
- Data consistency: The service will ensure that data does not breach consistency constraints.
- Immediate feedback on success. The service will immediately give the caller an indication of success or failure, allowing it to take appropriate action.
- Protection from change: The internal implementation of the service may change without affecting the external application.
- Ability to run SITS processes. Without this functionality, an external program would be unable to run SITS processes and the ability to reuse such functionality would be restricted to applications written in e:Vision.
One limitation of Web Services is that they are typically not suited for the transfer of large amounts of data. They are intended to support individual transactions and operations rather than bulk data transfer. StuTalk includes a facility called StuTalk XML that is designed for handling bulk data.
At the time the University of Edinburgh first adopted SITS, the StuTalk interfaces were judged to be too immature for us to rely on. Since then, StuTalk has been further developed and is in use at several other UK universities.
The choice of whether to use StuTalk is independent of how the application is built. StuTalk can be used from separate applications or from within SITS e:Vision itself. Phase 1 of the current project recommended that StuTalk be used, where possible, even for applications that we build in SITS e:Vision.
3Overview of the Architecture
St. Andrews has built two key applications that interact with SITS:
- MMS: institutional data flow management tool suite
- Admissions
MMS extracts data directly from the SITS database and presents a number of reports to members of staff. The data includes courses and enrolments, supervisors for postgraduate research students, course results for degree classifications, exceptional circumstances and disability information. After the exam boards have met, the end-of-course results are uploaded from MMS back to SITS using a semi-automatic process: MMS generates CSV files and these are imported in batch operations from the SITS client.
IS THIS THE ONLY DATA UPDATED BACK INTO SITS FROM MMS?
The Admissions system also reads data directly from the database.It writes decisions back via StuTalk Web Services. Student details and applications are written back via StuTalk XML, which as noted above is the bulk data facility within StuTalk. The version used was StuTalk 8.5.1.
User response for the systems has been very positive. They are felt to be noticeably easier to use than the SITS tools and SITS-specific details are generally hidden from the users. The use of ordinary development environments substantially simplified the ability of developers to adopt the institutional look and feel for these applications.
4Evaluation of StuTalk
The principal goal of this review was to learn from the St. Andrews experience of using StuTalk. In summary, StuTalk gave the developers several advantages but also had several limitations.
StuTalk Web Services are well suited to small interactive tasks. They give immediate feedback on success or failure. They also have the ability to run processes within SITS, for example, to assign a new student ID or to generate reports. On the downside, they have relatively poor performance. The detailed design of the interfaces is rather poor. They do not use standard authentication mechanisms, have no support for transactions and limited support for writing multiple records. These limitations restrict the cases where StuTalk Web Services can be used effectively.
ISTR A NEW VERSION IS ON THE WAY?
StuTalk XML is intended for uploaded larger data sets. It is robust for simpler data sets. There are some limitations for more complicated data sets that write to multiple tables.
By contrast, reading and writing to the database directly has no performance issues. However, this approach is best for simple use-cases. It by-passes SITS data integrity enforcement and SITS triggers. It does not give any feedback to the calling application and cannot be used to run processes.
5Conclusion
The main recommendation from the review was to begin using StuTalk in situations where it will yield most benefit. This may be for applications written in e:Vision itself; the use of StuTalk is independent of how the application is built. As our experience grows, we will gain more knowledge of how best to exploit this technology.
The review did not make any recommendations regarding when to write applications in e:Vision or other systems. The St. Andrews experience shows that it is practical to build applications outwith e:Vision.
In parallel with our gradual adoption of StuTalk, the review also recommended that we work with Tribal and the SITS StuTalk Group to improve key issues in the design. These include overall performance, lack of support for transactions, and the need to handle related records as a batch.
Page 1 of 7
[1]
[2] Usability is generally how easy the system is to use;Accessibility is specifically about ease of use for disabled users.