> IEEE MULTIDISCIPLINARY ENGINEERING EDUCATION MAGAZINE, VOL. X, NO.

X, MONTH YEAR<

13

Providing reliable use of Semantic Web Services in Educational systems

Heitor Barros, Marlos Silva, Ig Ibert Bittencourt, Evandro Costa, Aydano Machado, Douglas Vras
machine-understandable form. In some applications, it is also necessary to provide application services that machines and intelligent agents can understand, select, compose and invoke automatically. This is possible through the use of Semantic Web Services [19], the focus of this work. Semantic Web Services appears in the intersection between the Web Services technology and Semantic Web. It inherits characteristics from both approaches, semantic interoperability from Semantic Web and dynamics of resources available on the Web Services technology [8]. The use of services becomes attractive in the construction of educational systems due to its dynamism and offer easy system extensibility and scalability. In this context, the use of semantic annotations for these services enables automation of the processes of service discovery and composition [1]. The use of Semantic Web Services in Educational Systems effectiveness has been proven in various applications developed by our research group, such as: i) MASSAYO-LMS [4]: A Learning Management System based in Semantic Web Technologies, ii) LPS-STI [26]: A Semantic Web-Based Soft-ware Product Line for Building Intelligent Tutoring Systems, iii) SEDAM [16]: A framework to provide educational data mining based in Semantic Web Services and iv) Fraw [25]: An Interactive Learning Environment for Fraction Domain through the Web. The use of Semantic Web Services enable software reuse in an automated manner, i.e. applications can interpret how to use and goals of these services based on its semantic annotations. Thus, applications can reason over these semantic annotations and decide whether or not to use this service without direct interference from human agents. Due to this characteristic, the development of systems based on semantic web services becomes faster due to the possibility of using services developed in previous applications or by third parties. However, due to automation in the reuse of services, it is not always possible to guarantee the quality of these services, especially in services developed by third parties. Thus, we cannot guarantee that the service will be available when requested, and if not available the system should provide mechanisms to continue running without this service [10]. In addition, services are not free of bugs and errors in its implementation. The invocation of these services can generate incorrect results, compromising the proper functioning of the application functionality. In this sense, the application that makes use of these services must provide mechanisms to verify the correctness of results provided by them [28].

AbstractSemantic Web Services propose the use of ontologies that provide semantic descriptions to traditional Web Services. Thus, it becomes possible to create mechanisms that can reason about these ontologies and interpret the service goals and how to use it. Therefore, the use of Semantic Web Services allows automating the processes of discovery, composition and invocation of services. However, service consumers must be concerned with some factors that may compromise the reliability of the system, as an unavailable service or a service that produces incorrect results. So applications that use services should provide mechanisms that can ensure reliability in face of these problems. In this perspective, this paper proposes a middleware that provides the reliable use of semantic services, providing a mechanism for fault tolerance and support for restrictions to evaluate the correctness in the results of services, besides allowing discovery and service composition. To evaluate our proposal, we present a case study that demonstrates its operation before the use of a service that produces incorrect results, within the context of educational systems Index Terms Reliability, Semantic Web Services, Services Composition, Services discovery.

I. INTRODUCTION agents can navigate through Web documents and perform sophisticated tasks. Nowadays, we can observe a great demand for Semantic Web-based applications [3] due to its robustness on providing rich data description mechanisms, such as Ontologies [12]. In this manner, researchers and industry start to use Semantic Web inside their Web applications to express information accurately. As a consequence, software agents become able to process, share, reuse and understand the terms being described and take better decisions according to the information processed by Semantic Web tools, for example, Semantic search engines [9]. Semantic Web requires explicit declaration of knowledge by using ontologies to represent information in a
Manuscript received Feb. 9, 2011. Heitor Barros and Marlos Silva are with Federal University of Campina Grande, Campina Grande, Brazil. (E-mail: {heitor.barros, marlos} @copin.ufcg.edu.br). Ig Ibert Bittencourt, Evandro Costa and Aydano Machado are with Federal University of Alagoas, Alagoas, Brazil. (E-mail: {ig.ibet, evandro, aydano}@ic.ufal.br). Publisher Identification Number 1558-7908-2011-8

EMANTIC Web provides an environment where software

1558-7908 2011 IEEE Education Society Students Activities Committee (EdSocSAC)

http://www.ieee.org/edsocsac

> IEEE MULTIDISCIPLINARY ENGINEERING EDUCATION MAGAZINE, VOL. X, NO. X, MONTH YEAR< In this context, this paper aims to present techniques to enable reliable use of Semantic Web Services using Grinv [1] as a tool for automatic discovery, composition and invocation of services, within the context of educational systems. Initially, we introduce some concepts related to reliability in use of services. Then, Grinv middleware is reviewed, showing details of its main concepts, functionality and implementation. To evaluate our proposal, we present two scenarios that illustrate the operation and efficiency of use of the Grinv to provide confidence in use of semantic services. II. RELIABILITY IN SERVICE ORIENTED SYSTEMS Software reliability can be defined as the probability of failure-free operation of a computer program for a specified time in a specified environment [21]. In systems based on Web Services, it is necessary to use mechanisms that provide confidence in use of these services, otherwise the system becomes vulnerable. In the use of services, we can identify two types of errors that can cause system problems: Service cannot be relied: to use Web Services, there is the possibility of failure in the execution of a service due to network problems or unavailability of a service. If this fault is not treated, the system may stop running or work incorrectly. Service provides incorrect results: Like all kinds of software, services may contain bugs that cause the provision of incorrect results in certain scenarios. Moreover, due to the reuse of services, the service user is not always its developer, this implies an uncertainty regarding the real objectives and operation of these services. Thus, an application can use a service that does not meet your expectations. This type of failure is more serious because, if untreated, it can cause the system to work with inconsistent data that could lead to significant problems. Zhang defines requirements to ensure reliability in Web Services based Systems [28], as shown in Figure 1. These requirements are divided into functional and non-functional, as can be seen below:

14

of producing acceptable results even though it is faulty. Testability: implies that the Web service allows existing faults to be detected in test time. Non-functional Requirements: Interoperability: implies that the Web service coexists with other system components in the context of a specific system environment. Timeliness: take into account availability and performance. o Availability: implies that the Web service is available at the invocation time. o Performance: implies that the Web service delivers at an acceptable speed at the invocation time. Analyzing this definition, we can see that the Correctness and Testability requirements are directly related, i.e. to verify the correctness of the invocation of a service is needed to test this service. Taking over the types of errors mentioned previously, the Service cannot be relied fault is related to fault tolerance requirement, while the error Service provides incorrect results is related to Correctness and Testability requirements. Non-functional requirements are related to issues of QoS (Quality of Software). A. Impact of fault in Educational Systems The existence of faults in educational systems directly influences the cognitive development of students in this system. For example, a Problem Solving module aims to assist students in resolving questions about a particular object of study. If this module is defective, this system can display incorrect answers, students will rely on the recommendations of the system and will learn incorrectly. Likewise, if the system stops working during the execution of a functionality, such as occurs if a service cannot be relied upon, the student will be directly affected by not getting help from the system, which can cause discouragement to continue their studies. This scenario shows the need to address shortcomings in educational systems. In this sense, the objective of this work is to propose the use of the Grinv to provide reliability in educational systems based on semantic services. In this article we discuss the functional requirements presented in Figure 1. The Grinv fault tolerance mechanism was presented in [1], so this article will focus on solving the remaining problems relating to functional requirements (Service Provider incorrect results). Although not addressing the non-functional requirements in this article, using the Grinv is possible to attend these requirements through the discovery and composition mechanisms that take into account QoS. III. GRINV

Fig. 1. Requirements for Web Services (adapted from [28]).

Functional Requirements: Correctness: implies that the Web service generates reasonable output from input derived from the problem domain. Fault tolerance: implies that the Web service is capable

Grinv Middleware [1] aims at providing discovery, composition, and automatic invocation of Semantic Web Services processes in an extensible way and also transparent to users. In this manner, developers can modify the techniques/algorithms used in the service discovery and composition without cause major impacts to the rest of the

1558-7908 2011 IEEE Education Society Students Activities Committee (EdSocSAC)

http://www.ieee.org/edsocsac

> IEEE MULTIDISCIPLINARY ENGINEERING EDUCATION MAGAZINE, VOL. X, NO. X, MONTH YEAR< system. Grinv also provides a repository of services that aims to minimize the performance problem found in the loading of ontologies. In addition to this, Grinv can be integrated to others technologies of services repository and providing a mechanism for fault tolerance, as we will show next. Regarding the approach to service description, the SAWSDL [11] is the current W3C recommendation. It represents a conservative and incremental approach to introducing semantic characterization of Web services into mainstream Web service practices. Its objectives are modest. For example, it aims to provide semantic characterization of a services input and output types, which can be useful in disambiguating those types in the context of simple forms of service discovery. But it does not aim to provide a comprehensive framework to support more sophisticated approaches to discovery, composition, or any of the other service-related tasks that Semantic Web services research hopes to automate [18]. SAWSDL does not specify a particular semantic framework to characterize the semantics of Web services. Rather, it defines a small set of WSDL1 extension attributes. These extensions may be used to refer to constructs within any external semantic framework. SAWSDL is completely noncommittal regarding the choice of semantic framework [18]. Thus, more sophisticated semantic frameworks are more appropriate to allow the execution of more complex tasks such as WSMO [24] or OWL-S [17], both are W3C submissions. WSMO and OWL-S aim at representing Web services that make an essential use of ontologies from the Semantic Web, and the goals of both efforts is to support more effective discovery, composition and interoperation. The two efforts take very different approaches. WSMO stresses the role of mediation in order to support automatic interoperation between Web services, while OWL-S stresses action representation to support planning processes that provide automatic composition [23]. WSMO is based on WSML (Web Services Modeling Language) for building the semantic descriptions of services [24]. WSML is a language to create ontologies that is not derived from XML or OWL (W3C recommendation for the construction of ontologies in the Semantic Web). The consequence of this is incompatibility among the tools that manipulate other WSMO and OWL-based tools. In this case, the system need tools capable of interpreting ontologies described in OWL and in WSML, which requires the developer to conduct a series of mappings between these two languages. In contrast, OWL-S is based on OWL that allows an easy integration of OWL-S tools and proposed tools for manipulating ontologies in OWL, such as Jena2 (Jena is one of the most widely used Java APIs for RDF and OWL). In addition, a number of tools have been proposed for discovery and dynamic composition of services based on OWL-S, such as [22], [27], and [15] and [6].
2 Web Services Description Language (www.w3.org/TR/wsdl) 2 jena.sourceforge.net/

15

With that in mind, the OWL-S was chosen to describe the services semantically. Grinv has been developed using the Java language. OWL-S API 3 , based in Jena [14], was used for manipulation of semantic descriptions of services. Although the choice of OWL-S, the developer can extend Grinv in order to support other approaches, such as SAWSDL. In this case, the steps in [18] can be used to integrate SAWSDL and OWL-S. A. Middleware Architecture The Figure 2 illustrates the Middleware high-level architecture. The modules of this architecture are commented below:

Fig. 2. Grinv Architecture.

Request Manager: It is the kernel of Grinv Middleware, been responsible for indicating the flow of processes that must be performed to attend the users requests. It is also responsible for assessing the results of requests, as well as implement measures to correct possible errors in these results. Discovery Controller: This module is responsible for finding out what is the best service in system repository to attend the descriptions sent by the user, this module has a set of discovery algorithms to perform this task. Discovery Controller is able to do discovery using Planning. In discovery using planning, the user creates the workflow service that he wishes to invoke, describing the services that make up this workflow. Then the Middleware uses these descriptions to find the services present in the repository that fit these descriptions. Invocation Controller: This module is responsible for invoking automatically a service been provided by user or discovered by Discovery module. This module must be capable of invoke simple (a single service) and composed processes in a
3 Available at http://on.cs.unibas.ch/owls-api/

1558-7908 2011 IEEE Education Society Students Activities Committee (EdSocSAC)

http://www.ieee.org/edsocsac

> IEEE MULTIDISCIPLINARY ENGINEERING EDUCATION MAGAZINE, VOL. X, NO. X, MONTH YEAR< transparent manner. This module is also able to perform the invocation of a Planning discovery. Repository Manager: This module has the function to store the services that are used by other modules of architecture. It is implemented using Sesame[5] to store and manipulate ontologies that describe the services. As Sesame stores the ontologies in a data base, this module has routines to verify updates that may occur in the ontologies provided in Web and update the content of the data base. The Repository Manager has access to two repositories: the Services Repository (SR) is responsible to store the services that will be used by the system, the Services Under Observation (SUO) repository has services that presents problems during the discovery or invocation processes (i.e. Semantic description not provided in the Web, Web Service cannot be invoked, error during execution of the Service). The services that are found in the SUO stay isolated, in order that their problems do not affect the system performance, and they are under constant evaluation to verify if these services return to their usual behavior in order that they can be reintegrated to the system. Configuration: This module is responsible to adjust the system according to the configurations done by the user, that is, this module loads the configuration files that indicate the discovery algorithms that will be used, the invocation and politic mechanisms of the repository. More details about these configurations files will be shown in the case study. B. Fault Tolerance Mechanism This mechanism has been specified in [1]. As previously mentioned, systems based on Semantic Web Services must provide mechanisms for fault tolerance. Grinv offers fault tolerance through the error detection in the mechanisms of services invocation (Invocation Controller) and, when the error is detected, the Repository Manager removes the defective service of the Services Repository (SR) and add it in the Repository Services Under Observation (SUO), making this defective service do not be used anymore by the system. After the removal of the defective service, a new discovery process is performed by the Discovery Controller module to search a new service similar to the defective service. In this search for the service which will replace the defective service, the Discovery Controller module can use different algorithms that are available in Discovery Algorithms module, increasing the possibility of finding a new service. If none of the algorithms can find a new service similar to the defective service, the request made by the user can not be done by the system and Request Manager sends to the user an error message containing information about the execution of the defective service and the generated error. As for the defective service, the (SUO) repository has routines to check if the service returned to its usual operation. Checking this, the defective service is added to the (SR) and reintegrated into the system. C. Extending the Middleware Features Grinv has hot spots that allow the user to extend the
4

16

functionalities according to application needs. For this, the developer must extend some middleware classes and make changes in the configuration file (an example of this configuration file is shown in Section IV). For example, to add a new discovery algorithm (Matchmaker) to the environment, the customer should extend the AbstractMatchmaker class and implement the abstract method discover with the steps of the discovery process. Then he should add the class in the configuration file and indicate its priority (highest priority algorithm is used first). Then, the algorithm is set and Grinv is able to use this new algorithm. A complete guide about the hot spots and how to extend them can be found in the Grinv documentation4. D. Adding Constraints to Grinv As shown previously, Semantic Web Services-based systems require mechanisms to ensure that the services are producing consistent results with the expectations of the system. To resolve this problem, Grinv uses the concept of Constraints in order to evaluate the invocation of services. To make possible the evaluation of invoking a particular service, the software customer must create Constraints that are checked after the invocation of this service. These Constraints are based on descriptions of services and the results obtained after the process of service invocation. For example, for invoking a service that calculates the roots of a certain mathematical function f. A possible constraint for this service would be to check if the values are actually the roots of the function, i.e., taking the set of values Cx, results of the invocation of service, the service will meet the constraint if , we have f(x)=0 (or f(x) 0 within an acceptable threshold). Figure 3 shows the class diagram of the RequestManager module. As said before, this module is responsible for managing the processes in the system through the class RequestManager. The evaluation of the invocations of the services is done by the class ExecutionValidator. This class is responsible for verifying if the results of the invocation are consistent with the set of user defined constraints.

www.grow.ic.ufal.br

1558-7908 2011 IEEE Education Society Students Activities Committee (EdSocSAC)

http://www.ieee.org/edsocsac

> IEEE MULTIDISCIPLINARY ENGINEERING EDUCATION MAGAZINE, VOL. X, NO. X, MONTH YEAR<

17

Receive Request: In this step, the Grinv receives the service description that the application wants to run, these descriptions will be used in the process of service discovery. They also informed the input parameters of the desired service to be able to invoke it. Select Discovery Techniques: As previously mentioned, the Grinv supports multiple mechanisms for service discovery and composition. In this step, the Configuration module is responsible for loading the configuration settings from the configuration file of the application. Select Service or set of Services: In this step, the technique born in the previous step are used to discover the services or set of services that best match the descriptions reported by the application. The execution is interrupted if the discovery mechanisms fail to find a service that offers the functionalities required by the application.
Fig. 3. Request Module.

