Gérald Kembellec
email: gerald.kembellec@univ-paris8.fr

Imad Saleh
email: imad.saleh@univ-paris8.fr

Catherine Sauvaget

OntologyNavigator: WEB 2.0 scalable ontology based CLIR portal to IT scientific corpus for researchers

Keywords: Digital Library, Domain Ontology, KBS, Metadata, Cross Language Information Retrieval

This work presents the architecture used in the ongoing OntologyNavigator project. It is a research tool to help advanced learners to find adapted IT papers to create scientific bibliographies. The purpose is the use of an IT representation as educational research software for researchers. We use an ontology based on the ACM's Computing Classification System in order to find scientific articles directly related to the new researcher's domain without any formal request. An ontology translation in French is automatically proposed and can be based on Web 2.0 enhanced by a community of users. A visualization and navigation model is proposed to make it more accessible and examples are given to show the interface of the tool. This model offers the possibility of cross language query. Users deeply interact with the translation by providing alternative translation of the node label. Customers also enrich the ontology node labels with implicit descriptors.

Introduction

The purpose of this article is to develop a method for approaching the IT field for the use of student researchers, typically in their second year of master or beginning their PhD thesis. In the French university context, it is common to see students in 2 nd and 3 rd cycles experiencing real difficulties in collecting the documentation on their field of study or research. The main idea is to support these learners by a tool to supplement their perception of the knowledge domain "stored" in ontology. It is to consider, even hoping, that mastering tool lets it become obsolete for the advanced learner (became autonomous). The context is bibliographical research in the IT area for "Insiders" but not experts, who are increasingly lost in a predominantly English corpus. Once the subject and the target audience have been defined, it is necessary to determine the habits, practices, behaviour and attitudes of young researchers in their research of information. An important point of transition between the first and the second year of master is the increased focus on access to quality and credit worthy information. The purpose of information retrieval systems, such as conventional search engines or documentaries on the Internet is to search by keywords or natural language. During the first part of their studies, students tend to seek information on the total mass of the Internet without particular method, discernment or qualitative discrimination. When transitioning to a higher level of studies the method of research evolves. This is mainly due to the fact that access to a huge amount of information causes two major problems. The first major obstacle to efficient research is the difficulty to control the quality of information. The ability to assess the creditworthiness of the information will depend on the level of knowledge of the student researcher. The second problem identified in a classic request on a search engine is the amount of information returned by each search. While not purporting to replace the role of a director of research, OntologyNavigator seeks to lead the researcher in his approach of the field of IT research. In this article, the concept of domain ontology is defined. The way that domain ontologies can help to search scientific information is shown. This paper describes step by step the design of the tool, how OntologyNavigator includes translation tools, and discusses the methods of representation. The article continues with examples of the use of the tool.

DOMAIN ONTOLOGIES AND INFORMATION RETRIVAL

In the context, domain ontology means a conceptual hierarchy designed by an expert within a structure, where elements are linked by their proximity in terms of syntactic or semantic relations. The traditional approach to the use of ontology's area is to prioritize subsets of the area for management purposes. The ontology is then used most often to prioritize and rank the components of the domain and to describe their relationship. A frequent application is indexing a specialized corpus. A more innovative use of ontology is to reverse the process. It is possible to use domain ontology as a means of research in a text, a corpus, a digital library, or perhaps even the Internet. Thanks to a combination of different semantic technologies, Stephan Bloehdorn has proposed an interesting method of searching in digital libraries [START_REF] Bloehdorn | Ontology-Based Question Answering for Digital Libraries[END_REF]. He defines an approach by analysis of structured questions in natural language with a formal grammar. It is then the role of the system to understand the question, identify keywords, titles and authors. Basic examples of questions would be: who wrote this book? What book deals with this specific topic? Which article is part of this conference and corresponds to these keywords? This approach translates natural language into meta-data, and rephrases the question in SPARQL language (W3C, 2008, SPARQL). The answer is contained in a Resource Description Framework (RDF) file (W3C, 2004. RDF/XML Syntax Specification), this enables updates in real time, the use of a variety of formats as well as sourcing from many different locations. This method enables the user to avoid using any database in the common sense of the term. IT is a very broad area, which includes a multitude of sub-disciplines, and is a powerful tool used in many scientific fields. It is therefore necessary to understand the nature and context of the user's research and his angle of research as much as possible. For example: the couple of words "data storage" will not have the same meaning for an assembly technician, a systems and networks engineer or a librarian. The technician's perception of "data storage" is the hard disk or USB drive. The systems and networks engineer will have a broader vision of "data storage", not only the concept of devices, but also methods of storage such as NAS, data redundancy (RAID level), information sharing techniques (NetBIOS, NFS, SMB ...) and permission(s) (reading, writing and execution). Finally, the librarian will understand the term "data storage" primarily as an integrated library system, which administers the loans and reservations and manages the order tracking and state of the inventory. These three professionals, having advanced knowledge in their own particular field have different uses of the term "data storage". This is however not a case of polysemy (multiple meanings) but is rather a difference in the angle of perception of these three professionals. The issue of user relevance arises in the particular case of the IRS. The idea of user relevance has greatly influenced the tool, which focuses on the angle of perception of the user and not only on the data.

TAXONOMY BASED IT ONTOLOGY

Initially, the approach will be onomasiological or top-down, i.e. the corpus will be classified in a structure, which is a finished standardized set. In a second step, the structure is enriched, where this becomes necessary, through the ad junction of additional corpus. The domain ontology consists of a tree of topics ranging from a generic root (in this case computer science) to the leaves of knowledge. The arcs are links between nodes that materialize top-down or bottom-up relations or ties of similarity. The ontology contains no articles, but nodes with labels containing keywords issued by superior nodes. These keywords can generate a request to be submitted to the main scientific on-line libraries.

Proposal of a model

This project must consist in a tool of flexible use, which integrates the field of a particular user to be within the user's grasp. Therefore it should help the user mastering his field of expertise. This tree can simply be seen as the external skeleton or exoskeleton in the IT field. First keywords of each node or leaf are the words constituting its label. These keywords are called "native" keywords, as opposed to other keywords added afterwards, which will be referred to as "added" keywords. The starting point was the description of research with a minimal ontological exoskeleton. To put into place such a minimal ontological exoskeleton it was necessary to find taxonomic approaches representing as carefully and as fully as possible the broad field of IT. Then, to conceptualize this field, it was necessary to segment the titles of each branch. This specification phase passes through a stage of construction of keyword "clusters" related to each branch, thanks to lemmas (canonical form of a lexeme) extracted from titles. From a technical point of view, for greater ease of handling, it would be appropriate to integrate the ontology and its keywords in a database, which will result in a comprehensive ontology in Extensible Mark-up Language (W3C, 2008, Canonical XML) where developments are updated in real time. For the test phase, the corpus of research will be composed of the titles of articles published since 1945 and referenced in the Database systems and Logic Programming [START_REF] Ley | Maintaining an Online Bibliographical Database: The Problem of Data Quality, Actes des Sixièmes Journées Extraction et Gestion des Connaissances[END_REF] by Michael Ley from the German University of Trier. It is the source of an XML document of about one million admissions in BibTeX 1 format (format of bibliographic description of L A TEX 2 ). It should be noted that the papers are written in various languages (3.6). It also proposes meta-queries to on-line digital libraries such as Computer Science Bibliography 3 or ACM.

Choosing the best reference for IT classification

From a technical point of view, to increase handling comfort, the ontology and its keywords were integrated in a database. That results in a comprehensive XML ontology where developments are updated in real time. The model tried as a first step to find an agency specialized in computer sciences. Then it proposed a system of representation in the field that the tool wishes to model. For the sake of simplicity lit take the online encyclopaedia Wikipedia as a first step. Indeed Wikipedia from an IT perspective is classified according to an internal hierarchy, has an abundant corpus and is immediately available in XML and RDF. Unfortunately, as of today the scientific legitimacy of Wikipedia is not demonstrable. Let us then turn to Computing Classification System (Association for Computing Machinery, 1998), whose legitimacy is evident. Moreover, conveniently the Association for Computing Machinery (ACM) has its own digital library of scientific articles indexed according to the CCS model. However, the CCS is not usable as it stands. The CCS is more in the state of taxonomy than ontology. According to Grüber, an important aspect of ontology (in addition to clarity, consistency, minimal commitment, and deformation) is scalability [START_REF] Grüber | Toward principles for the design of ontologies used for knowledge sharing[END_REF].

