Select Language:

An Architectual Framework for distributed E-Learning Systems


Education plays a central role in today´s society. Schools, Universities and companies all face the same problem of having to make their e-learning content available at every possible location and at every possible time. Therefore it is necessary to either expand on current infrastructures or develop new ones. E-learning systems represent the first successful answer to this challenge. However such systems have often been monolithically programmed and cannot be expanded easily or integrated into the existing IT infrastructures.

This paper develops a framework for modern e-learning systems that can be easily expanded, adjusted and integrated. Based on the idea of breaking monolithical programmes apart into functional components, a component based architecture will be developed by taking the expectations placed on such systems into account. Finally the idea of using components will be expanded on and a service based framework which builds on this will be presented. The use of web services is recommended to fully implement these. Firstly web services and their suitability for implementation will be presented. They will then be compared with other technology and the reasoning behind our recommendations will be explained.

Finally with the use of the architectural framework a sketch of the structure of sample e-learning systems equipped with basic functions will be provided.

1. Introduction

Vocational and further education are very important in our society. It is becoming more and more difficult to achieve success in the current labour market without a good solid education. The indispensable foundations necessary for the professional world are provided by schools and universities. However a good education is not only important at the beginning of a career, it is necessary to remain constantly up-to-date by participating in further educational courses. Several companies have recognised this [ZFU] and have considerably expanded their educational programs in the last few years. The additions to their programs include the traditional trainer based teaching, Business TV, pre-recorded speeches/presentations and computer based training. However these measures are very costly on the one hand because staff members are not available for their everyday work and on the other hand additional costs for travel, accommodation as well as course fees have to be paid.

A slightly different situation can be found in schools and universities. Their primary task is to educate their students in their chosen professions. Their daily work is not directly affected by the absence of participants [NBS+99]. Nevertheless the traditional methods of teaching supplemented by group work and on the job training is no longer sufficient. Students expect additional educational facilities that they can avail of whenever and where ever they choose. Therefore new IT infrastructures are required that are available everywhere, 24 hours a day, to successfully meet the changing expectations placed on education in schools, universities and companies.

The first successful solution is known as E-learning platforms. These web based systems enabled students to access the desired e-learning material anywhere and at anytime. Such systems [CS02] were developed by several companies and universities but could only offer certain functions. This disadvantage results from the fact that they are complete systems which have been monolithically programmed. Further, from a functional point of view, the systems cannot be expanded because the necessary interfaces were not planned for. To rectify this situation it is possible to break monolithic programmes down into small modular routines to be then used for the improvement and creation of new functions in existing systems.

According to demand and individual requirements learning environments could then be created from this components. These components are also able to provide the appropriate web interfaces that are only needed for the functions. The functions of a system that logically belong together are encapsulated by the components and then offered to the students via a web interface.

The functions and interfaces of the various components must match if a co-operation between components is to be achieved. This idea, when consistently carried out, leads to a framework for e-learning systems that enables the developers of components to create new or improved components that can be easily integrated into existing e-learning systems.

Recent developments in web applications have often been referred to as services. In contrast to components, services can be seen as individual small programmes that are then offered to other programmes in a network. These services can be localised and their functions utilised. In systems that consist of components this has to occur before the system becomes operational. However to enable this kind of flexibility it is essential to have a more exact definition of the services and their interfaces. Therefore a corresponding framework is called for.

This paper begins with a description of the general expectations that a component based architecture has to meet. In relation to this an architectural framework will be introduced. Finally, with the aid of the newest web services offered by IBM and Microsoft, a suggestion for the concrete implementation of the systems will be made.

2. The requirements of a component based architectural framework

This chapter will be limited to the description of requirements specific to the domain of e-learning systems and not applicable to all software architecture. Some of the general software requirements consist of the layer architecture including separation of the user interface from the application, modularity, encapsulation, scalability and the use of standards etc.

2.1. How components can be combined

In order to meet the desired expectations more than one component or rather more than one function is often necessary. Indeed components often have to be combined to satisfy the demands placed on them. It follows from this that the components have to offer the appropriate interfaces in order to be combined.

2.2. Individual working environments

Different expectations are often placed on the programme display. Every user or group of users (working groups, Institutes etc.) of a system would like its display to be based on their own ideas and wishes. Therefore it is necessary that the graphical user interface (GUI) of the various components can be combined with each other so that an appearance that is both individual yet uniform for the user group can be granted (corporate Identity).

