LeAP Project Case Study:

Transcription

1 LeAP Project Case Study: Implementing Web Services in an Education Environment Summary IMS Australia Department of Education, Tasmania Contributors Kerry Blinco, IMS Australia Greg Curtis, Department of Education, Tasmania Neil McLean, IMS Australia Jon Mason, IMS Australia Australia This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivs License. To view a copy of this license, visit or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA. Document Name: LeAP Project Case Study: Implementing Web Services in an Education Environment Summary Version 1 Version Date: 16 July 2004

2 Contents Contents INTRODUCTION LEAP IN CONTEXT Architectural Models LeAP Components COMPARING LEAP TO FRAMEWORKS LeAP Layered Model LEAP IDENTIFIED WEB SERVICES IMPLEMENTATION CHALLENGES OBSERVATIONS The LeAP Approach Potential Benefits Management implications Implications for Infrastructure Development Case Study Web Site: The latest version of this document may be found at: CaseSummaryAppendix.pdf The accompanying document LeAP Project Case Study: Implementing Web Services in an Education Environment Summary Appendix Architectural Models, may be found at: CaseSummary.pdf The full version of the Case Study may be found at: Case.pdf Version 1 Date 16 July

3 1 Introduction The Department of Education, Tasmania 1 provides education services in 218 schools and colleges across the State with over 70,000 students. The Department s Learning Architecture Project (LeAP) supports the implementation of the new Essential Learnings curriculum and pedagogical reform. The project is delivering a set of integrated and interoperable online applications to enhance teaching and learning. Applications enable teachers to: plan learning experiences and units of work for delivery on or off line; access curriculum outcomes; record student assessments; and report progress to inform students and parents. Staff and student authentication, collaboration and communication tools and a digital data bank of resources underpin these applications. The LeAP project is wholly funded by the Department of Education, Tasmania. The LeAP project builds on deployment of a common hardware, software and networking infrastructure throughout the sector in Tasmania, including: The delivery of quality ICT infrastructure to the school A standard operating environment for all schools A student computer ratio of 4.8:1 (excluding old and administrative computers) Whole of government contract for networking of Schools Technical support for the computer and networking equipment which ensures better than 99% availability Implementation of the WebCT Learning Management System (1999) The development and delivery of multimedia, online resources (learning objects) through the Open-IT and the Curriculum Consultation Project Acquisition of collaboration tools including chat, bulletin boards Introduction of a unique student identifier for each government school student Implementation of a common school administration system for all government schools (1997) supported by a central business unit Implementation of a range of professional development programs for teachers supported by establishing a resource teacher in every The setting up of the Centre of Excellence in Online Learning promoting the integration of ICT pedagogical practices into the classroom The full case study documents the overall architectures and key components supporting the core business functions of Plan, Deliver, Report and Assess. The full case study can be found at: Case.pdf This document summarises the core architecture of LeAP (a service oriented approach), abstracts the technical architecture underpinning LeAP and compares this (as an example) to the framework developed by CETIS/JISC. 1 See Version 1 Date 16 July

4 The technical mappings are used to identify congruencies or compatibility between LeAP and national and international standards. The comparison of these components with key current standards frameworks, suggests that although the current trend in e-learning standardisation to develop specifications which include behaviours and binding of these behaviours as Web Services is useful, the development of a well factored, coherent and consistent framework plus high level service definitions would be of significant value. The LeAP experience is compared to the potential benefits attributes to service oriented approaches to integration and interoperability. Although still in the early stages of the adoption cycle, the Tasmanian experience of implementation in a real world scenario indicates that although there are some technical issues and change management challenges, there are significant benefits to adopting a service oriented approach. 2 LeAP in context In moving the ICT in Education agenda forward the department implemented a number of systems. At a time when new curriculum and policy initiatives required ICT support, a number of the existing systems required review for various reasons relating to functionality, licensing, architecture or degree of interoperability. LeAP was designed as an overarching strategy for a range of projects that are being undertaken in the E-Learning space. The purpose of developing these projects under an overarching architecture is to provide a set of integrated and interoperable online applications to enhance teaching and learning in which the core business activities of Plan, Deliver, Report & Assess are supported by Communications and Collaboration tools, Content and Infrastructure, and Professional Learning. The business model informs the outcomes and objectives of LeAP and is reflected in organisation of the Project. Importantly, in this model, ICT is seen in a supporting role and not an outcome in itself. The applications developed under LeAP will be underpinned by a digital databank of resources, collaboration and communications tools (chat, forums, and list servers etc) and supporting services (security, scheduling, people information etc). Further the same systems used to support delivery of learning to the school student will support access to professional learning, quality content and infrastructure. The LeAP project has guiding principles of interoperability and the use of standards for data and infrastructure. The application architecture model has a preference for the use of service based infrastructure. The diversity of products within the educational computing environment makes it impossible to take an ideal or single track approach to application architecture. LeAP considers good practice in this situation to have a preference for using existing common services and create new services as application development progresses. Where neither approach is possible other integration techniques are used. Version 1 Date 16 July