A WEB 2.0 way to enrich the ontology with keywords and implicit descriptors

Consider the corpus as a mass of papers' titles in terms of information and statistical science. According to [START_REF] Coadic | Mathématique et statistique en science de l'information et en science de la communication: infométrie mathématique et infométrie statistique des revues scientifiques[END_REF], when a serie of scientific articles is considered, a specific attention to meaningful words and their co-occurrence must be given in order to generate significant semantic proximities. So when a couple of associated words emerge simultaneously in several node labels, it is likely that the subjects in question are associated. Of course, in this case this approach is only used on titles. Nevertheless, ACM labels appear sufficiently precise to be representative of all documents, both from the general and particular point of view. Thus, the words that best represent the label will be added as keywords to get to the document and to the branch of the ontology. Other words, less representative, will be added as "semantically near". Subsequently, during the indexing phase of a digital library, if an article appears to be indexed in two places, it is proposed to establish proximity link between the two branches. Dislike Stephanov's work for building IT domain ontology with ACM CCS [START_REF] Stefanov | Computing Ontology Creation[END_REF]) who deleted all "miscellaneous" and "general" nodes, this approach allows greater compatibility with the tools offered by ACM. Indeed, the implicit subject descriptors sometimes refer to these nodes. In addition, the portal uses the ACM full classification described for his papers. A "general" node is used (at any level) if the article covers most of the concepts in an area. If a paper cannot be classified under any other node, then the "Miscellaneous" node of the given area is used (Association for Computing Machinery 1998). The lexical scope of the original taxonomy has been expanded by subject descriptors, which only specify certain nodes. This document is available in text format on the ACM website. Implicit Subject Descriptors (also called "Proper Noun Subject Descriptors") are proprietary names of products, systems, languages, and prominent people in the computing field, along with the category code under which they are classified. For example, "C++" is under "D.3.2 Language Classifications" (Association for Computing Machinery 1998). This list of descriptors was translated into XML for the purpose of the tool. These descriptors are integrated in the ontology as "implicitDescriptorOf" type leaf specifying certain nodes (cf. Figure 1). Sometimes there are co-occurrences of descriptors, which automatically create semantics arcs between nearby nodes described. Besides the fact that these specifications consistently improve research, they also create new semantic arcs integrated to the ontology. This theoretical approach, although functional, is inadequate to enrich the ontology while remaining close to the user. Indeed, this tool is designed to adapt to the user by exchanging knowledge. But in the case previously described, this specification is achieved by the system for the final user. The second use of these descriptors is to provide the users with the opportunity to submit their own interpretation. These synonyms are then classified as keywords and stored for future researches. These keywords will not be able to be seen during browsing, but they will be included for the future researches. The process will also be applied when added co-occurrences expressions. Creations of "IsRelatedTo" arcs between keywords and descriptors will be created. It is important to notice that implicit descriptors are different of generic keywords of the CCS that can be found on ACM portal. On the one hand, generic keywords are explicit descriptors of CCS nodes. They precisely describe the main concept of a node. On the other hand, implicit descriptors specify very deeply a concept with a name of a major actor or the main software in a field of knowledge.

Corpus Interface

In the long run, a method of compilation (or clustering) from different on-line databases of articles like CSBIB, DBLP, ACM and others will be done. The clustering will go through a phase of pre-treatment. Each library has its own scientific query interface; we will try to find the RDF document that describes each database. It should be noted that if each site provided data Description services such as RDFa (W3C, 2008, RDFa), this work would be greatly simplified. A database, the "The scientific library of the field of Information Technologies" will be created, describing each article by its title, the context and year of publication, and authors of this article. The database, automatically updated each week on an incremental basis, would ideally continuously generate a single RDF document describing the pseudo corpus. The term "continuously" means that in theory for every query, a snapshot of the corpus will be established by RDF through interrogation of the database and will be processed to reflect the weekly updates. This approach, while desirable is technically unrealistic. It is possible and even desirable in view of the vast amount of data (in a resource-saving system) to maintain a snapshot cache. This snapshot of the database would become a RDF file and therefore the representation of the pseudo corpus. The corpus of scientific articles would not be hosted locally on the host machine of the ontology for legal reasons, but also for reasons of storage capacity. This is why the term pseudo-corpus is used rather than corpus. Indeed labels, and possibly abstracts indexed in digital libraries do not strictly constitute a corpus.

The perspectives for IT ontology

The index of the pseudo corpus is composed by titles of articles. Most of the times the titles of scientific articles are long enough to provide a number of keywords indicating the leading ideas. During the phase of indexing the corpus, if an article's title appears as "unclassifiable", we propose to classify it momentarily in a branch of the ontology having the closest semantic proximity within a "miscellaneous" or "general" subsection. Then once the ontology has reached a sufficient size, the "orphan" article will be classified permanently by creating a new branch on the ontology where semantic proximity is the greatest (using added keywords). The process described above is one of the vectors of the evolution of an ontology, which is not static but evolves with the corpus and the work of the users and experts. The extensions that may be added to the ontology must be anticipated during its creation. It should be possible to add new concepts without having to modify the foundation of ontology. For example a "branch" which turns up an important number of common keywords would constitute a suitable root for the ontology. It may be possible to automate this task e.g. if a text generative algorithm would be able to produce a full text leaf of the ontology. This algorithm should be able to redistribute keywords extracted from one or more articles classified in a temporary general branch of the ontology.

WEB 2.0 Cross Language module implementation

The lingua franca of scientific research today is English. Each researcher should in theory feel comfortable with this international scientific language. Why is it important to make an effort to translate the titles of the IT ontology branches in vernacular language (French in the context) while the corpus is mainly English, the predominant scientific language? However, even if the user feels comfortable reading technical and scientific texts (as the case may be with a good dictionary in hand), he may feel more at ease in French to conduct his research.

In order to create a more customizable tool, a Web 2.0 approach was used, i.e. hybrid translation starting with automatic translation, which is thereafter corrected and completed through communal manual translation. The simplest and most economical solution to automate an Anglo-French translation would be to use an on-line translation tool. The more used tools are Babel fish, Yahoo and Google Translate. An API was written to generate a French version of the ontology based on one of these tools. It can be pointed out that this kind of on-line applications would benefit from having its own official API. Of course nothing can replace manual translation, which is why a notion of folksonomy was incorporated with a RDF Site Summary (World Wide Web Consortium, 2002, RSS 2.0 specification) in the tool. This enables the last user to report a translation error, or imprecision, to the management committee. This group will consist of researchers from laboratories of the research and training unit, which will validate the proposal or reject it. According to Thomas Vander Wal, the value of external marking of the folksonomy comes from the users using their own words, which add an explicit dimension, which will be an inference of the object [START_REF] Vander Wal | Understanding folksonomy: Tagging That Works[END_REF]. The system of translation of the ontology's nodes automated in a first step continued and developed by English language users and validated by experts, can be carried out without recourse to a professional translator, or occupying an expert on a full-time basis. This procedure implies considerable time saving for researchers and the financial economy should not be underestimated. The technical aspects of this process should be simplified, as much as possible, for the user so as not to discourage him from making a proposal e.g. making a proposal should also not take him more than a few seconds. Once the proposal has been submitted (cf. Figure 2), an RSS feed is generated and will remain active until at least two committee members have verified the proposal. It is contemplated to correct the French part of the ontology over a period of time which is yet to be determined. Another advantage of this process is that it takes into account terminology modification, which is inherent to the field of IT. Due to the interaction between the system and the user, the user enriches his knowledge in the field in question while participating in its evolution.

Choosing a model of representation

To make the corpus more accessible, to facilitate the representation, the domain ontology was represented as a navigable map. The tree should enable the user to focus on the branch containing a formalization of the concept sought. There are many ways to view ontologies, but all are not specific to navigation, at least not as concerns intuitive navigation. In this context, the tool of representation must abide by a number of rules set out by Christophe Tricot and Christophe Roche [START_REF] Tricot | Visualisation of ontology: a focus and context approach[END_REF]. To be effective a visualization system should observe the following rules as a minimal requirement:

• Provision of an overview of the ontology. This will allow the user to identify all the concepts in the field. • Use of a "focus + context" to allow the user to concentrate on certain aspects while having access to others; • Use of plane geometry, to avoid disturbing natural perception. This particular point, has however not been followed in the present case, because giving the mass of data to display and the wish to comply with the other principles, it is complex, if not impossible, to combine a tree display and Euclidean geometry. According to feedback C. Tricot obtained from an experiment, two types of users emerge: "newcomers" and "experts". Newcomers understand the field and its concepts without perceiving details of the organization and interactions. Experts have a perfect mastery of the entire field both in terms of the content of the concepts and the links that bind them together. For the target audience, users have a profile of a master student or a PhD beginner who searches scientific information on a subject in a specialized field. A compromise on the representation of the field was found. It offers a direct access to context on the element in focus. In the article by C. Tricot, it appears that the model representation by radial tree is the most suitable for experts and the model representation by eye tree is the most suitable for newcomers. The eye tree visualization allows a global view of the field and the possibility of a wide-angle focused (fish eye polar) on a point of detail around which the field is articulated. The main shortcoming of this alternative, in the context, is to be limited to a plane. This prevents putting elements into perspective which is possible with the use of cone trees. The radial tree is quite similar to the eye tree combining global vision of the field and the polar fish eye. But the background and focus is more significant within the graph. It appears however that the very advantages of the radial tree (focus + context) also cause a loss of contact with the primary objective, which is to keep the global view. In addition, a radial tree describing the ACM would be quite unreadable because of the huge size of the ontology. In view of the size issue, a visualization of information clusters seems to emerge through the combination of ontology and a technology called Topic Map, thanks to the open source applet Hypergraph. While not specifically conceived to effectively represent ontology, the Topic Map is a hyperbolic tree type representation, which consists of mapping the ontology and unlimited navigation. It has been adapted to enable angles of perception to stand out as well as their focus and contexts. This method will thus be a hybrid approach between the eye tree and the hyperbolic tree.

Meta request concept

Through the Topic Map described, OntologyNavigator provides the advanced learner access to scientific documents relating to his field of research. We intend to use external resources with OntologyNavigator, such as on-line Knowledge Base System (KBS). For this purpose we define user's context and profile to enable personal customized access to knowledge, through this application, in a transparent manner. This is a Reverse-Engineering approach of interrogation of the external KBS. A meta-query is a query sent to a remote KBS, without knowing the system of internal questioning. This is done by simulating a manual use of the remote application through combination of lemmas of keywords extracted from the context of navigation.

Modelling the system

While a natural language search on all words in the order established will have little chance of success, a search by key words will have every chance to return hundreds of thousands of results. The first step in generating request is the filtering of "noise" on the label when positioning the user's browser in the ontology thanks to the stop-lists (one in each language), which will eliminate empty words, like pronouns and nouns, which are too common for significant meaning. A similar preliminary stage is conducted when using a search engine in a natural language search. The second step is the lemmatization4 of words, followed by a calculation of statistical proximity of all of the words, which have emerged, from the keyword cluster in a branch of the ontology. It may be appropriate to provide a valuation of the keywords in this context? This point could be the subject of a further study. 1. and 1 ': Possibility to establish a subject's position in the ontology by browsing or through a natural language query (cf. Figure 3). 2. Positioning identifies a user point of view and interests, 3. and 3 ': Generating meta data and establishing requests to the RDF internally or to digital on-line libraries. 4. and 4 ': Presentation of the titles of the articles corresponding to the request and found in the RDF, or the foundation of scientific knowledge. 5. Articles are searchable on the net on Google Scholar if Uniform Resource Identifier (W3C, MIT, 2005) is absent from the base or directly available on digital libraries. If digital libraries are used, the access to a document is direct. The first stage of the research is to navigate down the tree until the node that is the most representative of the concept sought. The context block (cf. Figure 4) offers a direct access to on-line digital library articles as CSBIB, DBLP, or ACM by generating contextual meta-queries to these sites. In the context, queries are called meta-queries because they do not directly generate a request, but an URL with keywords. The remote Knowledge Base System (KBS) will use its own search engine to generate the real request. But the tool also proposes to search the internal database of titles of articles. In the example, search for "database management" is generated and proposes several dozen results. The article: "Managing taxonomies in relational databases" was chosen. The database provides us with the name of the principal author. The tool checks for the presence of an URI on the article in the database. In the absence of an URI a request to Google Scholar is automatically generated, which provides us with a direct access to the article (cf. Figure 5). Tests were performed on the classical databases, but results pertaining exactly to the subject of research are still too few. This mechanism for generating requests is still in a heuristic stage, but opens interesting prospects.

Trial of navigated search

Results

OntologyNavigator was experimented within the University of Paris 8 (in France) in Computer Sciences department and in the Library Sciences one. It is as well accessible on-line, but the fee paid by the Library to ACM portal only grants access within the University. Nevertheless, the tool also uses several free on-line databases. A feedback form is available to get feelings and comments about the tool. The answers were used to measure final user's interest. The questions were asked about the usability, the intuitive and the results produced by the tool. Users' habits were also measured with cookies and Google Analytics. The most often comprehensive problem that users had with the tool was the lack of intuitive. The cross language search based on meta-data gave some lack of results, as described in the following paragraph. and "Computer vision". We then tried to use the folksonomy option for the automated processing of language to propose an alternative translation for the ontology node (cf. Figure 2). For example, the node I.3.3 "generation of images and photos" originally "picture / image generation" was given the alternative French proposal "rendu non-photoréaliste" (NPR). This proposal has no chance of being selected as the best translation by the committee of experts. This is in fact not a real translation of the node label. It is a specification and not equivalent. However, this proposal gave a result in the next time query because it created a specific entry for the French sentence "rendu non-photoréaliste". This notion, if researchers use it, allows users to include concepts of equivalence or specification outside of the simple syntax correction. This option allows the tool to avoid terminology tendencies of the moment. For instance, in French, "rendu non-photoréaliste" (NPR) referred to the previous paragraph is not at the time of writing these lines transcription of the most widely used concept involved. The denial word "non" in "rendu non-photorealiste" conveys a negative image. Because of that fact, French specialists more likely uses "rendu expressif" (Expressive rendering) for about two years. The participatory community (folksonomy) also allows members to correct the shortcomings of automated processing of language. It is certain that the growing number of users of the tool significantly affect the quality of research results. This tool has the flexibility of a virtual index on a scalable corpus and presents a possible match between needs of knowledge and virtual location of on-line IT scientific articles for the young researcher.

6 OntologyNavigator experiments social tagging and relies on researchers' involvement to enhance the quality of its translations. Moreover, it helps the community monitoring the evolution in indexed concept terminology. This tool is the only one to be able to manage to research into English language from a French request (Cross Language Retrieval).

To conclude this comparative study, OntologyNavigator provides the classical services of other KBS. Besides it adds the ability to browse through search area map navigation, which is an educational advantage. What's more OntologyNavigator offers a contextual overview that would be difficult to apprehend through a mere listing. It may happen that the articles offered by the Internal are not what the user is looking for. In this case, equivalent queries in the form of hyper-links to the main area of KBS are available. OntologyNavigator was thought to be compatible with Zotero. The two together offer the possibility to manage bibliographic records and create bibliographies. These are exported by plug-in in any format of scientific conferences, and is ready for any tool of publication (LaTeX, Word, OpenOffice...). The testing of the tool by users has shown that the adequacy of current meta-data queries generated is relevant. Nevertheless the results are sometime poor or too big on external databases, but more precise on OntologyNavigator own database. However, the more the ontology's content is enriched with articles, the more research and indexing will become accurate. For this purpose, a pre-existing important size corpus was indexed. We will set the goal of creating a script for extracting incremental content on the on-line library DBLP updates. This ongoing automation work should refine the relevance for indexing and searching through ontology. Another limitation is the physical access to articles that is often subject to the payment of a subscription fee or even a fee per article. That is why it is easier to implement the solution in a university laboratory or a library. However, the use of proxy should help extend access to digital libraries for an entire campus. The tool will be made available to students in their second cycle of studies in the IT department and for the computation centre of the University of Paris 8. An on-line form is available for the purpose of recording feedback and follows the evolution of the users. In the near future it is planned to extend the application with an ontology based on the Friend of a Friend format (W3C, RDF and SemWeb developer, 2007) for a better understanding of the working groups, teams, and laboratories as well as links to disciplinary transversally. Another goal is to make the system as independent as possible. Possibly the hyperbolic tree / eye tree type navigation system will be modified if another way of displaying the tool emerges. To facilitate the use of items found and selected by young researchers, an interesting feature could be developed in the form of one or several thematic bibliographies on BibTeX format and thus reusable in every article and shareable with researchers with similar profiles.