To customize your application and add new constraints on the system, the software customer must create a new class that implements this constraint by the method validate(Service s, Map parameters, List results), where s is the service invoked, parameters corresponds to the parameters informed by the system and results the result of the invocation. Furthermore, this class should extend the class Constraint. With this class implemented, the customer must enter it in system settings. For this, the configuration file of the Grinv should be changed to Configuration module to identify this change and can apply them to the system. Listing 1 shows an example of the configuration file with the Constraints configuration.
Listing 1. Example of configuration file.

<?xml version="1.0" encoding="UTF-8"?> <Configuration> <!-- other settings --> <ExecutionValidator> <Constraint> <Class>constraints.Constraint_A</Class> </Constraint> <Constraint> <Class>constraints.Constraint_B</Class> </Constraint> </ExecutionValidator> <!-- other settings --> </Configuration>
Fig. 4: Grinvs Activities diagram.

E. Activities diagram Figure 4 shows an activity diagram that illustrates the processes involved in the execution of requests in Grinv. This diagram shows the entire process, ranging from receipt of the request, the discovery service that will meet this request, the invocation of this service, and the validation of this result and sending the response to the application. The steps in this diagram are discussed below:

Invoke selected Services: With the process of discovery completed and the service set, the Invocation module is responsible for invoking the service or composition of services using input parameters specified by the application. If the invocation does not occur successfully, the fault tolerance mechanism will be activated and held the stage for removal of defective services. It will begin the validation of results if the invocation is successful. Validate Results: As shown in subsection III-D, the validation of results is done through evaluation of constraints. For this, the validation engine load restrictions chosen for the application and select the constraints that fit into services that were performed based on the descriptions made by the application. Thus, the mechanism will only check the constraints that were specified for services that were executed, preventing them from being imposed constraints that make no

1558-7908 2011 IEEE Education Society Students Activities Committee (EdSocSAC)

http://www.ieee.org/edsocsac

> IEEE MULTIDISCIPLINARY ENGINEERING EDUCATION MAGAZINE, VOL. X, NO. X, MONTH YEAR< sense. For example, constraints that were created to evaluate the results of a service that calculates the roots of a function should not be applied to a service that provides content recommendation. Remove defective Services: Since there was a problem in the implementation of a service (Service could not be performed or produced incorrect results), the fault tolerance mechanism is responsible for removing the defective services system, as specified in subsection III-B, the service will be removed from the Service Repository and inserted into the SUO Repository, which includes services that do not show proper operation. The removal of these services is that they do not continue disrupting the proper functioning of the system. Prepare new Request: With the faulty service removed from the repository, the fault tolerance mechanism creates a new request so that we can find a service that can replace the service removed. This request is identical to the original request or may contain descriptions of a particular service that is part of the composition where only one service that the composition presents problems. Prepare Response: This last step is responsible for creating the response will be sent to the application, since the results were validated. IV. CASE STUDY In order to validate our proposal, this section presents a scenario that illustrates the operation of the mechanism to verify the correctness of the results of the invocation of services, showing how to specify the constraints that will be part of the validation process. Initially, it will show a scenario where the application requests a service to provide an explanation for a given problem. In this context, the constraints will be presented which can be modeled for these services. A. Scenario description In this scenario, a student is interacting with an Interactive Learning Environment (ILE) that uses semantic services to provide its activity, i.e. the system uses Grinv middleware to find a service that provides the functionality required by user. For example, student is doing a problem solve activity. However, he needs a hint to resolve this problem, i.e. the student needs a service (simple or composite) that come to provide this hint based on problem that he is solving. So, Grinv is responsible to find a service that fits the user requirements (Input: Problem, Output: Explanation). B. Creating Constraints Regarding the constraints for this scenario, we can cite the following story: A student who uses the English language is doing the activity for solving problems. At one point, this student feels a question and demands an explanation for the application. The application then sends a resource containing an explanation of that problem, however this explanation is written in French language, so the student could not understand this explanation and, consequently, did not solve the problem.

18

In this scenario, we can see that the language in which the explanation is written directly affects student learning. That is, does not make sense to send the student an explanation that he cannot interpret. However, somehow, the system used a service that provided an explanation in another language, this means that the service generated an incorrect result for the application. In this context, to ensure the correctness of the results of the invocation of services is necessary to create a check constraint that the language that the action recommended by the service. This verification can be done through tools such as Google Language API 5 and What language is This website6. The Listing 2 presents the implementation of a class that represents the language Constraint.
Listing 2. Code Example of Language Constraint.