5 2.1 Architectural Models The LeAP project has developed architectural models for each of the project groups. The project groups, and the application sets and services that are being developed, focus around the key areas described in the Teaching and Learning Model: Plan Deliver Assess & Report Infrastructure Content. These models provide useful tools for explaining the LeAP project to key stakeholders, and describe the interoperability requirements and dependencies for each key area. The models also indicate the nature of the interaction between application and services for a particular key area. Although the philosophy of implementing web services as a first preference has been adopted in the LeAP project, not all applications are able to be integrated using web services at this time. The models are detailed in the accompanying Appendix document: CaseSummaryAppendix.pdf 2.2 LeAP Components The LeAP implementation is built from many components. Details of each of the major components are detailed in the full LeAP report. The components can be categorised into the following groups: Portal Applications Web Applications Client Applications Software Agents Web Service providers Web Service enabled tools Standards based services Repositories Web Services Management Tools Version 1 Date 16 July

6 3 Comparing LeAP to frameworks In the past few years there has been significant work in the e-learning space in developing service oriented technical frameworks and component based models. Two of the key frameworks are the IMS Abstract Framework and the JISC Technical Framework to support e-learning. The full Case Study describe these key frameworks and provides an analysis of the overlap between these frameworks and LeAP service components. The most useful comparison was with the JISC framework. Each of these frameworks is a layered model, the layers being equivalent in both models. The componentisation (or factoring) of the models differs in detail. To some extent these differences are purely terminological. However the JISC ELF has attempted to present a reasonably internally consistent breakdown of components, whilst the IMS IAF documents a Grab bag of likely components. The frameworks also differ in the granularity of components that are represented in the current stage of development of the models. Each model aims to be informed by the e-learning environment Released in February 2004, the JISC document A Technical Framework to Support e-learning (ELF), introduces the rationale for developing a service oriented framework, proposes a framework and briefly describes each of the services and its relation to existing standards. The JISC ELF is a small s service framework, which makes no assumptions about the implementation of those services, allowing for delivery via computerised, computer assisted or manual processes. The ELF document is intended as a starting point for discussion, with refinement of the detail anticipated over time. LeAP components do not map exactly against the ELF components. There are differences in granularity between LeAP applications and the framework categories and in the vocabulary used to describe functions. In Figure 1, components of ELF which have some overlap with LeAP components are highlighted in yellow. The ELF does not assume that institutions will either desire to, or be able to implement a homogeneous services environment. The ELF documentation describes three common ways of integrating systems. User interface integration Service oriented approach based on web services. Data warehousing. Version 1 Date 16 July

7 Figure 1 - Comparison of LeAP with JISC ELF With the addition of Web Services and Application logic over the Data Warehouse component, this diagram provides a useful high level model of the actual LeAP implementation architecture, where web services are being used where ever possible, but other mechanisms are used where system constraints or design requirements require them. Figure 2 shows the high level LeAP integration model. Version 1 Date 16 July

8 Figure 2 - LeAP Heterogeneous Integration Model 3.1 LeAP Layered Model The following model (Figure 3) maps individual LeAP components as described in Section 5 of the full Case Study to a layered service oriented component model, using layers consistent with the key frameworks. Many of the LeAP service interfaces are, or will be implemented as Web Services, but some are implemented using other technologies, for the following reasons: the alternate technology is more appropriate for the function (eg Kerberos for authentication, JABBER for Instant Messaging) legacy interfaces are yet to be redeveloped interfaces vendor systems do not yet support web services some functions can not yet be implemented efficiently in Web Services In some cases services are invoked by web service requests or wrapped in web services. As LeAP is using a staged implementation, not all services in the model are sub-componented to the same level of granularity. Figure 4 indicates where standards have been incorporated into the LeAP implementation by highlighting in blue those service components which are to some extent based on standards. These blue areas are concentrated in infrastructure (which includes Web Services and SOAP) and areas where the Version 1 Date 16 July

9 Version 1 Date 16 July Figure 3 - LeAP Layered Service Model