Conclusion

In the French University context, advanced learners, in 2 and 3 study cycles (end of graduate and postgraduate studies) often experiencing real difficulties in collecting the documentation in their field of study or research. The main purpose is to help these learners by providing a tool to supplement their perception of the knowledge domain "stored" in ontology. It is to consider, even hoping, that the tool will become obsolete by his mastery (because mastery of the tool is an intrinsic source of knowledge). This study focuses on bibliographical research in the IT field by "insiders" but not experts, i.e. young researchers that are increasingly lost in a predominantly English corpus. The basis of this research is a reflection on the concept of projecting domain ontology on the concepts of portal and search engine relevance. This approach tends to generate a transparent and intuitive man-machine interface (MMI) in order to improve the user approach. The question raised by this discussion is the impact of knowledge representation on information retrieval and learning. Is the impact of the tool on the results obtained as compared to more traditional research significant? The ultimate goal of this research is to develop an incremental system and ideally an autonomous system capable of indexing scientific documents by extracting keywords and placing articles in IT domain ontology. The autonomy of the system would be a significant factor in cost reduction. More importantly it could avoid having a group of experts lost in an endless work with every technical or ideological detail which would provoke discussions on the appropriateness of indexing a new concept or not, and on the place of the new concept on the ontology. This approach will also provide easier access to information sought by search engines using natural language, keywords, context, or semantic proximity. Thus, and this is the key concept, even a user who does not master the entire computer vocabulary (and the English language) might find relevant articles in several languages which he would not have accessed through traditional research methods. This article proposes to implement the first part of this task, namely the construction of ontology, and of a navigation system to browse and search the ontology in a scientific corpus. In this work, a research tool for scholars whose work is related to IT as been created. This consists in an on-line interface to link an ontology search to on-line scientific libraries. The ontology-based ACM CCS has been translated into French in an automatic way to assist researchers wishing to conduct research in French. This solution offers researchers a possibility to find articles on a study revolving around a node in the IT ontology field. This query is generated by graphic navigation or natural language queries. Once the research is completed an automated system can find articles on the internal database or propose meta-data queries to scientific on-line digital libraries. The system generation of metasearch is based solely on the titles of nodes in the ontology. However, the results are encouraging and the prospects for improvement in the near future are already under consideration. For the time being, OntologyNavigator works only on the IT field. Very advanced domain ontologies can also be found in biomedical, standards and safety of the building construction [START_REF] Barzic | Ontologie prévention et sécurité dans les métiers du bâtiment, Aide sémantique à la navigation en ressource documentaire professionnelle fondée sur une ontologie de domaine[END_REF], and law fields. The application can be exported in any of these areas by changing the KBS and ontology domains.

Figure 1 .

 1 Figure 1. ACM CCS short sample and an XML translation of the native implicit descriptors list

Figure 2 .

 2 Figure 2. Alternative translation of a node

Figure

  Figure 3. Functional scheme

Figure 4 .

 4 Figure 4. Search scientific papers by navigating through ontology and zoom on the focused context

Figure 5 .

 5 Figure 5. Scientific paper proposed by the system A PhD candidate in computer graphics has done research in ontologyNavigator with the French sentence "rendu non photo-réaliste" (Non-Photo realistic Rendering). Research in ontology failed. The tool printed: "rendu non photo-réaliste" does not exist in French in the ACM ontology" what are known to be false in English. The articles on the NPR are usually classified under I.3 and I.4 nodes of the ACM ComputerClassification System. These two nodes are respectively labelled "Computer Graphics and image processing" and "Computer vision". We then tried to use the folksonomy option for the automated processing of language to propose an alternative translation for the ontology node (cf. Figure2). For example, the node I.3.3 "generation of images and photos" originally "picture / image generation" was given the alternative French proposal "rendu non-photoréaliste" (NPR). This proposal has no chance of being selected as the best translation by the committee of experts. This is in fact not a real translation of the node label. It is a specification and not equivalent. However, this proposal gave a result in the next time query because it created a specific entry for the French sentence "rendu non-photoréaliste". This notion, if researchers use it, allows users to include concepts of equivalence or specification outside of the simple syntax correction. This option allows the tool to avoid terminology tendencies of the moment. For instance, in French, "rendu non-photoréaliste" (NPR) referred to the previous paragraph is not at the time of writing these lines transcription of the most widely used concept involved. The denial word "non" in "rendu non-photorealiste" conveys a negative image. Because of that fact, French specialists more likely uses "rendu expressif"

Table 1 .

 1 KBS comparedEach tool offers a great number of scientific articles related to the subject sought. The idea of this comparative study is not to count the number of items returned. However, the services involved in the research were not all equal. The most often used service is the provision of meta-data in an adequate format to write a thesis or a scientific article bibliography. Usually, when such a service is available, a hyper link can generate a BibTeX or Endnote notice. The ACM portal, CiteSeer, IEEE, CSBib or OntologyNavigator, offer this service. A comparable alternative is the integration of meta-data on Article directly in XHTML thanks to micro-formats and Dublin Core. ACM, CiteSeer, CSBib, HAL, Edutice and OntologyNavigator offer this alternative service that can integrate items to Zotero. In this case, there is no need to create bibliography service within a KBS interface. CiteSeer, IEEE, ArXiv, and Delicious integrate a bibliography service. Some databases of scientific knowledge create hyper links to other KBS from the initial research. This applies to CisteSeerX, IEEE, CSBib and DBLP. It is the main purpose of Google Scholar or OntologyNavigator. This tool dynamically creates hyper-links toward all the quoted sites in addition to its own database. Social tagging is supported natively by Delicious, because it was settled as a social tagging website.

	OntologyNavigator and other KBS
	Meta-data
	export
	available
	yes	yes	yes	yes	yes	no	yes

Lemmatization is the process of finding the normalized form of a word.


Manel Fredj

Apostolos Zarras

Nikolaos Georgantas

Valérie Issarny

Dynamic Maintenance of Service Orchestrations

come   L'archive ouverte pluridisciplinaire

INTRODUCTION

Service Oriented Architecture (SOA) is an architectural style that emerged recently as the answer to the latest requirements for loosely-coupled distributed computing (Cardoso & Sheth, 2006). Inline with the conventional distributed computing paradigm, functionality is decomposed into distinct architectural elements, distributed over the network. Nevertheless, in SOA the basic architectural elements (i.e., services) are by themselves autonomous systems that have been developed independently from each other. Moreover, services evolve independently. A service may be deployed, or un-deployed at anytime. Its implementation, along with its interface may change without prior notification. Services are typically combined in a loosely-coupled manner by building service orchestrations. Basically, an orchestration is a workflow that consists of a set of activities which exchange data with a set of services. The orchestration incarnates the basic control and dataflow dependencies that govern the execution of these activities.

In the context of SOA, several research efforts grew with the main focus being on the discovery and the systematic composition/orchestration of services, e.g., (Ben Mokhtar et al., 2006;[START_REF] Berardi | Automatic Service Composition Based on Behavioral Descriptions[END_REF]Yang & Papazoglou, 2004). One of the next challenges in this field is the maintenance of service orchestrations towards accomplishing the ultimate goal of constructing eternal service-oriented systems out of loosely-coupled basic architectural elements [START_REF] Fredj | Dynamic Service Substitution in Service-Oriented Architectures[END_REF]. To this end, in this chapter we focus on the dynamic maintenance of a set of executing orchestrations upon the unavailability of a service that is required for the execution of these orchestrations. The deal with this problem we propose an approach that enables the dynamic substitution of the unavailable service with an available one. The proposed approach is aimed at W3C Web services (W3Ca, 2004); we assume that services exchange information with the rest of the world within SOAP messages; service interfaces are specified in SA-WSDL (W3Cb, 2007); finally, service orchestrations are specified in terms of BPEL (IBM, 2002). Dealing with the dynamic substitution of stateless services is more or less straightforward. Thus, we concentrate on the worst case that involves the dynamic substitution of stateful services. According to the standard WS-Resource Framework (OASIS, 2004), we assume that service state descriptions may be provided, along with service interface descriptions.