2.3. Extensibility and Interchangeable

The fast technical progress and development of new learning scenarios will lead to the further development or replacement of existing components as well as to additional components. These structural changes and extension have to be carried out without major affect on the existing components too much. That means that availability must not be limited or that the functional capabilities of other components be affected in a negative manner.

2.4. Integration in existing Infrastructures

A lot of learning environments require information that has been produced and stored in existing systems known as legacy systems. It is often necessary to integrate these systems in the new environments to avoid programming the information once again and of course the resulting costs and time lost.

2.5. Easy to use

Several users will use the various components that make up the e-learning systems. Many of these will not be very familiar with web technology. Their expertise lies in other areas such as mathematics, chemistry, biology or mechanical engineering and they would like to use the e-learn systems to impart their knowledge. As a result of this the components have to be extremely user friendly and easy to understand.

3. An architectural Framework for component oriented systems

3.1. Architectural scheme

A typical e-learning system component consists of three architectural layers analogue to Model - View - Controller (MVC-Architektur, vgl. [GHJV95], [KP88]). The lower layer consists of storage layer, followed by the application layer and finally the top layer constitutes a web layer (view).

Illustration 1 shows this architecture.

[ Illustration 1: Architectual scheme of a component ]
Illustration 1: Architectual scheme of a component

3.2. Web layer

The user interface (web surface) of a component is composed of several web pages that have been linked with each other. These are shown using an internet browser which receives the pages from the web server which it is connected to.

The adaptability of the surface presents a technical challenge. To take a closer look at this it makes sense to differentiate between pages that have been made/configured by users and system pages. System pages are generated by components and supply navigation services, present search results and offer other functions. Individual pages tend to have been completely created by users or are system pages that can be changed by users.

3.3. Application layer

The application logic can be found in the application layer and is normally separated from the web client in web based systems and carried out in what are known as web servers. Web client requests are received and processed here. The results are then sent back to the web client using an appropriate protocol (HTTP 2-Protocol).
Should other components be needed for processing or calculation purposes it will be communicated among the components using defined techniques of communication (CORBA, RPC etc).

3.4. Storage Layer

This layer stores for example personal notes made by the user, interim work results etc. It is not necessary to save this kind of information on a central database. The information in question is saved on web servers using a variety of methods. It is therefore possible to use relational databases or text files for storing purposes.

3.5. Overall Architecture

As described in 3.1 a single component is not always sufficient to create an extensive e-learning system and hence the combination of several components is essential. This kind of system which consists of various components can be seen in illustration 2. The complete architecture distinguishes itself from the single components in a number of points.

[ Illustration 2: Overall architecture ]
Illustration 2: Overall architecture

3.6. Web-Interface

In the web-interface the web surfaces of every component are combined in such a way that, optically, the resulting surface appears to be a homogeneous system.

3.7. Global data maintenance

This layer is made up of on the one hand legacy systems that can be approached or acted by components via defined API´s 3 and on the other hand a central database where component overlapping data is stored.

3.8. Upgrading component based services

A component based system can fulfil a lot of the of the expectations mentioned in chapter 2. However, from the software technology point of view not all problems have been solved. For example the scalability of a component based system is very limited and the availability of such systems cannot always be guaranteed. The solutions to these and other problems have been increasingly addressed by what are known as services over the past few years.

4. An Architectural Framework for service based systems

Current web applications can only partly satisfy the demands placed on them. The systems that are currently available were developed either as classic client/server applications or in some cases as component based systems. However problems with scaling or the prevention of system failure often arise. These problems could be avoided by a service based architecture which is founded on a component based architectural concept.

Services widen the possibilities of the above mentioned components and can be characterised as follows:

In the following sections the additional expectations placed on the architectural framework of service based systems but which do not apply to component based systems will be explained.

4.1 Combination of Services

In contrast to components where the connections required have to be determined during the planning stages, services, have to be technically capable of not only looking for and connecting with other services but also be able to use the functions which are on offer when they go into operation. This requires a more detailed description of the interfaces and of how or rather in which order the services should be combined.

4.2. Service Security

To create a working environment which consists of various services clearly defined guidelines on security are needed in order to protect data from being tampered with or information sent to unauthorised addressees. The services have to be able to authenticate each other to ensure that only legitimate or authorised communication occurs.

