ADJUSTMENT NEEDS IN SOA BASED E-LEARNING
APPLICATIONS
Antonio Ortiz, Juan Manuel de Blas and José María Gutiérrez
Computer Science Department. Technical School of Computer Science Engineering. University of Alcala
28871 Alcalá de Henares, Madrid, Spain
Keywords: Service-Oriented Architecture, Web Services, E-learning systems, Software reuse, Interoperability.
Abstract: SOA is a promising emerging technology and as such, it still has to solve certain issues. This paper
describes the solutions made to solve some interoperability issues found while carrying out an
interconnection project of two SOA based systems. It is supposed that the solutions can help to avoid the
problems in the future or solve incompatibilities. Not only in these projects, but also in similar ones, as the
proposed solutions are not tied to a specific implementation. Both systems were developed using the same
programming language, although they were based on different software platforms. These solutions are based
on the analysis and the tests accomplished, where simple data structures were sent and received, using the
Java language. This document also demonstrates the current state of interoperability in today’s frameworks,
which are not fully compliant yet, and are still rather weak using complex data structures.
1 INTRODUCTION
The Computer Science Department of the University
of Alcalá, is developing an e-learning application,
composed by many subsystems. Two of these
subsystems, self independent, are the subject of this
study.
Both systems needed a reliable communication
mechanism, and it was decided to use Web Services
to implement them, since there was the possibility
that they used different programming languages.
Web Services architecture allows developers and
corporations to encapsulate business logic, publish it
as services, subscribe to other services, and share
data between systems. One of the main benefits
derived from using this technology is a considerable
reduction in difficulty to intercommunicate along
different components, offering a view of those
components as a service-based architecture, fully
Internet compatible.
Due to the fact that the project uses Web
Services, a complete interoperability was expected.
However, in the process of integration of the two
subsystems, some incompatibility issues were found.
After detecting these interoperability problems,
that were previously spotted by other authors
(Severine, 2005), (Aragão and Fernandes, 2003) and
(Söderström, 2005), it was necessary to tweak the
core logic to achieve a satisfactory integration
between these two systems. On the following
chapters, the steps taken to gain interoperability are
detailed, also describing the necessary standards and
guides followed.
2 INTEROPERABILITY
STANDARDS AND GUIDES
Web Services are based on the SOAP standard, with
current release 1.2 (SOAP, 2003). It is an XML-
based protocol used to access services on the Web. It
was originally developed by IBM and Microsoft.
SOAP main purpose is, in fact, similar to others
object distributed systems, such as DCOM and
CORBA, but less resource-consuming and easier to
develop and maintain. It uses XML syntax to send
messages over the Internet using the HTTP protocol.
In addition, it can be concluded that because SOAP
uses a simple interchange message system, SOAP
can be used a messaging system as well.
Therefore, SOAP is the element that allows
communication between heterogeneous systems,
thanks to the use of a common language like XML.
However, in order to ensure interoperability across
123
Ortiz A., Manuel de Blas J. and María Gutiérrez J. (2007).
ADJUSTMENT NEEDS IN SOA BASED E-LEARNING APPLICATIONS.
In Proceedings of the Third International Conference on Web Information Systems and Technologies - Internet Technology, pages 123-127
DOI: 10.5220/0001261901230127
Copyright
c
SciTePress
platforms, operating systems, and programming
languages, an organization was created. This
organization is the WS-I, (Web Services
Interoperability) (WS-I, 2006), which gives
guidelines, creates and promotes generic
communication protocols, achieving to be a referent
in Web Services interoperability among different
platforms and programming languages.
WS-I Basic profile is one of the most important
guidelines. The version 1.0 was released on August
2003, and solved more than 200 interoperability
issues. Among others, some of the standards that can
be found in WS-I BP are SOAP 1.1, WSDL 1.1,
UDDI 2.0, XML 1.0 y XML Schema.
Version 1.1 was released in April, 2006, and it
included some improvements such as file attachment
support (SwA). Some of the new requirements are
described in the John Evdemon (Evdemon, 2004)
personal blog, who is a specialist in business
projects and workflow technologies.
WS-I also works on rules that ensure
interoperability using secure SOAP messaging
systems. The workgroup in charge is named Basic
Security Profile Working Group, which also is in
charge of some specifications developed by OASIS
(OASIS, 2006). OASIS is a consortium that aids
development, convergence and adoption of new
standards. The more relevant of them are the ones
that care about secure interoperable Web Services. It
has a technical committee named Web Services
Security TC (WSS), which objective is to carry on
the work described on the WS-Security specification
that was released in the context of Web Services
Security Roadmap, published on April 2002. One of
the most important specifications described is WS-
Security (WS-Security 1.0 y WS-Security 1.1). This
specification cares about security, using previously
defined specifications and standards, avoiding
defining a complete security solution, and proposing
an existing set of SOAP (SOAP 1.1 and SOAP 1.2)
extensions, allowing the use of secure Web Services
through a great variety of security models such as
Kerberos, PKI, and SSL.
It is clear that there are organizations that care
about ensuring interoperability, developing rules and
guidelines. Now, it is necessary to test if the uses of
these guidelines are enough to make interoperable
systems or something more is needed.
3 COMPLETED PROJECTS
The first system (Figure 1) belongs to the PROFIT
research project “FIT-350101-2004-7”, named
“Educational virtual resources management and
exploitation platform”, which aims to create a
learning management platform that will use a digital
repository to store the data.
During development process guidelines from
IMS DRI (DRI, 2003) were followed and the
Codehaus XFire (Codehaus, 2006) platform was
used for the core functions. The choice of this
platform was due to its easy of use, its standard
compliance, and it open source characteristic.
Figure 1: Digital Repository Interface.
The second system (Figure 2), named SROA
(Learning Object Reusability System), is part of
another research project: PROFIT “FIT-350101-
2005-4”, named “Publication and universal location
of learning objects system”. The goals of this project
are to analyze and design a prototype system to
assemble courses by reuse existing content located
in diverse remote repositories.
Figure 2: SROA system interface.
WEBIST 2007 - International Conference on Web Information Systems and Technologies
124
The first prototypes created (Otón et. all, 2006A)
and (Otón et. all, 2006B), were able to demonstrate
that systems following these guides and architecture
(Otón et. all, 2005), are able to distribute educative
resources along many different e-learning platforms,
by making their respective repositories
interoperable.
IMS Abstract Framework (AF, 2003)
specifications were used during the development
process, and Web Services were used as well. This
second system uses Systinet Server platform
(Systinet, 2006), because it is easily integrated into
the Eclipse development software. Systinet Server
for Java offers high performance, interoperability,
reliable delivery and security. This platform is
widely deployed by industry leaders including
Barclays Global Capital, T-Mobile and FileNet
(Systinet, 2006).
Once both systems development reached an
advanced stated, the integration process began, in
order to build completely standalone system, as
shown in Figure 3.
Figure 3: Scheme of the integrated system.
3.1 Observed Problems and Proposed
Solutions
By using Web Services and its possibilities to
communicate heterogeneous systems it is avoided
the need of use of special connection mechanism for
connecting different language based systems.
However, the Web Services servers used were not
the same and although no importance was given to
this aspect, at the beginning. Later it was discovered
that the integration was not seamlessly, as the results
were not the expected ones. Foregoing reason, it was
detected the necessity to make a higher effort in
order to obtain a complete interoperability between
both systems.
The first step was to ensure that the servers used
fulfilled the recommendations dictated by the WS-I;
information that is shown in the table 1.
Table 1: Main characteristics of the servers used.
Systinet 6.0 XFire 1.2
SOAP 1.1
SOAP 1.2
SwA
WSDL 1.1
WSDL 2.0
UDDI V2
UDDI V3
WS-I BP 1.0
WS-I BP 1.1
MTOM/XOP
WS-Security
WS-Addressing
WS- R. Messaging
The following conclusions are extracted from the
previous table:
Both servers fulfil the interoperability
recommendations developed by the WS-I
(highlighted rows of the table). The fulfilment
of these procedures should be an essential
requirement for selecting a server as a
platform to use for developing SOA
architecture.
They all fulfil the main standards that shape
the Web Services (SOAP 1.1, SOAP 1.2 and
WSDL 1.1). Only one exception is found, the
XFire server, failing the SwA requirement
(SOAP with Attachment), using MTOM
(Message Transmission Optimization
Mechanism, MTOM 2005) instead to send
files. None of the servers fulfils WSDL 2.0;
mainly because it is not a standard yet, only a
candidate recommendation as of March 2006
(WSDL, 2006).
About secure interoperability connections
(WS-Security, WS-Addressing and WS-
Reliable Messaging), it is also fulfilled by
both servers, with the exception of XFire
server, that does not fulfil WS-Reliable
Messaging recommendation.
This information should guarantee, at least from
a theoretical point of view, a certain level of
interoperability, which is required when developing
interoperable service oriented systems. Nevertheless,
when testing the interconnection, the obtained
results were not the awaited ones.
The SROA system has to perform a learning
object search on the repository, and then return to
ADJUSTMENT NEEDS IN SOA BASED E-LEARNING APPLICATIONS
125
the client those objects that meet the parameters
marked by the user. To send the files across the
wire, a Systinet's proprietary class was used: the
ResponseMessageAttachment class, which turned
out to be incompatible with the other platform. So,
the first interoperability problem was found, but it
was solved using byte arrays (byte []). Because it is
a primitive type (available in all the platforms), its
use ensures interoperability.
This solution is not perfect; because another
problem appears, the whole content of the file is
loaded into memory. The solution to this can be to
transfer it across streaming. Tests were also
performed using DataHandler and DataSource
classes, recommended by Sun when SAAJ is not
used (SAAJ, 2006). At the end, also these classes
turned out to be incompatible as well.
When returning the learning object list, the
SROA system use complex objects. These objects
(JavaBean) incorporate different attributes, such as
an indicator of the operation state, or a collection
(ArrayList) of new JavaBean generated in the
operation. The above mentioned objects represent
each of the learning objects that match the
parameters of the search. These types of structures
are widely used in the Java language, but they
produce some interoperability problems. After
trying, without success, to return an object-only
collection, parameterization of the data inside was
necessary, and to encapsulate it inside another object
in order that at least the transmitted information was
recognized across the SOAP applications that are
included with the platforms.
Another problem was found sending files using
SOAP. It was necessary to deactivate the MTOM
(MTOM, 2005) support in the XFire platform in
order to achieve a complete interoperability, because
the platform used in the other project did not support
it.
On the following paragraph, an example of the
SOAP message sent by the platform SROA to the
Repository is shown, being outlined in boldface the
most relevant information. It can be observed how
this information is grouped in a complex object
called DatosBusquedaBean, including a file type. To
process the sending of this file, the system
decomposes in bytes (base64Binary), because the
inclusion of it in the SOAP message once MTOM is
deactivated.
<e:Envelope
xmlns:d="http://www.w3.org/2001/XMLSchema"
xmlns:e="http://schemas.xmlsoap.org/soap/env
elope/"
xmlns:i="http://www.w3.org/2001/XMLSchema-
instance"
xmlns:wn0="http://bean.common.busqueda.sroa.
org"
xmlns:wn1="http://xfire.codehaus.org/Servici
oWebMetadatosRepositorio">
<e:Body>
<wn1:buscarLOEnRepositorio>
<wn1:db
i:type="wn0:DatosBusquedaBean">
<wn0:ficheroXEL
i:type="d:base64Binary">PD9lkjdfldkjgsldk
fgjsvGJDDOgjjsdfgldgorkgsdFSDJofg4wgdmuuhjsh
… … …
JhdohjakldjvsakjhsaklvnsnaasjSSJDjsjdSJDjsjo
wekjkdsfgjlskjdfasDJDSJDSdjldvalkbnRlbnQ+
</wn0:ficheroXEL>
<wn0:forzarGeneracionXEL
i:type="d:boolean">0
</wn0:forzarGeneracionXEL>
<wn0:opcionBusqueda
i:type="d:int">1
</wn0:opcionBusqueda>
<wn0:porcentajeCoincidencia
i:type="d:float">20.0
</wn0:porcentajeCoincidencia>
</wn1:db>
</wn1:buscarLOEnRepositorio>
</e:Body>
</e:Envelope>
The returned error found when the SROA system
tries to send a file to a client that uses MTOM is
shown in the following code. The transmitter sends
the file as a stream of bytes inside the SOAP
message, whereas in destiny the receiver expects this
file to be out of the SOAP message.
Unsupported media type: application/xop+xml;
charset=UTF-8; type="text/xml"
at
com.systinet.saaj.soap.SOAPPartImpl.checkCon
tentType(SOAPPartImpl.java:486)
4 CONCLUSIONS
Web Services and SOA architectures, with all their
presented features, were met with a great
enthusiasm, because, it was possible to interconnect
heterogeneous systems, as the market demanded.
The possibility of using the language and the
platform most adapted to every purpose, to finally
obtain a complete system composed by independent
elements, was finally possible. Nevertheless, and
after our own experience, it is possible to conclude
indicating that the obtained results are not as ideal as
the announced ones by the organizations and the
manufacturers.
The system integration was possible, although it
has been necessary to do modifications in the
transmission protocols used, and in the information
sent, reducing notably its complexity. Therefore,
WEBIST 2007 - International Conference on Web Information Systems and Technologies
126
Web Services interoperability at this moment does
not reach the degree of awaited fulfilment.
During the testing stage, the obtained results
reveal that working with simple data (primitive
types), guarantees interoperability. Greater problems
arise when the information is more complex, for
instance when using JavaBeans, because this
information is handled in different ways depending
on the platforms used.
Another detected disadvantage is the inability to
use common structures in the Java environments, as
the Collection objects. Depending on the server, it is
possible to use them as a return type for the
methods, being handled all in a different way by
almost all of the servers, when its use is possible. It
has been observed that every platform adapts the
WSDL file to its own needs, resulting in
incompatibilities among platforms, and producing
errors while sending data, because the format of the
message sent is different from to the expected by the
receiver.
On top of that, with all of these issues exposed, it
is expected that future works should be carried out
with that limitations on mind, focusing the problems
from another point of view and making easier the
process of dealing the limitations.
In the future, it will be necessary for the
organizations as the mentioned WS-I, OASIS, and
the implementation manufacturers, to continue
improving the recommendations. For example, the
automation in the complex information sending (as
JavaBeans), or the possibility of using compatible
Streaming systems.
Without fulfilling with these expectations, Web
Services use will be limited as occurs with other
solutions on the market, such as RMI or CORBA. If
this goal is achieved, the use of Web Services will
be extended to all kinds of applications that need
data transmission over the Internet.
REFERENCES
Severine, B., 2005. “Interoperability problems:
management of evolution of collaborative enterprises”.
In INTEROP-ESA’05, 1st International Conference
on Interoperability of Enterprise Software and
Applications.
Aragão, R., Fernandes, A., 2003. “Conflict Resolution in
Web Services Federations”. In ICWS’03, 1st
International Conference on Web Services.
Söderström, E., 2005. “Web services and inter-
operability”. In INTEROP-ESA’05, 1st International
Conference on Interoperability of Enterprise Software
and Applications.
IMS DRI. 2003. IMS Digital Repositories Interoperability,
http://www.imsglobal.org/digitalrepositories/index.ht
ml
Codehaus Xfire. 2006. http://xfire.codehaus.org/
Otón, S., Ortiz, A., Barchino, R. 2006A. “Arquitectura
orientada a servicios Web para la implementación de
repositorios distribuidos de objetos de aprendizaje”. In
IADIS WWW/Internet’06. International Association
for Development of the Information Society
Otón, S., Ortiz, A., Hilera, J.R. 2006B. “Sistema de
reutilización de objetos de aprendizaje”. In VIII
congreso Iberoamericano de Informática Educativa.
Otón, S., Hilera, J.R., Gutiérrez, I., Ortiz, A. 2005.
“Arquitectura orientada a servicios Web para la
implementación de repositorios distribuidos de objetos
de aprendizaje”. In SINTICE’05. Simposio Nacional
de Tecnologías de la Información y las
Comunicaciones en la Educación.
IMS AF. 2003. IMS Abstract Framework,
http://www.imsproject.org/af/index.html
Systinet Corporation, http://www.systinet.com/
WSDL 2.0. 2006. Web Services Description Language 2.0
Candidate Recommendation 27 March 2006,
http://www.w3.org/TR/wsdl20/
SAAJ. 2006. SOAP with Attachments API for Java,
http://java.sun.com/webservices/saaj/index.jsp
MTOM. 2005. SOAP Message Transmission Optimization
Mechanism, http://www.w3.org/TR/soap12-mtom/
WS-I. 2006. Web Services Interoperability Organization,
http://www.ws-i.org
SOAP 1.2. 2003. Simple Object Access Protocol 1.2
Recommendation 24 June 2003,
http://www.w3.org/TR/soap/
Evdemon, J. 2004. “What's changed in WS-I Basic Profile
1.1?”.http://blogs.msdn.com/jevdemon/archive/2004/0
8/25/220353.aspx
OASIS. 2006. Organization for the Advancement of
Structured Information Standards. http://www.oasis-
open.org/home/index.php
ADJUSTMENT NEEDS IN SOA BASED E-LEARNING APPLICATIONS
127