Several approaches that deal with the unavailability of services, e.g., [START_REF] Salatge | [END_REF], rely on the construction of fault tolerant service groups out of unreliable services. The formulation of fault-tolerant groups of services as proposed in the state of the art seems difficult to apply when considering that the constituent services may be offered by competitive organizations or businesses. In this realistic scenario no independent business (e.g., a hotel) will accept to register its online service as a passive backup member of a group of services. Similarly, no independent business will accept to register its online service in a group that realizes active replication, while knowing that this will involve devoting precious resources to the group without any actual benefit (many reservations made by the same customer to each of the active replicas, while only one of them will be validated at the end of the protocol that realizes the reservation process through the active replication group). Similarly, in the field of dynamic reconfiguration of conventional distributed systems, several approaches tackled the issue of substituting an entity for another prefabricated backup entity [START_REF] Kramer | [END_REF][START_REF] Goudarzi | Maintaining Node Consistency in the Face of Dynamic Change[END_REF][START_REF] Hauptmann | [END_REF][START_REF] Minsky | Building Reconfiguration Primitives into the Law of a System[END_REF][START_REF] Warren | [END_REF][START_REF] Bidan | A Dynamic Reconfiguration Service for CORBA[END_REF][START_REF] Blair | The Role of Software Architecture in Constraining Adaptation in Component-Based Middleware Platforms[END_REF][START_REF] Poladian | Dynamic Configuration of Resource-Aware Services[END_REF]. As previously discussed, the problem of service substitution is far more complex. In SOA, we can assume the possible existence of several semantically compatible services capable of performing the same or similar tasks. However, each one of them constantly serves requests and can not be considered as a passive backup for other services.

Therefore, the service substitution process that we are after consists in (1) discovering candidate substitute services out of a set of semantically compatible services that can be used in place of a service, which becomes unavailable and, (2) trying to identify one amongst these candidates that can be used as an actual substitute; whenever possible the selected substitute service must be such that its current state can be synchronized with the state of the unavailable service. Based on the above, our contribution is SIROCO, a middleware platform that enables the dynamic maintenance of service orchestrations upon the unavailability of services used in these orchestrations.

The rest of this chapter is structured as follows. Section 2 provides the necessary background on dynamic substitution of basic engineering elements in conventional distributed systems and discusses work related to service substitution in particular. Section 3 discusses in detail our approach to the problem of dynamic service substitution in SOA. Section 4 presents an evaluation of our first prototype. Finally, Section 5 provides our conclusions and future research issues.

BACKGROUND & RELATED WORK

Background

To provide a background on the dynamic substitution of basic engineering elements in conventional distributed systems, we rely on a generic reconfiguration cycle, which provides an abstract descriptive view of reconfiguration approaches that have been proposed in the past (the interested reader may refer to [START_REF] Zarras | Engineering Reconfigurable Distributed Software Systems: Issues Arising for Pervasive Computing[END_REF] for a more detailed survey).

Conceptually, the basic entities involved in the reconfiguration cycle are the Reconfigurable System (RS), its Context or Environment (CE), and the Reconfiguration Management System (RM). CE consists of prefabricated passive functional entities that can be used for the reconfiguration of RS. RM provides all the functionalities that are necessary for the reconfiguration of RS. Conventional approaches assume that RS is described at an abstract level in terms of components and connectors. Based on that, they deal with the reconfiguration of RS in terms of adding, removing and substituting components [START_REF] Kramer | [END_REF][START_REF] Goudarzi | Maintaining Node Consistency in the Face of Dynamic Change[END_REF][START_REF] Minsky | Building Reconfiguration Primitives into the Law of a System[END_REF][START_REF] Bidan | A Dynamic Reconfiguration Service for CORBA[END_REF][START_REF] Kramer | [END_REF]Hofmeister & Purtilo, 1993), and connectors [START_REF] Blair | The Role of Software Architecture in Constraining Adaptation in Component-Based Middleware Platforms[END_REF][START_REF] Kon | The Case of Reective Middleware[END_REF][START_REF] Kon | [END_REF].

The reconfiguration cycle typically comprises a sequence of phases that take place during the lifetime of RS. These phases support the reconfiguration of RS whenever needed. In Phase 1, RS executes normally, while RM monitors RS. The monitoring tasks typically include checkpointing the state of RS as this state changes. Phase 2 takes place whenever a cause for reconfiguration emerges. RM detects the emerging cause for reconfiguration after having observed current monitoring data and compared it with execution constraints. In Phase 3, RM prepares RS for reconfiguration. This preparation concerns components affected by the intended reconfiguration and may take several forms. For example, request blocking [START_REF] Kramer | [END_REF][START_REF] Goudarzi | Maintaining Node Consistency in the Face of Dynamic Change[END_REF][START_REF] Bidan | A Dynamic Reconfiguration Service for CORBA[END_REF], request redirection [START_REF] Minsky | Building Reconfiguration Primitives into the Law of a System[END_REF] or request queuing may be enforced on components that interact with a component that must be substituted. In Phase 4, RM determines the contribution of CE to the new configuration. In Phase 5, RM adapts RS to the new configuration. In this phase, the substitution of components or connectors further implies transferring the state of the elements used in the current configuration to their substitute elements [START_REF] Warren | [END_REF][START_REF] Blair | The Role of Software Architecture in Constraining Adaptation in Component-Based Middleware Platforms[END_REF]. Finally, in Phase 6, RM carries out the final reconfiguration actions, which typically comprise producing a new configuration description and putting RS back to normal execution (Phase 1)).

Related Work

Concerning the particular problem of service substitution, there have been few interesting approaches, which we discuss in the remainder of this section. /these approaches mainly focus on the enabling the substitution of services, while introducing minimum changes in the clients that use these services, i.e. the service orchestrations in our particular system model.

In [START_REF] Melloul | [END_REF] the authors propose a framework that allows defining abstractions, which are called service composition patterns. A composition pattern can be refined into various alternative concrete service compositions. Consequently, an orchestration developed with respect to the composition pattern can exploit these alternatives without any changes. A similar approach that involves abstractions is proposed in (Yang & Papazoglou, 2004). Moreover, in [START_REF] Taher | Towards an Approach for Web Services Substitution[END_REF] another approach is proposed, which is based on the definition of abstractions, named abstract services. An abstract service represents a set of alternative concrete services that offer the same functionality, via different interfaces. Technically, the abstract service interface can be mapped into the interfaces of the alternative concrete services. Then, a service orchestration that has been built based on the abstract service interface may use, any of the alternative concrete services, without changes in the orchestration. Going on step further, in [START_REF] Athanasopoulos | Towards the Maintenance of Service Oriented Software[END_REF] we discuss the need for a systematic process that mines service abstractions out of existing services that offer similar functionality via different interfaces.

In the same spirit [START_REF] Ponnekanti | Interoperability Among Independently Evolving Web Services[END_REF] discusses the issue of substituting a target service with another concrete service, in the particular case where the interfaces of both services are derived from the same popular, or standardized interface. To deal with such substitution scenarios, various types of incompatibilities between the services' interfaces (structural, value, encoding, semantic), are identified and handled in the proposed approach. Moreover, corresponding resolution options are proposed for structural and value incompatibilities. Based on these resolution options an adapter is generated. The adapter provides the interface of the target service, which is implemented based on the functionality that is provided by the interface of the substitute service. Then, the adapter can be accessed by a service orchestration using the original target interface to access the functionality of the substitute service without any changes in the orchestration. The assumption that the interfaces of the current and the substitute services are derived from the same popular or, standardized interface is taken into account in (Ponnekanti, 2003). In this case, the proposed framework exploits a service repository that manages information about available services and adapters that can be used to map the functionality of a service to other services that offer the same functionality via different interfaces. Based on the service repository, a target service can be replaced by a substitute service as long as the repository contains a corresponding adapter. The development of adapters for pairs of services that may get involved in a substitution scenario is assigned to of the corresponding service providers.

Finally, the framework proposed in (Motahari Nezhad et al., 2007) provides mechanisms that aim at detecting both structural and protocol incompatibilities for pairs of services that can be involved in a substitution scenario.

Although all of the aforementioned approaches are valuable towards enabling service substitution, the main issue that still remains open is dealing with the substitution in the particular case of stateful services that become unavailable during the execution of service orchestrations. This issue is the main focus of the SIROCO approach and consequently constitutes the distinctive feature of SIROCO, compared to the state of the art in service substitution.

DYNAMIC SERVICE SUBSTITUTION IN SIROCO

SIROCO offers a Reconfiguration Manager, RM (Figure 1), that provides the necessary functionality for maintaining the execution of service orchestrations in the presence of unavailable services. Without loss of generality, we assume that RM is a centralized entity. However, the proposed approach can be extended in a quite straightforward way towards a coordinated set of RMs. The basic constituents of the SIROCO RM are:

• A BPEL execution-engine that carries out the execution of service orchestrations that are provided to SIROCO by users. In particular, a user may provide as input to SIROCO a BPEL orchestration description and require its instantiation, or even require the instantiation of an orchestration that is already available through SIROCO (i.e., it has been previously registered to SIROCO possibly by a different user).

• A service-registry that manages information concerning Web services that can be used for the execution of service orchestrations registered to SIROCO.

• A monitoring-manager that inspects the set of orchestrations that are executing through the SIROCO execution-engine.

• An adaptation-manager that dynamically reconfigures the orchestrations when necessary.

Figure 1. Overview of SIROCO.

Therefore, from the point of view of SIROCO the role of RS is played by a set of orchestrations that are concurrently executing through the SIROCO execution-engine. The role of CE is played by Web services that have been registered to the SIROCO service-registry. These services have been independently developed and deployed in certain sites. Taking an example, consider that the SIROCO RM has been provided with an orchestration description that others online medical help to patients. This orchestration may be instantiated multiple times by the SIROCO execution engine for different patients, doctors and pharmacies. Initially, the orchestration receives from the patient his personal details and symptoms. Following, it forwards the patient's symptoms to an associated doctor. At the same time, the patient's social security record is updated with a new tuple that contains information about the patient's e-visit to the associated doctor; this information is inserted in the database of the national social security service. The orchestration waits for the reception of the doctor's prescription which is sent back to the patient. Depending on its contents, the prescription is further forwarded to an associated pharmacy along with the patient's details. The Web services involved in this orchestration are: the one used to communicate with the patient, the one that allows online interaction with the associated doctor's office, the national social security service and the service offered by the associated pharmacy.

Information Managed by SIROCO

The information managed by the SIROCO RM consists of:

• Descriptions of service orchestrations, specified in terms of BPEL (IBM,2002).

• Descriptions of the Web services that have been registered to SIROCO, given in terms of SA-WSDL (W3Cb, 2007).

• Descriptions of the state that is managed by the Web services that have been registered to SIROCO, specified in terms of WS-ResourceProperties documents (OASIS, 2004).

Providing state descriptions for the services is not mandatory in SIROCO. Nevertheless, SIROCO takes advantage of this information, if available, towards dealing with dynamic service substitution.

Specifying Service Orchestrations

The specification of service orchestrations in SIROCO is standardized and quite straightforward. Briefly, a BPEL (IBM, 2002) orchestration specifies a set of activities, which may be either simple or structured. Simple activities may involve the reception of a message, the invocation of a service operation, or the reply to a message. Structured activities prescribe control flow dependencies for a set of constituent activities (sequential execution, concurrent execution, conditional execution, etc.). A BPEL specification further comprises the definition of variables which serve as placeholders for the data exchanged with the services during the execution of the BPEL activities. Finally, BPEL supports the specification of fault handling and compensation activities. Such application-specific activities, introduced by the authors of a BPEL orchestration, may also serve for handling the unavailability of a service. In general, we see these facilities as complementary to our approach, which aims at handling service unavailability without requiring the intervention of the authors of BPEL orchestrations.

Figure 2, gives a simplified view of the BPEL description that specifies the online medical help conversation. In particular, a receive activity accepts a request from a patient. Following, a flow activity (i.e., a concurrent activity) is used towards interacting concurrently with the service that is deployed at the doctor's office and the national social security service. The first branch of the flow activity further comprises a switch activity (i.e., a conditional activity) that interacts, if necessary, with the service that is deployed in the pharmacy.

Specifying Service Descriptions

Typically, Web service descriptions are specified using WSDL. Nevertheless, in SIROCO we employ a standard extension of this notation, which allows us to add semantic annotations to standard WSDL descriptions. The purpose of adding semantic annotations to service descriptions is twofold:

• Service interfaces (i.e., PortTypes) are annotated with semantic concepts defined in an OWL ontology offered by SIROCO to enable the classification of services that offer semantically compatible functionality in corresponding semantic categories. The OWL ontology that we assume relies on a well-known thesaurus of concepts, called WordNet (WordNet, 2006).

• Operations offered by a service interface are annotated with either the UpdateState, or the QueryState OWL concept (Figure 3) in order to distinguish between operations that update the state of the service and operations that simply query the state of the service. As explained later, this distinction serves for enriching a BPEL orchestration with activities that allow the SIROCO monitoring-manager to checkpoint (if possible) the state of a service before the execution of activities that invoke operations, which change the state of the service. Checkpointing is possible if the description of the service is further associated with a description of the service state. The semantic annotation of service descriptions is a responsibility of the service providers who should further collaborate with the SIROCO administrator who is in charge of validating the service descriptions and extending the SIROCO OWL ontology, whenever necessary. Regarding our scenario, Figure 4 gives a simplified (UML-like) view of the interface (i.e., the GeneralPractitionerPT port type) that is offered by a service, which provides access to a doctor's office. The interface is annotated with a reference to the GeneralPractitioner OWL concept (Figure 5). Each operation of the GeneralPractitionerPT interface is annotated with a reference to the UpdateState or the QueryState OWL concepts (Figure 3). The enqueueRequest() operation, for instance, is characterized with the UpdateState concept because it inserts a request from a patient in a waiting queue managed by the service.

Specifying Service State Descriptions

According to the WS-ResourceProperties standard, a service state description defines an XML complex type that consists of one or more state properties. Still according to the standard, the values of each property can be queried or updated by sending standardized SOAP messages towards the service; the service is obliged to provide corresponding functionality that handles these messages. The messages are characterized by the names of the properties involved.

In SIROCO, we require that the properties that constitute a service state description are defined with respect to the SIROCO OWL ontology. Each property corresponds to a SIROCO OWL concept, which is further associated with an XML data type (simple or complex). The XML elements that constitute the property are also defined with respect to the SIROCO OWL ontology. If a property p is defined as a subclass of another property q one of the following conditions must hold for their associated datatypes, Providing service state descriptions is a collaborative task that involves the service providers and the SIROCO administrator who is in charge of validating the state descriptions and possibly extending the SIROCO OWL ontology, if needed.

Figure 3. State description of a service that provides the GeneralPractitionerPT interface.

In our scenario, the state description of a service that provides the GeneralPractitionerPT interface is given in Figure 6. Figure 7, gives part of the SIROCO OWL ontology that includes the concepts involved in the state description of the service. The description models the waiting queue managed by the service, i.e., the state is a complex XML type that consists of zero or more Patient properties; each property further consists of 5 elements corresponding to the Name, Address, Phone Number, Email and Symptoms of a patient; all 5 elements are of the same XML type (i.e., XML string).

S e r v i c e S u b s t i t u t i o n C y c l e

Phase 1: Normal RS execution During this phase, the BPEL execution-engine is in charge of the concurrent execution of a set of orchestrations that are instantiated according to users' requests. Specifically, at any time a user may provide as input to the BPEL execution-engine a new orchestration description along with abstract descriptions of the services required for the execution of this orchestration (we use the term abstract to refer to SA-WSDL descriptions that do not contain any binding information). Based on this information a number of preparatory steps are performed before instantiating the new orchestration.

First, the service-registry is searched for services that can be used for the execution of the orchestration. The service-registry maintains service catalogs. Each catalog corresponds to a different semantic category of services and therefore it is characterized by an OWL semantic concept such as the ones given in Figure 5. Each service catalog is progressively populated (during the lifetime of RS) with concrete SA-WSDL descriptions of services (we use the term concrete to refer to SA-WSDL descriptions that contain binding information) that are registered to the service-registry. Hence, given the semantic concept that characterizes the abstract SA-WSDL description of a service that is required for the execution of the new orchestration, the corresponding service-registry catalog is located. The catalog is then searched for a concrete service description whose WSDL interface syntactically matches the WSDL interface that is specified in the abstract service description. If multiple concrete services are discovered in this step, one of them is randomly selected.