4.3. Individual working environment

As already mentioned in 2.2 users have to be able to adapt or change the web surface of a system as they choose In a service based architecture it is important to remember that services which offer similar functions as well as a web surface must do so in a similar way. All services, which are in similar any way have to be able to avail of the functions of the web surface.

4.4. Availability and Scalability

Although, in an attempt to increase availability it is theoretically possible to supply various computers with services that have the same functions, it can nevertheless arise that there is no service which offers the desired function. The resulting system failure can lead to a considerable lack of understanding on the user's part. It, therefore, has to be guaranteed that following a system failure all services are available as quickly as possible. A suitable concept is called for to enable this.

Peak times represent an additional problem. These are times when several users are using the same service which can lead to increased latency. The problem can be more or less solved by providing numerous services. A record should be kept of which services are most frequently used so that the amount of frequently used services remains manageable and easy to maintain.

4.5. Integration in the existing IT infrastructure

As expressed in 2.4, it has to be possible to, on the one hand, continue using existing systems and on the other hand to read and change information offered by these systems.

In order for existing systems to communicate with these services they will have to be accordingly modified and to enable this the corresponding interfaces have to be specified and implemented.

5. Implementation with web services

In the previous sections services in general have been discussed and the demands on them formulated. In this section, a concept for the implementation of web services will be recommended. This will be followed by an introduction to web services and subsequently the examination of specific aspects with regard to the implementation of e-learning systems. It will then be shown how the above mentioned service requirements can be satisfied with the aid of web services. Finally a comparison to other techniques will be made and reasons for the recommendation of the implementation of web services given.

5.1. Web Services

"Intelligent web services are for the Information age,
what interchangeable components were for the Industrial age."

(Scott McNealy, Chairman and CEO, Sun Microsystems,Inc)

Recently a lot has been written about the concept of web services. Yet a definition which is both precise and exact does not exist. The [IBM00] offers the following definition: "Web Services are self-contained, modular applications that can be described, published, located, and invoked over a network, generally, the Web".

However at the point in time when this paper was written W3C02 offered a more up-to-date definition: "A Web service is a software application identified by a URI, whose interfaces and bindings are capable of being defined, described, and discovered as XML artifacts. A Web service supports direct interactions with other software agents using XML based messages exchanged via internet-based protocols.".

It is neither the aim of this paper to establish one definition from the numerous available nor to attempt to create a new concise one. Web services will be looked at according to their functions and standards.

Web services are self contained applications. They encapsulate a certain user logic and can be invoked via a network (web). When referring to a network it can be understood to include the World Wide Web (WWW) as well as a Local Area Network (LAN). In order to control and use the consolidated logic it is necessary to define the interfaces. This definition is in line with the "Web Service Description Language" (WSDL) which was standardised by the World Wide Web Consortium (W3C). WSDL is based on "eXtensible Markup Language" (XML) and enables a description, which is not dependent on platforms and programming languages, of web services available in a WSDL document. (cp. [STA02]).

Using the W3C standardised "Simple Object Access Protocol" (SOAP) web services as well as applications can in general communicate by exchanging XML based messages and thus use their logic. SOAP is based on XML as well as WSDL and is therefore platform and programming language neutral. SOAP enables not only synchrone communication but also asynchrone communication that ranges from the XML based Remote Procedure Calls (RPCs) to the exchange of any XML messages. The message to be transmitted (payload) is encapsulated in a SOAP element (Body-Element) and provided with additional information e.g. routing information in another element known as Header Element. The syntax of XML messages that a web service expects and can process is stipulated in a WSDL document which is part of the web service [STA02]. SOAP messages are sent and received via the HTTP Protocol (a binding to the HTTP is not completely necessary as other protocols can also be used. [WOLO1]).

Web services, if they are to be localised by other users, have to be on the one hand registered at a central instance and on the other hand this instance has to support the search for certain web services (e.g. based on the description of an interface). This is when the standard "Universal description Discovery and integration" (UDDI) is enacted. UDDI defines a data structure based on XML and enables the description of a web service which can range from details on the publisher, general details describing the web service, to its technical description whereby reference is often made to an appropriate WSDL document via URL (cp. [ARI00], [WOLO1]). An URL indicating where each web service can be reached is also provided. The information is stored at a UDDI Registry and can be looked at or search for there.(see illustration 3, steps 1, 2 and 3). For this purpose an API is defined by the standard which can be accessed via the SOAP protocol [ARI00]. Various UDDI registries can replicate the entries that have been made. The UDDI registry is only needed for the localisation of web services. At a later stage communication takes place directly between the applications and web services. (see illustration 3, step 4).