10 Legend Figure 4 - LeAP Layered service model components with standards implemented Version 1 Date 16 July

11 Legend Figure 5 - LeAP components with potential for standards implementation Version 1 Date 16 July

12 standards are well established e-learning standards such as Learning Object Metadata and Content Packaging. These specifications are currently data specifications only and there are no associated service behaviour specifications. Figure 5 indicates where the IMS will be releasing standards in the near future, and where there are candidates or emerging standards from other specification bodies. The key technical frameworks are intended to encourage the development of the next generation of systems supporting e-learning. LeAP is a very early implementation of such a development strategy. Comparing the layered service model for LeAP with the key frameworks a number of conclusions can be made: the small component design and service architecture will allow LeAP to replace or add standards based interfaces to components as the standard interfaces are developed there is significant difference in the degree of componentisation between frameworks and that necessary to meet implementation needs the component service interface standards are lagging behind development design for projects such as LeAP can provide valuable input to the further refinement of technical frameworks the amount of redevelopment, or additional development which will be required in future for LeAP to become standards compliant at all interfaces, will depend on the degree of overlap of componentisation between LeAP and the frameworks used to guide standards development. To this extent a well defined and highly granular framework with high level service interface definitions would be of more assistance to projects like LeAP than one or two thoroughly detailed specifications. educational profiling of the use of web services is a high priority. The IMS General Web Services Project Group is scheduled to complete documentation for the use of Web Services in IMS Specifications in September 4 LeAP Identified Web Services Implementation Challenges Early adopters of a technology often face challenges that are resolved by the time the technology becomes mainstream thanks of course to those early adopters. The LeAP project team has identified a number of real and perceived challenges for early adopters of Web Services as a key component of an enterprise architecture: Infrastructure Management and application availability. When the core data systems are provided by loosely coupled web services the complexity of supporting and monitoring application performance and availability is increased. The LeAP team has tools under development to register applications and their dependencies, application errors and performance statistics. Vendor supplied web Services environments are including such tools in their standard environments. Security in terms of infrastructure and data are issues that need to be dealt with. Where in the network architecture the components hosted?, What method of web service security is used? are questions to address. (The first WS-Security specifications were ratified on 6 April 2004, WS-Security profiles for Kerberos and SAML Tokens are in process). Performance. It is generally accepted in the literature that there is an overhead to using web services. Reports from IBM/Gartner in mid 2003 estimate the overhead to be around 20-25%. The messaging service and extent of parsing Version 1 Date 16 July

13 contribute to the overhead. There is a growing body of literature around techniques for optimisation of web services and the applications that interact with them. Best practice implementation strategies are being developed and tools are becoming available. The need to deal with increased resource usage of this scale when implementing new technologies or even new versions of software are very common in the industry and are balanced against benefits. As with implementations of all kinds, careful sizing of all supporting infrastructure are required. Performance testing for new implementations of any architecture is an important risk management strategy. Availability. If a single component fails all other components that depend on that component will also fail. Web services can be implemented with redundant infrastructure such as web farms to reduce the likelihood of failure, migration of Database services to platforms with fail-over ability. Redundancy of infrastructure is a standard strategy for enterprise critical applications no matter what the architecture. Reporting. There are currently no products available to perform generic reporting across multiple web services and their resulting XML data sets. This becomes a more complex issue when complex filtering rules need to be applied. It would seem that this would be very inefficient. Some tools (Microsoft Reporting Service) have started addressing these needs but are still very green. Tools will increase in sophistication and availability. Project Management The ability to source small components from multiple vendors, in house and open source developments means that project dependency lines become complex and difficult to understand and manage but there are also benefits from not being single vendor dependant. Standards Support: Vendors claim support for standards but may not fully comply in a plug and play interoperability situation. Vendor relationships: Vendors are slow to adopt new technology frameworks such as web services. Consumption of Services. To encourage wide consumption of services with the organisation, it is not sufficient to supply services alone. The supplier needs to make it easy for consumers to consume the service into their application. Consumers need to be aware that the service is available, service interfaces need to be well defined, and software toolkits: that consume the service and with appropriate API interfaces can be supplied. 5 Observations Having analysed the LeAP approach from the view point of e-learning infrastructure development in the international context, there are a number of observations which may prove helpful with regard to the management of such infrastructure projects. The development of service oriented infrastructure to support e-learning is in its infancy and the LeAP approach sheds some interesting light on the management implications of adopting such an approach. In order to achieve best practice it is important that projects such as LeAP take advantage of the work being done by agencies such as JISC, IMS Australia and the IMS Global Consortium. Conversely such agencies need to take account of the experiences of implementation and development projects such as LeAP in refining framework models and developing strategic approaches to specification development. Version 1 Date 16 July