public class LanguageConstraint extends Constraint{ // tool that recognizes the language LanguageTool tool; public double validate(Service s, Map descriptions, List Results){ // Verify if the service requires this // constraint validation if(descriptions.contains("language")){ //retrieving the required language(s) String lang = descriptions.get("language"); //checking all results for(Resource resource:Results.getOutputs()){ // checking if the 'resource' is written // in language 'lang' double value= tool.check(resource, lang); // if the 'resource' has less than 70% of // its content in the required language // the result did not accomplish the // constraint if(value < 0.7){ return 0.0 } } } return 1.0; } }

C. Configuration Initially it will be shown the configuration of Grinv. The services that are available in the repository are presented in Table 1. Figure 5 shows an example of a service (Show Resource) described in OWL-S language. These services were described based on an ontology that describes the Educational Resources, the graphic representation of part of this ontology is presented in Figure 6. Some information about these services is
5 6

http://code.google.com/intl/pt-BR/apis/language/ http://whatlanguageisthis.com/

1558-7908 2011 IEEE Education Society Students Activities Committee (EdSocSAC)

http://www.ieee.org/edsocsac

> IEEE MULTIDISCIPLINARY ENGINEERING EDUCATION MAGAZINE, VOL. X, NO. X, MONTH YEAR< following:
Table 1. Services in Repository.

19

Service Give Concept Get Activities Report Give Explanation Show Resource Explain Concept Evaluate Problem

Input Problem Student Problem Student Concept Problem

Output Concept Report Explanation Resource Explanation Evaluation

Fig. 5. Show Resource Service described with OWL-S.

this service was developed by third parties that have implemented this service to be used in an ITS that has students who speak French, so this service recommends explanations in the French language. Show Resource: This service receives as entry a student and based in his course, this service returns to the user a resource that will be presented to the student. Explain Concept: This service aims provide an Explanation to help the student in understanding a certain Concept. Evaluate Problem: This service evaluates the solution of a problem made by a student. Therefore, it receives of system a student and a problem and returns an assessment this solution. Regarding the discovery process, two approaches will be used for discovery and composition. The first approach is a simple Uninformed Search Algorithm and does not support composition of services, compensation has good performance. The second approach was proposed in [6], and used in an E-Learning environment in [2], and uses an algorithm based on graphs to perform discovery and service composition, showing better results than the first approach but with somewhat lower performance compared to previous approach. More details about this approach are shown below: The second algorithm uses a directed graph, where the vertices represent the services and the weight of the edges represent relations between the services, providing direct or represents the indirect matching. The weight of an edge similarity between the output parameters of the service A and the input parameters of the service B, this similarity is calculated through the use of Cosine Similarity Metric (more details below). Cosine similarity treats entities as n-dimensional vectors, determining the cosine of the angle formed by these vectors. So the closer the vectors are to each other the more similar they are (more details about similarity metrics in [15]). Therefore, the graph is constructed so that the relations between the services is the possibility of using the output parameters of one service as input parameters for the next service, so the perform it in sequence a possible composition. Finally, Listings 3 shows the configuration file used in this scenario. It is based in XML and represents the Grinv configuration.
Listing 3. Grinv Configuration.

Fig. 6. Ontology that describes Educational Resources. Give Concept: This service helps the user in the problem solving activity. It relates a certain Problem to the Concept necessary to answer this problem. Get Activities Report: This service returns the report of activities performed by the user on the platform. Give Explanation: This service helps the user in the problem solving activity. It sends an Explanation based in the problem that the user is answering. However, in this scenario,

1558-7908 2011 IEEE Education Society Students Activities Committee (EdSocSAC)

http://www.ieee.org/edsocsac

> IEEE MULTIDISCIPLINARY ENGINEERING EDUCATION MAGAZINE, VOL. X, NO. X, MONTH YEAR<
<?xml version="1.0" encoding="UTF-8"?> <Configuration> <Repository-SR> <Class>repository.GrinvRepository</Class> <Location>./SR</Location> </Repository-SR> <Repository-SUO> <Class>repository.GrinvRepository</Class> <Location>./SUO</Location> </Repository-SUO> <Discovery> <Algorithm> <priority>0</priority> <ClassName>grinv.UninformedSearch</ClassName> <Parameter>inputs</Parameter> <Parameter>outputs</Parameter> </Algorithm> <Algorithm> <priority>1</priority> <ClassName>grinv.GBMatchmaker</ClassName> <Parameter>inputs</Parameter> <Parameter>outputs</Parameter> </Algorithm> </Discovery> <Invocation> <ClassName>invocation.OwlsEngine</ClassName> </Invocation> <ExecutionValidator> <Constraint> <Class>constraints.LanguageConstraint</Class> </Constraint> </ExecutionValidator> </Configuration> Discovery Request: > Descriptions: >> Inputs: {Problem} >> Outputs: {Explanation} -----Starting Uninformed Search: ->Service: Give Concept --> Inputs: {Problem} - 100% --> Outputs: {Concept} - 50% ->Service: Get Activities --> Inputs: {Student} - 0% --> Outputs: {Report} - 0% ->Service: Give Explanation --> Inputs: {Problem} - 100% --> Outputs: {Explanation} - 100% ->Service: Show Resource --> Inputs: {Student} - 0% --> Outputs: {Resource} - 71% ->Service: Explain Concept --> Inputs: {Concept} - 50% --> Outputs: {Explanation} - 100% ->Service: Evaluate Problem --> Inputs: {Problem} - 100% --> Outputs: {Evaluation} - 50% Calculating Similarity: > Service Give Concept: 75% > Service Get Activities: 0% > Service Give Explanation: 100% > Service Show Resource: 35,5% > Service Explain Concept: 75% > Service Evaluate Problem: 75% Matching Result: 100% (Give Explanation)

20

D. Attending Request With Grinv properly configured, the user request should be specified. This request is sent to the Request Manager to start its execution. In this scenario, the Input (Problem) and Output (Explanation) parameters must be specified, Table 2 presents this request. Moreover, the application must specify the restrictions that are necessary for this request, this case will be the language parameter. Furthermore, the problem that the user is resolving is added to this request to be used in service invocation. Other parameters can be added to these requests, as pre-conditions and Effects, but the algorithms presented in the previous subsection uses only input and output parameters.
Table 2: User Request Descriptions Input Output Language Parameters Problem Problem_120a Problem Explanation English

After the request specification, the discovery process is started using the Uninformed Search Algorithm cited in last subsection, which has the lowest priority in configuration file. Its execution is shown e Listing 4.
Listing 4. Uninformed Search Algorithm execution log.

This algorithm found the service Give Explanation as result, and it is sent to the Invocation module to be invocated. In fact, the service found fits with the descriptions come from the user, however, as stated earlier, this service only provides Explanations written in French language. So, the Invocation module invokes this service and receives as result an Explanation from the required Problem (Problem_120a). Although the service is designed for French language and the Problem being described in English, the service can interpret this problem due to it semantic description present in the ontology and identify the concepts that address the problem, and thus recommend an explanation. Since the stage of the service invocation was successful, the step to Validate the Results is initiated, as shown in the activity diagram (Figure 4). In this step, the ExecutionValidator verify if the Results meet the Constraints. In this scenario, the language restriction is not satisfied because the application indicated the need for explanation to be written in English and the service returned an explanation in French. As the restriction was not met, the execution was held invalid. Because the service did not produce a correct result, this service was removed from the Service Repository (SR) and inserted it into the repository of services under observation (SUO). This done, a new discovery process is started without the defective service. In this new discovery process, the use of the Uninformed Search algorithm returns a service with 75% similarity (Give Concept). As it is not a perfect result, the algorithm with

1558-7908 2011 IEEE Education Society Students Activities Committee (EdSocSAC)

http://www.ieee.org/edsocsac

> IEEE MULTIDISCIPLINARY ENGINEERING EDUCATION MAGAZINE, VOL. X, NO. X, MONTH YEAR< priority 1 (Graphs Matchmaker) is used in order to find a better result than the previous approach. As we can see in log file, Listing 5, the algorithm execution got the Give Concept service as direct matching result, this is the best single service that fits the users request, in fact its output parameter is equal to asked by user, however its input parameter is different. As indirect matching, the algorithm indicated the Give Concept and Explain Concept services composition in sequence, in fact the first service input corresponds to the required input by user (Problem) and the second service output is equal to defined output by user (Explanation). Moreover, the first service output is equal to second input making a good option to compose. Comparing the two solutions, the indirect matching is chosen as discovery module answer with 100% similarity, more details to see operation of the algorithm you can find in [6, 2], figure 7 illustrates this composition.

21

requests (to be written in English), this explanation will be sent to the student. Otherwise the process will repeat itself and the system will search for a new service that can provide the explanation. In this case, if no new service can be found, Grinv will send a message that no results could be obtained. Finally, this scenario sought to illustrate the operation of the proposed Middleware, presenting automatic discovery, composition and invocation, integrated and transparent to the user. Furthermore, the mechanisms used to provide reliable use of semantic services were shown in a scene that its use was necessary. E. Scenario Limitations In a more sophisticated solution, when the constraint is broken, the system could check for a service that repairs the result. For example, if the service returns an explanation in some language other than requested, Grinv could seek and use a translation service to translate the explanation for the correct language. This scenario showed only a restriction on the recommendation of explanations. Other constraints can be implemented, for example: i) verify if the explanation is actually related to the subject, ii) examine the size and complexity of the explanation (very long explanations should be avoided), iii) whether the student has viewed this explanation previously. V. RELATED WORK This section presents some proposals that, as this work, also aimed at providing reliable use of services to applications. WS-Reliability [13] is a SOAP-based specification that fulfills reliable messaging requirements critical to some applications of Web Services. Reliable Messaging (RM) is the execution of a transport-agnostic, SOAP-based protocol providing quality of service in the reliable delivery of messages. Despite being efficient in what it claims to do, this approach does not address issues of correctness in the invocation of services and does not take into account the use of semantic services. The authors of [28] explore the criteria of reliability of Web services-oriented systems, and discuss how to design and generate test cases to conduct tests over remote Web services. However, this work deals only with Web services alone, not dealing reliability in service compositions. In addition, this paper considers that the test cases for each service are specified prior to its use, not what happens in services developed by third parties, which impedes the automatic reuse. As shown in the previous section, the Grinv Constraints are made to validate features of the application and not for each service, for example: the Language Constraint in explanation recommendation was used in the execution of the faulty service and in the composition of services (Figure 7). Moreover, the proposed work on [10] displays a set of extensible recovery policies to declaratively specify how to handle and recover from typical faults in Web services composition. As the Grinv, this work provides both fault tolerance and correctness of the results. However, this paper