[ Illustration 3: Communication between web services ]
Illustration 3: Communication between web services

5.2. Local Data and Web surfaces

Web services encapsulate logic in capsules that cannot always be carried out without special data. Therefore web services must be able to save application specific data and to retrieve it when necessary. Data is to be divided in two parts when this is carried out. Firstly data which is only relevant to the web service and secondly data that that can be used by numerous web services. The web service itself administers local data and it cannot be accessed by other web services. Web services, however, avail of global data that has been provided by either one or several other web services. Here note should be taken of the fact that data cannot be saved as both local and global data (redundancy avoidance).

A large number of users are expected to participate in a learning environment. Some of these will use their own computers with various software and operating systems to access the e-learning systems. The supply of client-software that is compatible with all systems and equipment is a big problem. It becomes an even bigger problem when new versions are realised and have to be exchanged for the already installed local clients. Therefore web services that implement an integral part of a learn system where it is necessary for the user to have direct access should offer a HTML based graphical user interface. Hence the user would only need a HTML browser. It should be considered that if a technology other than HTML e.g. JavaScript or imbedded Java-Applets were used Browser Plugins 4 would then be required. It is necessary to define which technology and version thereof and the resulting Browser (perhaps with the aid of plugins) is to be used in each concrete case.

[ Illustration 4: Web services based architecture ]
Illustration 4: Web services based architecture

Illustration 4 shows the architecture of services within a distributed service based e-learning system needed for the implementation of web services.

5.3. Use of web services

The various tasks and functions of web services have been clearly defined in the WSDL document. The web services are registered at the central UDDI registry and can be localised. Web services can use other web services and thus based on necessity and the task at hand be combined. Over and above and with the additional aid of "Business Process Execution Language for Web Services" it is possible to map complete processes where various web services in a certain order are called and information is exchanged to obtain a certain final result. [CGK +02]

Aspects of security such as authentication and authorisation can be mapped via suitable XML elements in the header of SOAP messages that are exchanged between applications or web services. The corresponding procedure is described in [ADH+02] using WS Security as a SOAP expansion. With regard to this it would seem to be of great advantage to offer a web service that enables authentication and authorisation. This, in turn would enable a user, upon registration for the first and only time, to access the web services of the e-learning system to which they are, according to their rights, entitled (single sign-on).

Web services that encapsulate the integral parts of an e-learning system and where interaction occurs directly with the user should offer a HTML based Graphical User Interface via a HTTP interface. Thus the appearance of the surface of each web service lies in the hands of the developer. In order to facilitate the integration of various surfaces into one common surface the provision of special web services that offers the user the chance to configure and personalise the surface and combines other web services or rather their user surfaces should be taken into consideration.

Platforms as well as programming languages that are not dependant on standards are used for the definition of web service interfaces, for the registration of that and communication with web services. It follows from this that the actual implementation of the application logic can occur in any language. Moreover the interfaces have been clearly defined and allow transparent access to the encapsulated functions even without the knowledge of how they are actually implemented. Web services are therefore easy to exchange. A new web service is all that has to be created to integrate a new function of an e-learning system. The interfaces of this new web service have be defined in a WSDL document and be registered at the UDDI registry. The service is then made available in the system and can be expanded at ease.

Several UDDI registries can replicate with each other that means compare the information with relation to web services. It is therefore possible to use for example two UDDI registries in a learning system that rep with each other. One acts as a back-up system that can be taken into operation if the other fails. Hence the availability of the UDDI registry can be improved.

In order to increase the availability of single web service the introduction of a special monitor web service that systematically monitors all other web services should be considered If a monitor does not get a reply to a query after a certain period of time it can then either inform the system administrator or take appropriate action itself. Additional mechanisms are required to ensure the availability of the monitor but these will not be dealt with here.

Web services that are possibly excessively accessed at certain times should be provided a number of times to ensure that latency remain acceptable. This can, in principle, be carried out by providing the system with several services of the same kind that can be accessed via a special web service with the same interface. This special web service acts as a distributor and disburses incoming queries among web services which are not as burdened and therefore able to deal with them. When required this web service can start or stop a web service similar to the one needed. How much of an advantage this process brings would have to be examined in an individual concrete case. It depends on the amount of work involved in carrying out the application logic of the web service or how much local data is needed and how it is stored. It is also feasible to provide the logic within a web service several times and that the web service be expanded by a further distributor of logic.