14 5.1 The LeAP Approach The LeAP Project is very clearly aligned with the DoE s business requirements and is policy driven. Outcomes for the project are described as business and policy support outcomes not technology outcomes. Sub projects are precisely aligned with the Teaching and Learning Model. One strength of the project model being developed by LeAP, is that the IT project ownership remains with the business unit, thus ensuring that the project outputs (applications) remain focused on the project outcomes. The subprojects are managed by project leaders located in the Business Units with the IT team providing consultation and support to the project team. LeAP as a supporting IT Project, has a low profile in the department, and an almost non existent public profile. Departmental support of the LeAP project appears indicate a high level of trust in the IT Team and acceptance of the positive role the Maverick can play in creatively and constructively changing an organisation. Although philosophically LeAP is an example of a Web Services implementation project, in reality the project methodology includes a heterogeneous mix of architectural approaches including service oriented approaches, component based modeling, feature driven development, and even elements of extreme programming. The project has taken a deliberate decision to implement web services as core enterprise infrastructure. A number of recent articles have suggested that much web services adoption has been by a Trojan horse approach - where either discrete projects implement web services with the approach filtering out to other parts of the enterprise, or enterprise integration vendors ship product including web services support, which is then gradually taken up in the enterprise. Realistically, it is not possible for the DoE (and one must suspect any existing enterprise) to implement a homogeneous architecture. Existing applications and processes must be integrated into the overall framework approach. The resulting architecture for the DoE is a heterogeneous combination of major enterprise integration approaches, including data warehousing, data replication and portal technologies. (See Figure 2). By modeling all components in the architecture and the interactions between them as small s services, the LeAP Architecture remains true to its philosophy whilst enabling pragmatic decisions to be taken about individual interactions. Non Web Service interactions can be replaced at an appropriate time. Potentially a service oriented framework approach provides granular building blocks which can be combined into small targeted applications ( composite applications is the term emerging to describe this application development strategy). The service components are reusable, enabling rapid development of new granular applications. It takes some time to build a critical mass of components to realise this benefit. After a reasonably short lead time, LeAP is now beginning to take advantage of the component base and is seeing some instances of accelerated, low cost development of targeted composite applications. The LeAP project is making good progress towards a Write Once Use Many philosophy. The project has three core data stores, the Enterprise Resource Management (ERM) Data Warehouse, the Resource Repository and the Curriculum Repository. The strategy of harvesting and replicating subsets of data from schools and human resource management systems in the data warehouse makes good sense at this time. Data replication of people information is managed from the data warehouse which acts as the system of record the authoritative data source for Enterprise Resources (ER). ERM Version 1 Date 16 July

15 functions are also exposed as web services. Decisions regarding data replication versus consumption of ER Web Service are taken pragmatically on an application by application basis. Development processes support economic development policies by utilising local vendors where feasible. The interoperable small component approach allows smaller vendors the opportunity to participate in low cost, low risk development whilst minimising risk to the department. LeAP implements a variety of user interface types including portals, web applications, desktop clients and software agents. The choice of interface depends on functional and deployment requirements. The types of small, targeted, portal exposed authoring and delivery applications that are being delivered in LeAP, raise questions about what a learning management system might be, and its role, in the new generation systems supporting e-learning. A series of data driven exemplar web sites are used to demonstrate the capabilities of the interoperable small component approach. Innovative presentation techniques are showcased on these sites. LeAP integrates collaboration and communication tools as core components of LeAP applications. These technologies are invoked through a web services wrapper. There is a great deal of interest in the specification communities about the best approaches to incorporating collaboration and communication and other desktop tools into learning delivery environments. LeAP has the advantage of building on an already deployed common core infrastructure including a common school management system implemented in schools across the state. Quality Assurance Processes are managed by a workflow engine. The division of repository spaces into Private, Private Shared and Public Repository spaces, with lodgment of content in Public Repository space subject to Quality Assurance processes, provides an interesting model for dealing with issues of reuse of Learning Objects by differentiating between ephemeral reuse and creation of new learning objects by adaptation of existing object. LeAP takes an interesting provisioning approach to access management. The ERM system maintains provisioning information, exposes services that support authorisation decisions by applications, and exports data required by external applications to manage access. Resources managed by the active directory environment operate in a single sign on environment. Other applications operate under same sign on either by authenticating via Kerberos to the directory service or import of common authentication tokens. 5.2 Potential Benefits The LeAP project experience to date suggests that the potential benefits attributed to adoption of SOA s by its advocates can be realised in practice. Because of the nature of SOA s, benefits are expected to increase proportionally with time. The benefits that have been recognised to this point in the project are: Data maintenance efficiencies ( create once - use many ); Ability to reuse services in different contexts rather than undertaking separate duplicative development. ( develop once, expose many ); Development of focused applications ( fit for purpose ) that consume services in different aggregations ( composite applications ); Many composite applications can be developed with relatively small budgets resulting in: Version 1 Date 16 July