Fig. 7. Services Composition Listing 5. Graphs Algorithm execution log.

Discovery Request: > Descriptions: >> Inputs: {Problem} >> Outputs: {Explanation} -----Direct Matching Search: ->Service: Give Concept - 75% ->Service: Get Activities - 0% ->Service: Show Resource - 35,5% ->Service: Explain Concept - 75% ->Service: Evaluate Problem - 75% -----Indirect Matching Search: >Path found, Services: >> Give Concept -> Explain Concept - 100% -----Direct Matching Result: 75% Indirect Matching Result: 100% Final Result: Indirect Matching Composition: {Give Concept, Explain Concept}

With the service found, this is passed to Invocation module that use the OWL-S API to mapping the parameters sent by user with found service parameters. After, the service is invoked by OWL-S API that provides mechanisms to execute composite services. As result of the invocation of found services, we obtain the Explanation required by student. As with the first attempt, the results of this invocation will also be evaluated. In the case of the explanation meet all

1558-7908 2011 IEEE Education Society Students Activities Committee (EdSocSAC)

http://www.ieee.org/edsocsac

> IEEE MULTIDISCIPLINARY ENGINEERING EDUCATION MAGAZINE, VOL. X, NO. X, MONTH YEAR< works only with static composition of services, i.e. composition structures that are pre-established, so the user of this tool is able to specify policies for assessment and fault recovery. So this tool is not compatible with dynamic compositions of services, as shown in the previous section. Also in relation to [10], the selection of services is based on the QoS metrics gathered from prior interactions or from trusted peers this way, so that the service is selected it needs to be tested earlier by other users, which is not required in Grinv. In addition, this tool will not work on semantics for service description, which limits the process of discovery and automatic composition. Regarding the studies that use semantic annotations to services, in SAREK Framework [7], a fault tolerance mechanism is provided, it uses a planning algorithm for service composition based in Pre-conditions and Effects. This mechanism builds Replication Schemes to provide Reliability, i.e. it finds a set of possible solutions, if there is any failure in the execution of the first solution, and an alternative solution is used. However, this approach only provides service composition based on Pre-Conditions and Effects, so it is not possible to use different approaches, which utilize different parameters, to find alternative solutions to the faulty service, which limits the ability to find this alternative solution. In addition, this work does not guarantee correctness of the results. The work [20] have presented CFI (Control Flow Intervention), a novel approach to flexible and automatic forward recovery that dynamically substitutes failed services by semantically equivalent services, and its implementation in OSIRIS NEXT. Like the previous work, this work deals only with fault tolerance in the invocation of services, not providing mechanisms to verify the correctness of the results of invocations. VI. CONCLUSION AND FUTURE WORKS This article proposed a middleware for automatic discovery, composition and invocation of semantic web services that provides reliable use of services and a case study was presented in order to validate this proposal. As a concrete result of this work, we obtained a middleware capable of providing features that are required in systems based on semantic services, such as: i) Automatic management of discovery and invocation processes, ii) Support for multiple discovery approaches, iii) Fault tolerance mechanism and iv) Verification of correctness in the invocation of services through constraints. As immediate future work we will focus on providing a better analysis using the same case study, and some others, in order to compare the use of the proposed approach with different discovery approaches to indicate the best combination of approaches to achieve the best results, considering the system performance. In addition to implementing new restrictions on the scene and verify the impact of these restrictions on application performance.
[16]