[ Illustration 5: Overall architecture based on web services ]
Illustration 5: Overall architecture based on web services 5

The precise separation of local and global data is called for in the following section. A lot of legacy systems contain information that should be made available to the web services (global data). These systems have to be integrated into the e-learning systems to enable web services access to the information contained there. It is possible to do this in two ways. Either the legacy systems are implemented as new web services or a web service is implemented as an adapter that has access to legacy systems data using the proprietary interfaces and that offers other web services [FWK02].

The overall Architecture shown in illustration 5 results from the implementation of services with the aid of web services.

5.4. Comparison with other technology

It can be deducted from the above mentioned explanations that the previously formulated demands placed on service based learning systems can indeed be satisfied with the aid of web services. Therefore web services are in principle suitable for the achievement of such systems. In addition it is worth noting that concepts developed and spurred on by large companies such as Microsoft and IBM have been greeted with great interest within in the industry.

There are other technologies available apart from web services such as JINI, CORBA or DCOM that enable communication between distributed software to take place and can also in principle be used for the implementation of services.

JINI (cp. [SUN01a], [SUN01b]) is based on the programming language JAVA which is not dependant on a particular Platform. Services can be implemented with the aid of JINI. These services can be localised using a service similar to the registry service which is known as a look-up service. In order to communicate with a service, a proxy object which is a serialised Java object found in the Java implemented look up service has to be downloaded. The service interface is defined in the proxy object. If methods on the proxy-object are invoked they will then access the real service. The proxy object has to be implemented in Java so that an application that wants to use a JINI service also has to be implemented in Java. Since Java is not dependant on a particular platform it enables JINI to offer an extensive platform service. However JINI is not independent of programming languages.

A standard called "Common Object Request Broker Architecture" (CORBA) (see [OMG02]) developed by the Object management group (OMG) enables distributed software object communication. There is a software object that for example implements a service and a client object used to access the service. The interface of a software object is defined using the OMG "interface Definition Language" IDL which can be compared to the WSDL standards for web services. Based on the IDL definition Client-Stubs and Object Skeletons are generated for various programming languages. An application that wants to access a remote software object has to integrate the corresponding client stub. The remote object is accessed by the client stub that issues a request for example for a method call to a Object Request Broker (ORB). The ORB then locates the object and forwards the request, via the Object Skeleton, to the corresponding Software Object. When this is being carried out the Client Stub and Object-Skeleton as well as the object implementation do not have to use the same ORB. Various ORBs can communicate with each other using the standardised "Internet Inter ORB Protocol" (IIOP) (cp. [OMG02], [TVS02]).

Whilst WSDL is based on XML. IDL presents a complete new language with is own syntax that has to be learned. The IDL definition can be translated into several programming languages with the aid of a compiler (C, C++, Java, COBOL, Smalltalk, Ada, Lisp or Python). However it can not be translated into all languages. Over and above that the client stub for a specific programming language has to be carried out explicitly. In general web services based on the SOAP protocol can be accessed by every programming language. Additional work is not necessary here.

An additional problem relating to the communication of services may arise with CORBA at run-time. Generally communication is conducted using a an ORB. IF at some point the ORB is not available for use then communication cannot take place. In contrast, web services communicate either directly with each other or applications communicate with web services.

There is an additional tool which allows the integration of distributed software available called "Distributed component Object Model" (DCOM). DCOM is an extension of "Component Object Model" (COM) (see [MSC95]). The Microsoft Corporation developed both technologies. Software components that are to communicate via DCOM have to fulfil a certain binary format that is specified by COM. There is a Microsoft IDL based on the "Distributed Computing Environment" (DCE) IDL where the component interfaces have been defined. This is similar to CORBA. With regard to the IDL definitions, Compilers Proxy Objects and Stubs are made with the aid of the Microsoft IDL compiler. Applications invoked calls up methods from the Proxy Object. The Proxy Object forwards passes the call to the Stub via the DCE RPC which in turn accesses controls the components in question. A COM run-time Laufzeit Environment is needed on the local as well as distant computer. The Proxy object can be found in the local Laufzeit Environment and the Stub in the remote removed run-time Laufzeit Environment (cp. [COR01], [MSC95], [TVS02]).