In our scenario, the execution of the online medical help orchestration (Figure 2) amounts to locating a service-registry catalog, annotated with the GeneralPractitioner (Figure 5) semantic concept. Following, the catalog is searched for a concrete service description that specifies an interface that syntactically matches the GeneralPractitionerPT interface, described in Figure 4. The service discovery step is followed by the enrichment of the orchestration description with checkpointing activities. In particular, a concrete service description resulted from the previous step may be associated with a service state description. Moreover, every operation of the interface that is offered by the discovered concrete service is characterized by a semantic annotation (Figure 3) that specifies whether or not the operation changes the state of the service. Based on this information, the BPEL description of the new orchestration is searched for activities that invoke operations which change the state of the service. For every such activity a, a checkpointing activity that precedes a is added in the orchestration. As prescribed by the WS-ResourceProperties standard, the checkpointing activity (a) constructs a standardized message that queries the values of the properties that are specified in the service state description, (b) sends the message towards the service and (c) waits for the reception of a corresponding reply message that contains the current values of the properties that constitute the state of the service. The state data are enriched with identifiers that characterize the orchestration and the activity a. Finally, the state data are forwarded to the monitoring-manager, which stores them persistently.

In our scenario, the orchestration description of Figure 2 must be enriched with checkpointing activities. Such an activity must be added, for instance, before the activity that invokes the enqueueRequest() operation on the service that offers the GeneralPractitionerPT interface (highlighted in Figure2). The message that queries the contents of the waiting queue managed by the service (i.e., the list of the Patient properties specified in the WS-ResourceProperties document of the service (Figure 6)) is given in Figure 8(a). An example of a response message that contains the service state data is given in Figure 8 The preparation for the execution of the enriched orchestration ends by parsing the orchestration description towards the construction of ( 1) an abstract control-flow dependency graph (CDG) (e.g., Figure 9) and ( 2) an abstract dataflow dependency graph (DDG) (e.g. Figure 10), which shall serve for the dynamic maintenance of the orchestration. The nodes in both graphs are the basic BPEL activities of the orchestration. Typically, in the control-flow graph, a dependency from an activity a to an activity b specifies that the execution of a precedes the execution of b. In the dataflow graph, a dependency from an activity a to an activity b specifies that the output produced by a as a result of interacting with a service is utilized by b as an input to the same or another service. The CDG and DDG are given as input to the adaptation-manager. Finally, the BPEL execution-engine begins the execution of the enriched orchestration. Figure 7. DDG for the online medical help scenario.

Phase 2: A cause for dynamic substitution occurs

This phase takes place upon the occurrence of a cause for dynamic service substitution. While the BPEL execution-engine of SIROCO executes orchestrations, interaction with the Web services involved may result into an exception which serves as a notification that a service is not available. If such an exception is caught, the execution-engine notifies the SIROCO adaptation-manager. Technically, in our prototype interactions with Web services are realized through the standard JAXRPC mechanism. Therefore, the execution-engine checks for standard JAXRPC exceptions (e.g., RemoteException) that may be thrown while an activity attempts to interact with a Web service.

In our scenario, assume the following failure scenario which shall be used in the remainder of this section: the online medical help orchestration has been instantiated twice for different patients that contact the same doctor; a RemoteException exception is caught by the executionengine; the exception refers to the first orchestration and specifically it is caught during the execution of the activity that invokes the getPrescription() operation on the GeneralPractitionerPT service (i.e., activity 5 in Figure 9); as a result the execution-engine notifies the adaptationmanager about the unavailability of this service.

Phase 3: Preparing the substitution

This phase begins when the SIROCO adaptation-manager is notified about the occurrence of an exception in the execution of an orchestration. The adaptation-manager checks the set of executing orchestrations for other affected orchestrations. The set of affected orchestrations consists of the orchestration that failed to interact with the service and all other executing orchestrations that interact with the unavailable service. The execution of certain of the affected orchestrations may be in points where they have already interacted with the unavailable service, while the execution of certain others may be in points where the first interaction with the unavailable service will take place in the activities that follow. In both cases, the adaptationmanager blocks the execution of the affected orchestrations to prevent the occurrence of further exceptions.

In our example, the set of affected orchestrations includes both of the instantiated online medical help orchestrations.

Phase 4: Planning the substitution actions

With the affected orchestrations blocked, the goal of this phase is to discover candidate substitute services that may take the place of the unavailable service. To this end, the adaptation-manager contacts the service-registry. As in Phase 1, the service-registry looks for the service catalog that contains descriptions of services that are semantically compatible with the unavailable service. Technically, this is the catalog that is characterized by the OWL semantic concept that also characterizes the SA-WSDL description of the unavailable service.

In our scenario, for instance, the registry locates the service catalog that is characterized by the GeneralPractitioner concept (Figure 4). The service catalog may include several concrete SA-WSDL descriptions of services that provide different interfaces. The service catalog is searched for services whose interface syntactically matches the interface of the unavailable service. In particular, the GeneralPractitioner catalog is searched for concrete SA-WSDL descriptions of services that provide the GeneralPractitionerPT interface. The search results are divided in two sets. The first set, StateCompatibleServices, contains descriptions of services that are associated with service state descriptions (i.e., WS-ResourceProperties documents) which are semantically compatible with the service state description of the unavailable service. The second set, StateIncompatibleServices, contains all other descriptions of services with matching interfaces. Obviously, if the unavailable service is not accompanied with a service state description, StateCompatibleServices = Ø.

To avoid the extra overhead of checking for state compatibility between service state descriptions at the time when there is a need to substitute an unavailable service, state compatibility relations are established as the SIROCO service-registry is progressively populated with service descriptions. The semantic compatibility of two service state descriptions st, st' is defined according to the following intuition. As discussed in Subsection 3.1, the properties that constitute st and st' correspond to SIROCO OWL ontology concepts. Therefore, we consider that st is compatible with st' if there exists a one-to-one and onto mapping between the properties of st and st'. According to this mapping every property st p st ∈ should be mapped to a property ' ' st p st ∈ such that:

• the OWL concept that corresponds to st p is equal to the OWL concept that corresponds to ' st p or,

• the OWL concept that corresponds to st p is a subclass of the OWL concept that corresponds to ' st p .

Figure 8. State description of a candidate substitute service that provides the GeneralPractitionerPT interface.

In our scenario, suppose that the GeneralPractitioner catalog contains the description of a candidate substitute service, which is associated with the state description that is given in Figure 11. As detailed in Figure 12, the state description of the candidate substitute service (Figure 11) is semantically compatible with the state description of the unavailable service (Figure 6). Specifically, Patient is an OWL subclass of Case (Figure 7). Figure 12 further details how the elements that constitute Patient are recursively mapped into the elements that constitute the Case property; Address is an OWL subclass of Location, Symptoms is an OWL subclass of Evidence, etc.

The two state compatibility constraints that we use guarantee that state data that have been obtained by checkpointing the unavailable service can be transformed into state date that can be handled by a candidate substitute service. As explained in Subsection 3.1, every OWL concept is associated with a corresponding XML data type. Therefore, if a property st p st ∈ is mapped into a property ' ' st p st ∈ such that the first of the compatibility constraints holds, then the data type of Nevertheless, the ability to transform state data does not guarantee that the substitution of the unavailable service with a candidate substitute service that belongs in StateCompatibleServices shall be successful. This issue is further discussed in the following subsection.

Phase 5: Adapting the current configuration

Given the two sets of candidate substitute services (i.e. the StateCompatibleServices and the StateIncompatibleServices sets) that resulted from the previous phase, the adaptation-manager tries to select a service out of these sets to actually substitute the unavailable service. First, the adaptation-manager queries the monitoring-manager for the latest state data obtained from the unavailable service.

Following, the adaptation-manager iterates over the StateCompatibleServices set. For each candidate substitute service ∈ s StateCompatibleServices, the adaptation-manager tries to synchronize the current state of s with the state data of the unavailable service. As discussed in the previous subsection, the synchronization may involve transforming the state data of the unavailable service into state data that can be handled by s, with respect to the semantic mapping between the state descriptions of the services.

Regarding our scenario, assume that the adaptation-manager selects from the StateCompatibleServices set the service s that is associated with the state description of Figure 11. The XML data types of the elements that constitute the state property of s (Figure 11) are equal to the data types of the elements that constitute the state property of the unavailable service (Figure 6). Therefore, the transformation of state data (Figure 8(b)) that have been obtained from the unavailable service is quite simple. According to the semantic mapping of Figure 12, the transformation amounts to simply renaming certain XML tags (e.g., the Patient property should be renamed to Case, the Address element should be renamed to Location, etc.).

Figure 10. State synchronization message for the candidate substitute service; the message is generated with respect to (1) the state descriptions of the unavailable and the candidate substitute services (Figures 6,11) and,(2) the semantic mapping between these state descriptions (Figure 12).