22

REFERENCES
[1] Heitor Barros, Ig Ibert Bittencourt, Evandro Costa, Marlos Silva, and Douglas Vras. A fault tolerance approach for semantic web services based systems: A case study in e-learning. In Anais do XXI Simpsio Brasileiro de Informtica na Educao (SBIE 2010), III Brazilian Workshop on Semantic Web and Education, November 2010. Heitor Barros, Ivo Calado, Marlos Silva, Ig Ibert Bittencourt, and Evandro Costa. Using semantic web services to automatically attend to educational requests. In Anais do Simpsio Brasileiro de Informtica na Educao. SBIE, 2009. Tim Berners-Lee, James Hendler, and Ora Lassila. The semantic web. Scientific American, 284(5):3443, 2001. Ig Ibert Bittencourt, Evandro Costa, Marlos Silva, and Elvys Soares. A computational model for developing semantic web-based educational systems. Knowledge-Based Systems, 22, 2009. Jeen Broekstra, Arjohn Kampman, and Frank Van Harmelen. Sesame: An architecture for storing and querying rdf data and schema information. In Semantics for the WWW. MIT Press, 2001. Ivo Calado, Heitor Barros, and Ig Ibert Bittencourt. An approach for semantic web services automatic discovery and composition with similarity metrics. . In Symposium On Applied Computing - ACM, pages 694695, 2009. Daniela Barreiro Claro and Raimundo Joe de Arajo Macdo. Dependable web service compositions using a semantic replication scheme. In 26 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos, 2008. Michael C. Daconta, Leo J. Obrst, and Kevin T. Smith. The Semantic Web : A Guide to the Future of XML, Web Services, and Knowledge Management. Wiley, Indianapolis, May 2003. Vladan Devedzic. Education and the semantic web. International Journal of Artificial Intelligence in Education, 14:3965, 2004. Abdelkarim Erradi, Piyush Maheshwari, and Vladimir Tosic. Recovery policies for enhancing web services reliability. In Proceedings of the IEEE International Conference on Web Services, pages 189196, Washington, DC, USA, 2006. IEEE Computer Society. Joel Farrell and Holger Lausen. Semantic annotations for wsdl and xml schema. http://www.w3.org/TR/sawsdl/, August 2007. T. R. Gruber. A translation approach to portable ontology specifications. Knowledge Acquisition, 5(2):199220, 1993. Kazunori Iwasa, Jacques Durand, Tom Rutt, Mark Peel, Sunil Kunisetty, and Doug Bunting. Oasis web services reliable messaging (wsrm). http://docs.oasis-open.org/wsrm/ws-reliability/v1.1, November 2004. Jena. Jena api. http://jena.sourceforge.net/. Last access in April 2011. Matthias Klusch, Benedikt Fries, and Katia Sycara. Automated semantic web service discovery with owls-mx. In AAMAS 06: Proceedings of the fifth international joint conference on Autonomous agents and multiagent systems, pages 915922, New York, NY, USA, 2006. ACM. Tarsis Marinho, Diego Dermeval, Rafael Ferreira, Lucas Braz, Ig Ibert Bittencourt, Evandro Costa, and Henrique Pacca. An ontology-based framework to provide educational data mining. In Symposium On Applied Computing - ACM, 2010, 2010. David Martin, Mark Burstein, Jerry Hobbs, Ora Lassila, Drew McDermott, Sheila McIlraith, Srini Narayanan, Massimo Paolucci, Bijan Parsia, Terry Payne, Evren Sirin, Naveen Srinivasan, and Katia Sycara. Owl-s: Semantic markup for web services. http://www.w3.org/ Submission/2004/SUBM-OWL-S-20041122/, November 2004. W3C Member Submission. David Martin, Massimo Paolucci, and Matthias Wagner. Bringing semantic annotations to web services: Owl-s from the sawsdl perspective. In Proceedings of the 6th international The semantic web and 2nd Asian conference on Asian semantic web conference, pages 340352, 2007. Sheila A. McIlraith, Tran Cao Son, and Honglei Zeng. Semantic web services. IEEE Intelligent Systems, 16(2):4653, 2001. Thorsten Moller and Heiko Schuldt. Osiris next: Flexible semantic failure handling for composite web service execution. International Conference on Semantic Computing, 0:212217, 2010. John D. Musa, Anthony Iannino, and Kazuhira Okumoto. Software reliability: measurement, prediction, application. McGraw-Hill, Inc., New York, NY, USA, 1987. Massimo Paolucci, Takahiro Kawamura, Terry R. Payne, and Katia Sycara. Semantic matching of web services capabilities. pages 333+. 2002.

