Developing a Service Based Architecture in the Mobilearn E-Learning Project

Mobilearn is a project within the 5th Framework Programme of the European Union. Its objective is, to investigate the use of mobile technologies in different learning contexts. In order to achieve this, a service based software architecture is developed. In the following paper we describe the architectural approach taken within the Mobilearn project and some of the experiences gained. The author is a member of the Mobilearn Project Management Board. His institute maintains the Mobilearn Software Documentation.


INTRODUCTION
Mobile devices like Smartphones, PDAs and wireless connected Tablet PCs and notebooks provide in principle ubiquituous access to distributed knowledge resources.This opens up principally new possibilities for learning, not only in an institutional context but as least as much for the everyday learning activities motivated by interest, curiosity or professional needs.The Mobilearn project investigates these possibilities.Already in an early stage of the project it was decided to develop a service based framework for these investigations.Currently the project is in the final state of designing its system of services.Following a short introduction into the work of the Mobilearn project -as much as this is needed for the current subject -we will describe the reasons that led the project to go for a service based architecture.Then we will discuss the way in which this architecture is designed.This will show up some of the problems that the design of a service based architecture poses and the way in which these problems are handled within the Mobilearn project.Finally we will shortly describe the tools that have been used respectively developed in Mobilearn to support this work.

THE MOBILEARN PROJECT
The Mobilearn project has been started July 1 st , 2002.It brings together 24 partners from 6 European countries and Israel in a joint effort to investigate the use of mobile technologies for different learning settings.In addition to these European partners, Mobilearn has an agreed collaboration with partners from the United States and Australia.The project is coordinated by Giunti Ricerca.More detailed information can be found on the project web site http://www.mobilearn.org.For the following discussion it is very important to note that the Mobilearn partners come from quite different communities -there is pedagogy as well represented as technology and academia as well as industry.Mobilearn intentionally concentrates not on the usual institutional learning scenarios.The basic strands to be investigated in the project are • Visitors of a museum coming with certain interests and being supported in learning more about this and related art issues • People needing to learn about health problems for their personal usage without being health care professionals • Experienced managers or first semester students attending MBA university courses and needing assistance to quickly adapt to the opportunities offered by the university.The project undertakes to develop a technology that supports selected learning scenarios in these fields in a prototypical way.It is planned to test these prototypical tools with small groups of learners in order to gain a better understanding of the possibilities they offer and of the challenges which their further development poses.In the first year of the project, emphasis was on the investigation of the user needs.A considerable number of usage scenarios in the aforementioned fields has been collected from the Consortium members and from associated partners.These have been revised in a discussion among the partners.This has led to the formulation of four core scenarios that would be optimal to support from the end user and pedagogy point of view.It was found most attractive to develop basically a single Mobilearn system that would be capable to support all these core scenarios.Then, in fact, the resulting system should be also capable to cover other scenarios which combine activities from these.In parallel, project partners continued to develop software and to augment it with features which were likely to be needed in the project.The most important software tools, which were also used for early prototype testing, where • a learning management system • a collaboration system Figure 1.The OMAF Layers The experienced reader may note that there is a considerable similarity with the framework proposed by the Open Knowledge Initiative (OKI) led by the Mobilearn partner MIT.This is intended in order to foster the future cooperation between both projects.
The further work then concentrated on defining the required mobile and generic services.Looking backward it seems remarkable that this service based design was confirmed at the project meeting without an in-depth discussion.This seems due to the fact that the consequences and the significance of the proposed usage of a service based framework was not realized by many of the partners.This may be in part explained by the mixed competence available in the project and by the dominant effort (at that time) of analyzing the demands from a user point of view.It took until project month 12 to realize widely within the project that this approach, while being very much in line with current trends in software development, poses a number of additional challenges to the project.
• There is currently little technological experience in designing a service based system • Software development tools are just beginning to support the development of individual services.There is almost no tool support for the development of a complete system of services.• The usefulness of a system of services is hard to evaluate by the representatives of the potential end users.• This as well as the coordinated development of a system of independent services poses new challenges to the project management, especially the management must take care of the emerging dependencies between different services and workpackages.• Having independent services which communicate through the exchange of messages poses problems of distributed data storage and synchronization.• The large communication traffic between the services may pose efficiency problems to the overall system.On the other hand, the proposed service based architecture offers considerable benefits.
• Applications for different scenarios can be easily assembled from the various services • More services, also from other parties, may be integrated relatively easy • Existing systems can be reused by wrapping them into service envelopes.This allows each service developer to use the most efficient tools and programming languages for his purpose.Re-implementation in a common programming language is avoided.• The project management can concentrate on the coordination of the design and implementation of the mutual service calls, while it can leave all issues about data structures and algorithms completely to the implementing teams • Mobilearn services may be reused outside the Mobilearn project through their open communication interfaces.• The high level design of the system of services allows an early analysis of the emerging system and its comparison with the requirements from the users point of view.These advantages led the consortium to confirm the taken approach at a project meeting at month 12 .A special point discussed at this meeting was, whether the project will build a set of web services.Concern was raised about lack of sufficient experience with the development of this kind of services.This was met by the agreement that the service based OMAF approach will implement features of web services only as far as they are needed for the project.For example there is no need in Mobilearn to support complex service discovery or billing procedures.This is justified by the prototypical character of the Mobilearn system.On the other hand the Mobilearn services can be easily augmented outside the project with these features in order to convert them into full-featured web services.The remaining core parts of the development of services -establishing communication channels, exchanging messages etc. -are sufficiently well understood within the consortium in order to proceed on a solid base.Once relieved of the need to struggle with coordinating interior details of the individual services, the project management could concentrate on the design of the system of services.

DESIGNING THE MOBILEARN SYSTEM OF SERVICES
The starting point of the design of the system of services was the collection of core scenarios which have been isolated from the user requirements which had been collected in the first project phase.In a first approach it was planned to describe these scenarios as UML use cases and to transform this into a design of the intended system.This turned out to be too time consuming and to require too much additional discussion between those investigating the user needs and the underlying pedagogic principles and those having to design the services.Especially the required degrees of precision and granularity of the description had to be discussed.Therefore it was decided to proceed on two parallel tracks in a coordinated way.On one side it was continued to collect requirements from the end users side.These have been collected in a database maintained by The Open University UK.This database has a web interface so that partners could add requirements at any time.From time to time a revision of the database will evaluate the requirements uploaded and will forward them to the appropriate partners concerned with implementing the respective Mobilearn services.This activity is considered to be important to test the achievements of the project against the actual user needs.On the other hand, the design of the system of services started directly from the description of the selected core scenarios.It was apparent in this process that designing a software for educational purposes requires urgently a special competence to translate between the world of education and the world of software implementation.In this process, the use of UML diagrams has been helpful because they depict important features of the design under development in a graphic way which is easy to understand.Interviews with the respective experts in the Consortium where the most efficient mean to overcome different interpretations of requirements and possibilities.So, taking the produced UML use cases into account, in parallel the implementation group started to decompose the selected scenarios into activities.A set of services was designed so that all specified activities could be supported.This set of services then was structured into a number of components so that the responsibility for the development of the services of a single component could be assigned to one workpackage of the project.Already at this stage it was scheduled which service should be available at specific phases of the project.The next step augmented each service with a verbal description of its role.Also it was defined which other services it would call.This led to the network of dependencies which is depicted in Figure 2.