All programming languages that support the binary format can be used to implement components and applications. That Includes all languages from Microsoft e.g. Visual Basic, Visual C++ or J++. It is also possible to use Java. However that format is not supported by all programming languages. Web services are on the other hand not dependent on the programming languages used.

In addition although DCOM is well supported by Microsoft Windows this cannot be said of other systems. "COM and DCOM are best supported on Windows 95 and NT platforms. However Microsoft has released a version of COM/DCOM for MacOs [...]. Software AG, a Microsoft partner has released DCOM for some UNIX operating systems [...] and Linux. However, DCOM has solidified, the technology is best applied in environments that are primarily Windows-based". [COR01]. Due to the fact that web services are not dependent on any particular platform standards there is no restriction on the choice of operating systems. However the future of DCOM is not clear as Microsoft has also been heavily involved in the development of web services.

Every technique mentioned (JINI, CORBA, and DCOM) have one thing in common. They were not explicitly developed for web communication whilst web services are based on standardised web protocols and enable communication generally via HTTP. Although it is now possible for other techniques to communicate via HTTP it can only be carried out using proprietary proprietäre solutions. As a result of the identification of problems that could arise by using techniques other than the previously presented web services to fulfil the expectations mentioned at the onset, this paper strongly advocates the use of web services for the implementation of distributed service based e-learning systems.

6. An exemplary E-learning System based on Web Services

Resulting from the expectations mentioned and the architecture decide on certain services which can be deemed necessary in a distributed service based system. Over and above these services there are services specific to e-learning systems which can be identified in the learning environment.

The amount of services shown here is not by any means complete but should be seen as an exemplary basic structure of an e-learning system with minimal functions. The system can be expanded with extra services to implement additional functions when necessary. To localise the systems services a UDDI registry has to be provided where the various services can be registered.

General Services
Authentication and Authorisation (Security Service)

A security system which takes care of the authentication and authorisation of users for the system is one of the general services. This service should enable more than just the registration process, it should enable the single sign-on service. This means that users only have to register once to use all parts of the system to which they are entitled and authorised. This service should act as a centre for all other services in the system that have to check if a user has the right to access or not.

User Administration Directory Service

The security service requires that a directory service is available to help with user administration. The directory service administers the authorised users log in and password information. It can also grant the right to use certain parts of the whole system. Other methods used for authentication such as digital signature or biometrics can also be used.

User interface(UI service)

There has to be a service which administers the courses and their content in e-learning systems comparable to course services at a universities. Information that has to be administered includes the name of the event, the tutor, examination details and where course relevant literature can be found. Students have to be able to access the information and trainers have to be able to maintain the information. A function where students can register for events is desirable in certain cases.

The service should not only administer information on courses and course material but should also offer the link where the content can be retrieved to file or call content required for online learning (Wweb Bbased Ttraining). With regard to this it would be a good idea to offer an interface that enables content to be processed in SCORM format 6.

Exercise Service

Exercises are normally offered with courses. A service which administers student registration foe these exercises and their answers to these exercises would be of advantage. An appropriate learning content sharing system Inhaltsanbindung based on the SCORM format is also needed. Tutors have to be able to maintain the exercises.

Exam Service

If exams are to be taken then a service has to be implemented that takes registrations and hands out results (Exam Service). Trainers have to be able to maintain the exams using a service. It would be of advantage to define the order in which exams can be taken so that students so can only take certain exams on completion of other exams. Exams can be carried out online when required.

Digital course book (Study Record Service)

There also has to be a service which gives the student an overview of courses taken, exercises and exams completed as well as results received (Study Record Service). This service can be compared with a course information book available at universities. The integration of a coaching component that advises students on other courses available which relate to their course choices to date is also desirable.

Prüfungsverwaltung (Exam Service)

7. Summary

This paper described the problems with and expectations of modern e-learning systems. It was shown that the systems currently available on the market can only partly fulfil these expectations Several of these systems are large and have been monolithically programmed. They are not easy to extense or adjust and seldom provide interfaces that enable communication with other systems. However contemporary e-learning systems have to fulfil these expectations especially if they are to be optimally used in universities and other modern educational institutes. Web services, a relatively new technology has been presented as the solution. The reasons for this choice have been explained and the first suggestions for the convenient distribution in individual functional programmes have been made.

