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.

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.

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.

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.

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.

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).

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

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.

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:

they are registered and can be localised via a service registry
Services are registered at a network. This entails telling the network what their IP address is and what kind of functions they can offer. If, at some point, their functions are needed it is possible to search the network for them and then the appropriate service can be used.

they support loosely joined connections between systems
By registering various services with the network it is possible to start several services with the same function. This process is then registered with the network. Therefore scaling can be significantly increased because the burden has been distributed among services which are similar to each other. The likelihood of system failure can be significantly reduced because if one service fails another one can be called on immediately.

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.

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

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
8
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
shows the architecture of services within a distributed service based e-learning system needed for the implementation 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.

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.

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 ServicesAuthentication 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)

A service is also required that enables a user access to the system using a suitable user interface (UI). It would be
convenient if the interface could be configured in a personal and flexible manner so that the user interfaces of certain
services can be combined and presented according to personal preference analogue tio a portal which can be personalised (cp.
chapter 5.3).
A user can then start using the system according to their preferences and needs.

Special ServicesEvent administration (course 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
15.

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.

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