Conclusions

One of the risks identified at the start of the project was that it might be overambitious. The project team foresaw that the scope of what was technically possible would probably shrink in light of further analysis and that use cases would be prioritised in order to deliver maximum value. What was not foreseen was the scale of effort required to implement a security mechanism for the components in the system. Even without the problems encountered with the Shibboleth implementation, implementing Web services, single sign-on systems and authorisation systems in multiple institutions was an immense task technically, operationally and culturally.

SUNIWE was asking too much from existing technical and organisational systems in many respects. From a legal viewpoint, it was difficult to convey the nature of the portal and Web services to the legal experts because they had not encountered the technologies before. From a data point of view, there was no consistency between institutions in the range or availability of information stored. Too often, the project team found that systems that the portal was intended to interface with had no means of communicating with the portal. Culturally, there was significant resistance to sharing data in the way the SUNIWE portal intended. Creating the necessary organisational change was and is a slow process. The SUNIWE project has laid the ground work to inform future consortium processes and procedures that may need to be established within a similar context.

There was a vast amount to learn during the project. The development staff recruited at SURF had some Java knowledge but no experience of Web Services, XML, XSLT, Apache Axis, IMS Enterprise Services, SOAP, Shibboleth, SAML, Apache Tomcat or uPortal. Acquiring these skills obviously took time. Ideally development staff already possessing the necessary skills would have been recruited at the start of the project but the relatively low salary and short term nature of the project reduced the range of applicants. Additionally, the RUP approach was being implemented for the first time.

Retention of project staff is critical for projects like SUNIWE. Early in the development process one of the two SURF developers left and mid way through the Construction Phase the project manager left. Given the timescales involved it was decided not to recruit replacements. The technical lead took on the project management responsibilities and the work of the departed developer was split between the technical lead and the remaining developer. The decision not to replace the departed staff was valid because previous experience suggested the chances of recruiting staff with the required technical skills within the time available was remote. Given the skills required it would take months before a new developer could make a useful contribution to the project. It was, therefore, vital to hold on to skilled staff. Loss of the staff was not a project killer but it slowed down development and contributed to the failure to identify a suitable security solution for the system.

Communication between the project team over such a geographically dispersed area was a challenge. A combination of traditional face to face and remote meetings was found to be the best approach.

Telephone conferencing and use of Skype and VNC to hold remote development sessions was useful to keep travel costs under control but face to face meetings were essential, especially during the requirements capture period. It was important to discuss the requirements as a team to ensure a shared understanding of the intended system was developed. Use cases were an aid to this by describing the use of the system but the scope and technical options could not reliably be conveyed remotely.

The wiki was useful as a persistent store for project documents and for capturing discussions. It was configured to email users when any topics were updated so that the project team did not have to keep checking the wiki for updates. A down side of using the wiki was that the structure of the wiki evolved as content was added. This required periodic tidying up of the content to prevent it becoming unwieldy which in turn created problems for users trying to find content in the new structure. Another barrier to effective use of the wiki was that users felt inhibited about editing content created by other users. This tended to stifle the intended wiki way of working where content evolves and updates create discussion.

Shibboleth is suitable for federated access to online resources and applications, especially where the attributes used to determine access are not personalised. Shibboleth currently is not suitable for use with portals and Web services because there are no Shibboleth profiles to support Web services and the standard that Shibboleth is built on, SAML 2.0, cannot represent the delegation inherent in calls to Web services by the portal.

Development of IMS Enterprise Web services involves several technologies. Developers need to be familiar with … and the IMS specifications themselves. The scale of effort required in producing even a modest collection of service operations is large. This can only be justified if the skills acquired are going to be reused in other developments or more services are to be produced in the future. Similarly, the business case for using Web services needs to be apparent. Services should be designed to be part of a service-oriented architecture where each provides a focused service suitable for reuse without change in several different contexts. Reuse of the services enables the benefit to outweigh the cost of development. If the “services” are just seen as plumbing between channels and databases then there is no real need for Web services.

The approach taken in the SUNIWE project was to implement the service operations at a low level, building XML documents from scratch. For future implementations, use of the CETIS IMS Enterprise SDK would speed up development.

IMS documentation was unwieldy. Of most use to the development team were the IMS Enterprise Web Services information models and the best practice guide. A read through the information models is recommended and for Java developers, javadoc-style API documentation would be useful as a quick reference whilst developing.

Mapping of data to IMS Enterprise objects is a decidedly non-trivial exercise. It tends to highlight inconsistencies in data storage between institutions and the Web service operations sometimes operate contrary to the business rules of the institutions. For the SUNIWE data:

1. extensions needed to be added for term-time address information.

2. the address format varied between institutions with one format having insufficient structure to the address to allow a consistent mapping to be achieved

3. the restriction of the readGroups to supplying group information for a collection of group IDs meant that the readMembershipsForPerson operation had to be extended to return group relationship information because the group relationships only existed within the context of an individual learner.