Then, the adaptation manager tries to update the properties that characterize the state of s with respect to the transformed state data of the unavailable service. According to the WS-ResourceProperties standard, this step involves sending to s a standardized SetResourceProperties message. In our scenario, the synchronization between the states of the two services involves inserting the contents of the waiting queue of the unavailable service, into the waiting queue of the substitute service by sending the message that is given in Figure 13.

The result of the synchronization may be successful or not. In the latter case, s shall respond to the adaption-manager with a standardized fault message and the adaptation-manager shall proceed with another service from the StateCompatibleServices set. In our scenario, for instance, the waiting queue of the candidate substitute service may be full. In this case, the SetResourceProperties message shall fail and the next candidate will be examined by the adaptation-manager. If the state synchronization fails for all candidate services that belong to the StateCompatibleServices, the adaptation-manager randomly selects a service from the StateIncompatibleServices set. Phase 6: Completing the execution.

The goal of this phase is to put the affected orchestrations back to normal execution. This task highly depends on the outcome of the previous phase.

In particular, if the adaptation-manager discovers a service substitute in the StateCompatibleServices set, the execution of all the affected orchestrations is resumed from the points where they were stopped (i.e., from the activities that were blocked or failed). In our example, we assumed 2 instances of the online medical help orchestration, affected by the unavailability of the GeneralPractitionerPT service. The execution of the first orchestration failed during activity 5 (Figure 9, 10), while the execution of the second one was blocked right before contacting the GeneralPractitionerPT service for the first time (i.e., before activity 2). Therefore, in this case the first orchestration is resumed from activity 5, while the second one is resumed from activity 2.

One the other hand, if the adaptation-manager discovers a service substitute in the StateIncompatibleServices set, the affected orchestrations are rolled-back to a point that precedes the first interaction with the unavailable service. Identifying this point involves using the CDG and the DDG of the affected orchestrations, while further taking into account the checkpointing activities that relate to the rest of the services used in these orchestrations. In our example, the first interaction with the unavailable service was during activity 2. Hence, the execution of both orchestrations is rolled-back to activity 2.

EVALUATION

To evaluate the basic concepts of SIROCO we developed a first prototype and performed a number of experiments. The prototype and all our experiments were based on the AXIS SOAP engine and the Apache Tomcat application server. The SIROCO BPEL engine currently does not support full-featured BPEL orchestrations (e.g., handlers, pick activities, wait activities are not supported).

The main benefit from using SIROCO for the development of service orchestrations is the ability to dynamically maintain them to confront the unavailability of the services involved. On the other hand, the price to pay for this ability is the need for enriching the orchestrations with additional checkpointing activities, which introduce an overhead in the execution of the orchestrations. Hereafter, we use the term enhanced-orchestration to refer to an orchestration enriched with checkpointing activities. Respectively, we use the term original-orchestration to refer to an orchestration that does not include checkpointing activities.

Based on the previous remarks we performed two sets of experiments. In the first set, we compared the execution time of enhanced-orchestrations against the execution time of the original-orchestration in various scenarios of normal execution (i.e., there were no unavailable services during the orchestrations execution). In the second set of experiments, we measured the execution time of enhanced-orchestrations in various failure scenarios that can not be handled by the original-orchestrations.

In both sets of experiments, we used BPEL orchestrations that combine 5 Web services ( . In both sets of experiments, we used 4 different variants of orchestrations, where we varied the number of operations of each service that change the state of the service as follows: 1, 2, 5 and 10 operations per service. Therefore, we varied the number of checkpointing activities introduced in the orchestrations from 5 to 50. Finally, in both sets of experiments, the SIROCO RM was deployed on an 1.6 GHz Intel Centrino, with 1GB RAM, while the services were deployed on 1.7 Intel Pentium, with 1 GB RAM. Figure 14(a) summarizes the results from the 1st set of experiments (average execution times with a 95% confidence interval of 1%). Expectedly, the overhead of the checkpointing activities introduced by SIROCO in the execution of the orchestrations is linear to the number of checkpoints.

In the 2nd set of experiments we assessed the SIROCO approach in 5 different failure scenarios where 1 WS became unavailable. Specifically, in each scenarioi ; { } + . We assumed a candidate substitute for 1 WS for which the state synchronization was successful. The results from this set of experiments are summarized in Figure 14(b) (average execution times for the 5 failure scenarios with a 95% confidence interval of 2%). As we can observe the overall maintenance overhead introduced by SIROCO in the presence of unavailable services is quite reasonable.

CONCLUSION

In this paper we detailed the SIROCO middleware platform that enables the dynamic substitution of stateful services during the execution of service orchestrations. As opposed to conventional dynamic reconfiguration approaches, the SIROCO reconfiguration process consists of (1) discovering candidate substitute services out of a set of semantically compatible services that can be used in place of a service that becomes unavailable and (2) identifying one amongst these candidates that can be used as an actual substitute; whenever possible the selected substitute service is such that its current state can be synchronized with the state of the service that is substituted. The basic concepts of SIROCO were discussed in detail along with an experimental evaluation of our first prototype. Our findings showed that SIROCO provides the necessary means for achieving dynamic service substitution with a reasonable expense on the execution of service orchestrations.

However, the problem of dynamic service substitution involves further challenging issues for future research. Currently, we focus our efforts towards an optimization mechanism that would allow the efficient enrichment of service orchestrations with checkpointing activities. Moreover, we work towards a mechanism for the distributed coordination of multiple SIROCO middleware instances. Finally, we plan to extend our approach to enable the substitution of unavailable services with semantically compatible services that provide different interfaces.

Figure 2 .

 2 Figure 2. The online medical help BPEL orchestration.

Figure 3 .

 3 Figure 3. Ontology concepts used for distinguishing SA-WSDL operations with respect to their impact on state.

Figure 1 .

 1 Figure 1. Semantically annotated WSDL description of the GeneralPractitionerPT interface.

Figure 2 .

 2 Figure 2. Ontology concepts used for the semantic characterization of medical services.

  the XML elements of and further defines additional XML elements).

Figure 4 .

 4 Figure 4. Ontology concepts used for defining the state of medical services.

  (b).

Figure 5 .

 5 Figure5. Checkpointing messages for a service that provides the GeneralPractitionerPT interface; the messages are generated with respect to the state description of Figure6.The preparation for the execution of the enriched orchestration ends by parsing the orchestration description towards the construction of (1) an abstract control-flow dependency graph (CDG) (e.g., Figure9) and (2) an abstract dataflow dependency graph (DDG) (e.g. Figure10), which shall serve for the dynamic maintenance of the orchestration. The nodes in both graphs are the basic BPEL activities of the orchestration. Typically, in the control-flow graph, a dependency from an activity a to an activity b specifies that the execution of a precedes the execution of b. In the dataflow graph, a dependency from an activity a to an activity b specifies that the output produced by a as a result of interacting with a service is utilized by b as an input to the same or another service. The CDG and DDG are given as input to the adaptation-manager. Finally, the BPEL execution-engine begins the execution of the enriched orchestration.

Figure 6 .

 6 Figure 6. CDG for the online medical help scenario.

  st p is equal to the data type of ' st p . In this case, the values of st p can be directly used as values of ' st p . On the other hand, if a property st p is mapped into a property ' st p such that the second of the compatibility constraints holds, then the data type of st p may be equal to the data type of ' st p , or it may be derived by the data type of ' st p by XML restriction, or by XML extension (Subsection 3.1). In the former case (XML restriction), the values of st p can be directly used as values of ' st p . In the latter case (XML extension), the values of st p contain more XML elements than required for ' st p . Hence, the values of st p can be transformed into values of ' st p simply by removing the extra XML elements.

Figure 9 .

 9 Figure 9. Semantic state compatibility mapping for the state descriptions of Figures 6 and 11.

  one of which offered 10 operations. The control flow of the orchestrations was derived from a combination of two well-known work-flow patterns (Sequence and Parallel-Split(Van Der Aalst et al., 2003)). Specifically, each orchestration consists of a flow activity that comprises 5 sequence activities ( dataflow dependencies between the activities were set according to the following pattern: the output messages of the service operations invoked in activities

  (a) 1st set of experiments. (b) 2nd set of experiments.

Figure 11 .

 11 Figure 11. Experimental results.Figure14(a) summarizes the results from the 1st set of experiments (average execution times with a 95% confidence interval of 1%). Expectedly, the overhead of the checkpointing activities