[2]

[3] [4] [5] [6]

[7]

[8] [9] [10]

[11] [12] [13] [14] [15]

[17]

[18]

[19] [20] [21] [22]

1558-7908 2011 IEEE Education Society Students Activities Committee (EdSocSAC)

http://www.ieee.org/edsocsac

> IEEE MULTIDISCIPLINARY ENGINEERING EDUCATION MAGAZINE, VOL. X, NO. X, MONTH YEAR<
[23] Massimo Paolucci, Naveen Srinivasan, and Katia Sycara. Expressing wsmo mediators in owl-s. In Proceedings of the workshop on Semantic Web Services: Preparing to Meet the World of Business Applications held at the 3rd International Semantic Web Conference (ISWC 2004), 2004. [24] Dumitru Roman, Holger Lausen, and Uwe Keller. Web service modeling ontology (wsmo). http://www.wsmo.org/TR/d2/v1.3/. Last access in April 2011. [25] Maria Sibaldo, Anderson Neves, Flavio Medeiros, Ig Ibert Bittencourt, and Evandro Costa. Fraw - ambiente interativo de aprendizagem para o domnio de frao via web. In Simpsio Brasileiro de Informtica na Educao, 2008, XIX Simpsio Brasileiro de Informtica na Educao, 2008. [26] Alan Silva, Evandro Costa, Ig Ibert Bittencourt, Patrick Brito, Olavo Holanda, and Diego Dermeval. Semantic web-based software product line for building intelligent tutoring systems. In Second International Conference of Software, Services and Semantic Technologies, pages 127136, September 2010. [27] Naveen Srinivasan, Massimo Paolucci, and Katia Sycara. Semantic web service discovery in the owl-s ide. In HICSS 06: Proceedings of the 39th Annual Hawaii International Conference on System Sciences, page 109.2, Washington, DC, USA, 2006. IEEE Computer Society. [28] Jia Zhang and Liang-Jie Zhang. Criteria analysis and validation of the reliability of web services-oriented systems. In Proceedings of the IEEE International Conference on Web Services, ICWS 05, pages 621628, Washington, DC, USA, 2005. IEEE Computer Society. Heitor Barros is PhD student in Computer Science at Federal University of Campina Grande (UFCG), and member of GrOW (Group of Optimization of Web). In his master thesis, he worked in the design of systems based on Semantic Web Services, focusing on Middleware Grinv, shown in this work. His mains interests are Semantic Web Services, Software Engineering and Knowledge Engineering. Marlos Tacio Silva is PhD student in Computer Science at Federal University of Campina Grande, and member of GrOW (Group of Optimization of Web). His research focus is Multi-agent Systems, Software Engineering, and Semantic Web. Ig Ibert Bittencourt is a Professor and Vice-Director at the Computing Institute at the Federal University of Alagoas - UFAL, Brazil, Head of the GrOW (Group of Optimization of the Web) and member of the IEEE, ACM, and Brazilian Computer Society. He teaches issues, such as, Software Engineering, Knowledge Representation and Semantic Web, Artificial Intelligence in Education, and so on. His main research interests are Social Semantic Web and Education, Intelligent Tutoring Systems and Software Engineering in Education. Evandro Costa received his PhD in Electrical Engineering from the Federal University of Paraiba (UFPB), Brazil. He is currently an Associate Professor in the Computer Science Institute at the Federal University of Alagoas (UFAL), Brazil and Director of the same institute. He is also a collaborator professor in the graduate program at Federal University of Campina Grande (UFCG), Paraiba, Brazil. His research interests include Multi-agent Systems, Knowledge Representation and Semantic Web, and Artificial Intelligence in Education, where he has published over 100 peer-reviewed papers. He teaches several issues, such as, Artificial Intelligence, Multiagent Systems, Data Mining, and so on. Douglas Vras is graduated from the Federal University of Alagoas (UFAL) in Computer Science, he is external member of the GrOW and recently has developed research and development on Digital TV Interactive, specially in t-learning, theme of its conclusion work. Already is a Masters Student Federal University of Pernambuco (UFPE), in line with media research and interaction (TVDi) from course of Computer Science, where also works in partnership with Samsung Digital TV. Aydano Pamponet Machado is Associate Professor of the Computing Institute at Federal University of Alagoas. He received his Ph.D. in Computer Science from Universite Pierre et Marie Curie with the work performed at the Laboratoire dInformatique de Paris 6-LIP6 (2009), his research focus is Artificial Intelligence, Machine Learning, Knowledge Transfer, Multi-Agent Systems, and Games.

23

1558-7908 2011 IEEE Education Society Students Activities Committee (EdSocSAC)

http://www.ieee.org/edsocsac