16 big wins for relatively small investments advances without always requiring large budget item processes can be developed within existing budgets; Flexiblity and Responsiveness - ability to move quickly to respond to a need, a good idea or new technology ; Ability to re-engineer small components or add component interfaces as standards or protocols are ready to be implemented; and Discrete components of work can be allocated to a developer who only needs to know the interface definitions for service to be provided or consumed. 5.3 Management implications The LeAP Project is an example of early adoption of the next generation of frameworks and architectures which will support e-learning. Management implications of early adoption include: Early adoptors risk implementing approaches that do not stand the test of time. Recent market surveys indicate that 2004 should be a break out year for Web Services. Some commentators predict that by 2007/8 SOA s will be pervasive. ZapThink expect that by 2010 SOA s will be the dominant distributed computing architecture. Early adoptors are often implementing ahead of standards and the evolution of best practices. In the case of SOA s implemented over Web Services standards are required at both the infrastructure layer and at the domain and common services layers. Implementation plans should include strategies for adoption of standards as they mature, or run the risk of becoming non interoperable outside the enterprise. A few additional components in the LeAP project could incorporate current standards. Identification of appropriate standards is an ongoing challenge for implementation projects. As technologies mature, tools to support development and provide operational support are also developed. LeAP has developed in house tools for operational support. Adoption of new approaches such as SOA and Rapid Development Cycles, mark a significant change in organisational strategy. Change management strategies are required for staff, management, interactions with others including projects, clients, vendor partners etc. and might include: training communication of the vision, perception management project champions management of client expectations The position of vendors working with, or seeking to work with an organisation implementing an SOA approach can range from cynicism to over hype. There are very few (if any) references in the literature to full large scale homogeneous enterprise deployment of SOA s /Web Services. It is likely that most enterprises will, in the medium term, adopt a heterogeneous architecture with a preference for Web Services where possible. To encourage wide consumption of services within the organisation, it is not sufficient to supply services alone. The service supplier needs to make it easy for consumers to consume the service into their application. Consumers need to be aware that the service is available, service interfaces need to be well defined, and software toolkits that consume the service with appropriate API interfaces can be supplied. Version 1 Date 16 July

17 When should a function be provided as a new user application implemented as a re-aggregation of existing services rather than enhancing an existing interface? In part this includes issues of scaling and management. The LeAP Project exposes services within a highly distributed yet well controlled enterprise. What additional issues need to be addressed when services are exposed outside the enterprise? New methodologies require new forms of documentation. 5.4 Implications for Infrastructure Development The SOA approach challenges the traditional perception of an application and its granularity. With a SOA approach the services should be aligned with business processes and support the business model. The services defined in the architecture shouldn t define what processes are implemented; rather, the business processes define what services are needed. Implementing an SOA allows technology to better support the business by aligning with it rather than defining it. 2 Adoption of the SOA approach appears to deliver the promised benefits of flexibility, responsiveness, lower cost development of new applications etc. There needs to be a critical mass of services to realise the benefits, but these are realised rapidly once the key services are implemented. The amount of redevelopment, or additional development which will be required in future for LeAP to become standards compliant at all interfaces, will depend on the degree of overlap of the factoring of components between LeAP and the frameworks used to guide standards development. To this extent a well defined and highly granular framework with high level service interface definitions would be of more assistance to projects like LeAP than one or two thoroughly detailed specifications. Because the specification development process in e-learning has to date been focused on data interchange specifications that do not include behaviours, almost all the domain services for e-learning need to be defined. It may not be necessary to produce fully detailed specifications in one pass. There would be significant benefit in working on a wide range of service definitions and detailing the supporting data models later. The definition and specifications of common services need to be agreed across domains. Identification of appropriate standards is an ongoing challenge for implementation projects. 2 Summarised from Brian Schaffner, A SOA allows for better alignment, Builder.com, 12 September2003 Version 1 Date 16 July