Finally it should be noted that solutions are also offered by the other techniques which have been described. The use of web services was chosen because they, in the authors opinion, best address the expectations placed on modern e-learning systems

8. Literature

[ADH+02] Bob Atkinson, Giovanni Della-Libera, Satoshi Hada, Maryann Hondo, Phillip Hallam-Baker, Johannes Klein, Brian LaMacchia, Paul Leach, John Manferdelli, Hiroshi Maruyama, Anthony Nadalin, Nataraj Nagaratnam, Hemma Prafullchandra, John Shewchuk, Dan Simon. Web Services Security (WS-Security), April 2002.
[ADL01] Advanced Distributed Learning Initiative. Sharable Content Object Reference Model (SCORM). The SCORM Overview, Version 1.2, October 2001.
[ARI00] ARIBA, INC., INTERNATIONAL BUSINESS MACHINES CORPORATION AND MICROSOFT CORPORATION. Universal Description, Discovery and Integration (UDDI) Technical White Paper, September 2000.
[CGK+02] Francisco Curbera, Yaron Goland, Johannes Klein, Frank Leymann, Dieter Roller, Satish Thatte, Sanjiva Weerawarana. Business Process Execution Language for Web Services, Version 1.0, July 2002.
[COR01] Santiago Comella-Dorda. Component Object Model (COM), DCOM, and Related Capabilities, Software Technology Review, Carnegie Mellon Software Engineering Institute, März 2001, am 12.11.2002.
[CS02] Initiative CampusSource des Landes NRW. November 2002,  [ German Version ] am 17.11.2002.
[FWK02] Paul Fremantle, Sanjiva Weerawarana, and Rania Khalaf. Enterprise Services, Communications of the ACM, Vol. 45, No. 10, ACM Press, October 2002.
[GHJV95] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object Oriented Software, Addison-Wesley, Reading, MA, 1995.
[IBM00] IBM Web Services Architecture Team. Web Services architecture overview, September 2000, am 21.10.2002.
[KP88] Glenn E. Krasner and Stephen T. Pope. A cookbook for using the model-view controller user interface paradigm in Smalltalk -80, Journal of Object-Oriented Programming, 1(3):26-49, August/September 1988.
[MSC95] Microsoft Corporation. The Component Object Model Specification, Draft, Redmond, Oktober 1995, am 22.11.02.
[NBS+99] M. Nagl, H. Balzert, H. -W. Six, W. Schäfer, U. Kelter, A. Behle, B. Westfechtel, C. Weidauer, P. Pauen, J.Voss, J.P. Wadsack. Studie über Softwaretechnische Anforderungen an multimediale Lehr- und Lernsysteme, September 1999.
[OMG02] Object Management Group. Common Object Request Broker Architecture: Core Specification, Version 3.0, November 2002, am 22.11.02.
[STA02] Michael Stal. Web services: beyond component-based computing, Communications of the ACM, Vol. 45, No. 10, ACM Press, October 2002.
[SUN01a] Sun Microsystems. Jini Architecture Specification, Version 1.2, December 2001.
[SUN01b] Sun Microsystems. Jini Technology Core Platform Specification, Version 1.2, December 2001.
[TVS02] Andrew Tanenbaum und Maarten van Steen. Distributed Systems, Principles and Paradigms, Prentice Hall, 2002.
[W3C02] Web Services Architecture Working Group. Web Services Architecture Requirements,W3C Working Draft, October 2002, am 21.10.2002.
[WOL01] Roger Wolter, MICROSOFT CORPORATION. XML Web Services Basics, December 2001.
[ZFU] Zentralstelle für Fernunterricht, Bundesinstitut für Berufsbildung. Auszug aus dem Ratgeber für Fernunterricht der staatlichen Zentralstelle für Fernunterricht (ZFU) und dem Bundesinstitut für Berufsbildung (BIBB).  [ German Version ]

1 Supported by the Federal Ministry for education and research within the research project "New media in the education - Notebook University"
2 Hypertext Transfer Protokoll
3 Application Programming Interface
4 Plugins are small programs to extend the functionality of a web-browser.
5 The UDDI registry does not appear in the illustration to keep it as simple as possible. It does of course have to be available to the system at least once in the form of a service
6 More informations about SCORM p.e. under [ADL01] and also