Jacqueline Bourdeau
email: bourdeau@licef.teluq.uquebec.ca

Riichiro Mizoguchi

Collaborative Ontological Engineering of Instructional Design Knowledge for an ITS Authoring Environment

Intelligence in an ITS authoring system could rely on content-based engineering of instructional design (ID) knowledge, i.e. based on principles such as conceptualization, standardization and theory -awareness. An ontologybased architecture with appropriate ontologies has been proposed for a theoryaware ITS authoring system. Ontological engineering (OE) as a collaborative process jointly conducted by an OE expert and an ID expert is presented as a step on a roadmap towards a theory-aware ITS authoring system.

Introduction

What is (at) the core of Artificial Intelligence and Education (AIED) systems? This has been a question for as long as the field of AIED has come of age, and various answers have been suggested such as curriculum planning [START_REF] Wasson | Instructional Planning and Contemporary Theories of Learning[END_REF][START_REF] Nkambou | CREAM-tools: An authoring environment for curriculum and course building in an ITS[END_REF], student modeling [START_REF] Kay | Accretion Representation for Scrutable Student Modelling[END_REF][START_REF] Mccalla | Active Learner Modeling[END_REF], teaching expertise [START_REF] Goodyear | Teaching Knowledge and Intelligent Tutoring[END_REF][START_REF] Granbastien | Teaching Expertise is at the Core of ITS Research[END_REF], and dialogue modeling [START_REF] Baker | The roles of models in AIED research: a prospective view[END_REF][START_REF] Katz | An approach to analyzing the role and structure of reflective dialogue[END_REF][START_REF] Lajoie | Identifying human tutoring strategies for effective instruction in internal medicine[END_REF], among others. Also suggested was the idea of intelligence implemented all over the periphery of an ITS rather than centralized at a core [START_REF] Andriessen | Where is education heading and how about AI?[END_REF], as is for instance the case of adaptive hypermedia [START_REF] Brusilovsky | Course Sequencing for Static Courses? Applying ITS Techniques in Large-Scale Web-based Education[END_REF].

In this paper, the claim is that declarative knowledge about instruction could be the beating heart of an ITS, where shared intelligence among the designer/author and the authoring environment is the dynamic component for the interactive construction of instructional scenarios and learning environments. The goal of the work presented below is to explore the basic layer needed toward the architecture of an OE based authoring system, as described in [START_REF] Mizoguchi | Using Ontological Engineering to Overcome Common AI-ED Problems[END_REF]. The starting point and the main ideas are therefore shortly reminded in the next section.

Some Problems in ITS and in Instructional Technology Research

ITS research on knowledge representation so far has concentrated mainly on procedural knowledge, as opposed to declarative; cognitive modeling is often conducted from a naturalistic point of view. Authoring of ITS can be said fragmental [START_REF] Murray | Authoring intelligent tutoring systems: an analysis of the state of the art[END_REF]. ITSs have also been a research focus for years in Instructional Technology (IT), a field close to AIED, with the modeling of instructional design knowledge in authoring environments [START_REF] Merrill | An integrated model for automating instructional design and delivery[END_REF][START_REF]Automating Instructional Design: Concepts and Issues[END_REF][START_REF]Automating Instructional Design: Computer-Based Development and Delivery Tools[END_REF], or in an instructional design workbench [START_REF] Paquette | Telelearning Systems Engineering -Towards a New ISD Model[END_REF].

An analysis of the existing in terms of components shows that few environments combine authoring tools and knowledge representation of instructional theories and principles, and that none of them possesses desired functionalities of an intelligent authoring system such as Retrieve appropriate theories for selecting instructional methods or Provide principles for structuring a learning environment.

Declarative knowledge is mainly absent in those systems, as is the maintenance of its integrity. OE has the potential to solve these problems by proposing a declarative knowledge modeling approach [START_REF] Mizoguchi | Architectures and Methods for Designing Cost-Effective and Reusable ITSs[END_REF][START_REF] Ikeda | Task Ontology Makes It Easier To Use AuthoringTools[END_REF][START_REF] Chen | Ontological Issues in an Intelligent Authoring Tool[END_REF]; as a result, the semantic-based knowledge systematization could provide a gateway to learning objects and their management [START_REF] Wiley | Instructional Use of Learning Objects[END_REF]. Instructional Design theories provide the principled knowledge to make high level design decisions such as instructional strategies [START_REF] Jones | Instructional Systems Need Instructional Theory: Comments on a Truism[END_REF], or to orient the lower level decisions such as learning material. However, tackling the systematization of instructional knowledge is not without major challenges; the two next sections will describe some of these challenges.

Collaborative Ontological Engineering of Instructional Design Knowledge: Challenges of such an Enterprise

The ontological engineering process was conducted collaboratively by an OE expert and an ID expert. Among the many challenges of this enterprise are the following questions:

?? should a unification or an integration of theories be a goal, given that theories have competitive or complementary views? ?? should a unification or an integration of theoretical and practical knowledge be a goal, given that such a view is far from available and even questionable? ?? by which criteria should we consider theoretical knowledge? Experimental evidence versus hypothetical or speculative? classical versus emerging? ?? how can a common terminology be found and become acceptable by sometimes divergent theoreticians and practitioners? ?? how to distinguish Learning Theories from Instructional Theories from Instructional Design Theories, when the many classifications available show serious variations and strong overlaps? ?? how to specify these theories when, again, the many classifications of these show serious variations and strong overlaps? ?? how to respect the integrity of each theory vs to integrate theories as questioned by Mayer [START_REF] Mayer | Learners as information processors[END_REF] or Wasson [START_REF] Wasson | Instructional Planning and Contemporary Theories of Learning[END_REF]? ?? how to link theoretical to practical knowledge? ?? how to distinguish between domain and task ontologies and to link both in the case of an ontology-based ITS authoring system? ?? what kind of attributes can be given to things when these things are theories?

Cognitivist/constructivist? Validated/emergent? A very particular question was raised: what should be the status of instructional design knowledge, domain or task knowledge? The following section describes the exploration that was conducted based on Gibbons' view of instructional technology as a design science.

Gibbons' Exploration into Instructional Technology Knowledge

The issue of considering ID knowledge as domain knowledge or task knowledge is whether to build it into the domain or into the task ontology; considering it as science means engineering the ID knowledge under domain knowledge. For this reason, the work of Gibbons on Instructional Technology (IT) as a design science was given special attention. What is Instructional Technology? The Association for Educational Communications and Technology (AECT) states: "Instructional Technology is the theory and practice of design, development, utilization, management and evaluation of processes and resources for learning." (www.aect.org). IT is composed of two main components: Instructional Design and Instructional Development [START_REF] Seels | Instructional Technology: The Definition and Domains of the Field[END_REF]. Gibbons views IT as a design science in the sense of Simon [START_REF] Simon | The Sciences of the Artificial[END_REF], and attempts to relate theoretical knowledge to practical knowledge as done in the field of industrial design [START_REF] Gibbons | The Practice of Instructional Technology[END_REF]. Classes of technological knowledge are proposed: 1) Fundamental Design Concepts ( Operational Principle, Normal Configuration), 2) Criteria and Specifications, 3) Theoretical Tools, 4) Quantitative Data, 5) Practical Considerations, 6) Design Instrumentalities. As an example, a 'normal configuration' is defined as 'the general shape and arrangement that are commonly agreed to best embody the operational principle. Should these classes apply to IT Instructional design's operational principle could be: to build an instructional system that sustains and fosters the learning process, ensures the quality and the effectiveness of learning. This view has the potential to provide a framework for specifying IT knowledge, and stimulates reflection about the actual status of IT knowledge. For example, ID principles are defined as follows by Merrill [START_REF] Merrill | Instructional Design Theories[END_REF]: a) a principle is a relationship that is always true under appropriate conditions, b) fundamental principles for instructional design do exist, c) these design principles apply regardless of the instructional program or practices involved, d) violating them results in a decrement in learning and performance. Given this definition, ID principles could be considered as 'Operational principles' in the sense of Gibbons.

Further considerations relate to the basic principles of knowledge systematization as they apply to the systematization of theoretical knowledge, and of multiple theories for the same field.

Knowledge Systematization of Theoretical Knowledge

Knowledge systematization has been done for human consumption to date. The results have mainly been described in natural language in the form of a book or a paper. It might be no problem if humans learn them. But, it becomes a problem when we try to make computers understand and use the knowledge. Knowledge systematization for computer-consumption from engineering point of view should enable a seamless flow of knowledge from theoretical world to practical world.

Our systematization project is done not for the sake of theory but for using the theory. By this, we mean that theories should be interpreted from an engineering point of view. Engineering is heavily based on the requirements of practice. For example, a head of a company might want to train some specific competencies/skills such as creative thinking, reasoning in an abstract space, negotiation in sales activities, planning, presentation, etc. of employees who have various background and experiences from novice to expert. Because of the variety of learning goals (competencies and skills) and of the heterogeneity of learners, a variety of theories can help the learning process. For example, although situatedness has been claimed to be one of the most critical factors in successful learning, it is not always considered that way in training practice. Human Resource Development divisions have identified that a skill which is too much specialized for a specific situation or domain to be applied to many situations is not what they need. Instead, what they need are skills which prove to be effective in many situations, that is, competencies. Needless to say, they never want too abstract knowledge which is hard to apply to real world situations, but at the same time, they also dislike inflexible skills which apply only in a specific situation. Another example is social interaction. Some learning theorists claim that social interaction is the essence of learning process; however, for a company which wants to train their employees' reasoning capability in an abstract space or their motor skills, social interaction may seem of little importance.

In short, contrary to the claim of some learning theorists that "this is the only learning theory which explains the learning process", the fact that a variety of learning theories exist may be viewed in a positive way. There exists a variety of requirements for effective learning, and each of them needs a most suitable theory and needs to be interpreted in the terms used in the application domain. Having a collection of the existing theories in an authoring system also allows to respond to the preferences of the instructional designers/authors and of their clients. Moreover, it might prove to be a stimulus to a reflective process on the side of the designers/authors as they consider the potential and relevance of each theory and the compatibility among them, eventually resulting in an improved level of quality. For these reasons, useful characterization of each theory is what we need from an engineering point of view.

When the enterprise is knowledge systematization, the necessary characteristics that systematized knowledge is expected to have are the following: 1) Concepts found in all the knowledge are clearly defined, 2) Concepts are organized in a n is-a structure, 3) Dependencies and necessary relations among concepts are explicitly captured, 4) Each viewpoint used for structuring knowledge, if any, is made explicit, 5) Ready for multiple access, 6) Consistency is maintained. The above clearly shows that OE does contribute to the systematization of knowledge. Furthermore, when the user of the systematized knowledge is an engineer or a designer, which is our case, the set of viewpoints has to include practical points of view. One of our research goals is to make theories available for engineers and for designers/authors of ITSs.

Ontological Engineering, a Deconstructionist Approach

For an instructional scientist, OE starts with the deconstruction of the existing body of knowledge, both theoretical and practical. Although a risky enterprise, it is worth the journey. Needless to say, this restructuring process should not be considered a substitute to theory building. A simplified description of the OE process for Level 1 is: 1) Extract most essential concepts and most essential links among them; 2) Define them by their meaning, their attributes, and the semantic constraints on them. Ontological categories for a process are generally: actor (subject, thing which does actions), behaviour (verb, action, phenomena), object (thing being processed by actor), goal (state to be achieved), situation (context in which an action is done) and attributes (characteristics; of all of the above).

The first assumption is that "everything is concrete", and that concrete is defined as dimensioned by time and space.

The second assumption is that we have two kinds of worlds: 1) Concrete worlds (learning, instruction, instructional design) that we describe based upon the best possible approximation of what is existing, 2) Abstract worlds (learning, instruction, instructional design) where we reflect existing theories with the best possible fidelity. These are called Worlds of theories. The fourth assumption is that theories are "things" in the world of theories: 1) Theories of learning, of instruction, of instructional design, 2) Theories of knowledge (epistemologies) on which theories of learning rely, 3) The worlds of theories is part of the Domain Ontology.

Definitions of the theoretical knowledge considered are: 1) A theory of learning is a conceptual system to describe, explain, predict and study natural phenomena involved in the learning process, 2) A theory of instruction is a conceptual system to describe, explain, predict and study artificial activities for supporting, organizing, fostering, facilitating, accelerating or evaluating the learning process, 3) A theory of instructional design is a conceptual system to describe, explain, predict and study the design of artificial activities for supporting, organizing, fostering, facilitating, accelerating or evaluating the learning process. Figure 1 illustrates a view of how the three worlds of theories relate to the three concrete worlds.

One of the difficulties that we had in building ontologies of these theories is how to differentiate the relations and constraints contained in an ontology from those in the target theory, since an ontology itself is a theory of existence by definition and hence contains relations and/or constraints among objects just like a target theory is a set of relations/constraints among objects in the target world. We resolved this issue by giving each theory a primary identity with full relations/constraints it needs. Considering the fact that a theory tries to explain its target world we came up with a framework of our ontology building enterprise as shown in Fig. 2. It shows a nested structure of Learning, Instruction, and Instructional Design worlds. Each of the three kinds of theories explains processes/events which happen in each world. One of the major differences among the three kinds of processes/events is that while the lower two are real world processes/events, the other is a planning or design process. A theory needs to refer to objects existing in the target world when it tries to say something about them, which suggests that a theory may have its own set of objects, since any object in a theory is obtained according to the theory-specific articulation of the target world. In fact, a learning theory uses its own way of describing the learning process from its particular view. Each theory has its own viewpoint from which it views the target world. Although these distinctions are not perfect but questionable, they seem reasonable enough to serve the purpose of this work.

A tentative portrait of an ontology of instructional design was then sketched, following the steps recommended by the OE methodology for Level 1: a structured collection of terms, articulation of the world of interest, elicitation of concepts and of the is-a hierarchy among them.

Portraiting Domain and Task Ontologies of Instructional Design

A preliminary portrait of ID knowledge provides the main terms to be considered and how they can be structured. Three worlds compose the domain ontology, and two worlds the task ontologies. A structured collection of Fig. 2 A view of the three nested worlds. theories of learning and instruction is provided by Kearsley as an hypermedia base [START_REF] Kearsley | Explorations in Learning & Instruction: The Theory Into Practice Database[END_REF]. A view of learning theories from an ID perspective is found in Ertmer and Newby [START_REF] Ertmer | Behaviorism, cognitivism, constructivism: Comparing critical features from an instructional design perspective[END_REF]. How Learning Theories view Learning is inspired from Mayer [START_REF] Mayer | Learners as information processors[END_REF].

Instructional world

Learning theory

Learning world

Instructional

For the world of learning, the main concepts could be: learning activity, assignment, reading, interacting, problem-solving, learning phase, learning difficulties/remediation. For the world of theories of learning, the main concepts could be: theory of learning, epistemological ground, taxonomy, learning, motivation, attention, comprehension, memory, cognition, meta-cognition, learning phase, learning difficulties/remediation.

For the world of instruction, the main concepts could be: instruction, learning, instructional strategies, teaching, tutoring, assessment of learning. For the world of theories of instruction, the main concepts could be: theory of instruction, theory of learning, epistemological ground, taxonomy, learning, instructional strategies, teaching, tutoring, assessment of learning.

For the world of instructional design, the main concepts could be: instructional design, instruction, learning, instructional scenario, learning environment, selection of methods, selection of media, selection of assessment methods. For the world of theories of instructional design, the main concepts could be: theory of instructional design, theory of instruction, theory of learning, epistemological ground, taxonomy, learning, selection of methods, selection of media, selection of assessment methods.

As a conclusion to this preliminary portrait of knowledge relevant to the OE of ID knowledge, it is obviously too early to say whether these distinctions will reveal valuable; it is anticipated that a series of iterations may be needed before a satisfactory collection of terms is found.

Building these Ontologies into the Ontology Editor

The building of these ontologies into the Ontology Editor* fulfills the Level 1 of OE, and exposes the links and the hierarchy to constraint checking. Essentially, the building process consists, besides consolidating the terms and the hierarchy, in the specification of Is-a and Part-of relationships for each term. Generate and test is the preferred method, until a reasonable structure is obtained, and until all the constraints are fully respected. Another ontological category to be considered is role, as it proved to be a quite useful one in our case: a) Instructional designer is a role (agent of design), with, as sub-roles, analyst of learning contents, of learners' characteristics, of learning context; designer of scenarios, of learning environments; developer of learning environments; collaborator with other designers, etc. b) Instructor is a role (agent of instruction), with, as sub-roles, information presenter; discussion moderator; asking questions/answering questions; asking for/giving explanation; solving problems; collaborate; assess learning; game master; organizing lab experiment/field experiment; organize simulation/role play, etc. c) Learner is a role (agent of learning), with, as sub-roles, asking/answering questions; asking for/giving explanation; solve problems; play simulation games; make assignments; pass examinations; self-manage learn ing; self-assess learning, etc.

An extract of the building within the Ontology Editor is shown in Fig. 3.

Further Work

The work towards a Level 1 of the ontology needs to be completed, in that the collection of terms must be stabilized, the hierarchy also needs to be stabilized, the relations need to be completed and refined, the definitions need to be completed, the semantic constraints need to be fully checked. A series of iterations is expected to be necessary to obtain a satisfactory Level 1.

Further steps on our roadmap include: 1) Produce two detailed examples. Based on the assumption that "everything is concrete", and that "concrete" means 'dimensioned by time and space", we plan to illustrate this idea with two concrete examples, specified within the Ontology Editor: Learner-Instructor interaction (what is it made of? Specify components and roles), Scenario building (what is it made of? Scenarize the desired functionalities).

2) Elaborate functionalities of an ontology-based ITS authoring system. The functionalities of such a system can be: Intelligent theory retriever, Intelligent navigator based on theories, Advisor to form an appropriate collaborative learning group, etc. Steps towards the identification of these functionalities are: 1) imagine what users can do with an ontology-aware authoring environment, 2) specify new functionalities, 3) build a scenario-based demo of functionalities, 4) test mockup and validate with users.

A long term perspective for this work is to provide the next generation of authoring systems with a scientific basis for semantic standards of learning objects and their management.

Concluding Remarks

We have presented a work in progress in AIED research that aims at -ontologyawareness for future ITS authoring systems. Collaborative ontological engineering of ID knowledge has been described, followed by the first results on a road map towards an ontology-aware authoring system.

The implications of " ontology-awareness" are meaningful, not only for AIED research into system building but also for knowledge sharing between humans and computers. OE enables humans to share theories with computers, and stimulates the quest for a consensus among humans. If a n ontology represents a shared conceptualization in a community, OE has the potential to contribute to the building of such a conceptualization.

Discussions about the hierarchical nature of ontologies can help find general concepts by going up the hierarchy. The is-a and part-of hierarchies help humans in finding the essential differences between them. The first results described above represent a possible shared conceptualization. It may be far from complete, but it should provide a good start to come up with a richer agreement. *The Ontology Editor was developed at Mizlab, Osaka University (http://www.ei.sanken.osaka-u.ac.jp/oe/oe.html).

Fig. 1

 1 Fig. 1 Abstract and concrete worlds and how they relate to each other.

Figure 3 .

 3 Figure 3. Extract of the ontology built within the Ontology Editor


Matteo Gaeta
email: gaeta@diima.unisa.it

Nicola Capuano

Angelo Gaeta

Francesco Orciuoli
email: orciuoli@crmpa.unisa.it

Laura Pappacena

Pierluigi Ritrovato

DIOGENE: A service Oriented Virtual Organisation for e-Learning

Keywords: Virtual Organisations, Web services, GRID, Learning services

In this paper we present the main results of the DIOGENE project where the characteristics of Virtual Organisation for providing learning services has been identified and implemented using state of the art Web Services technologies. Moreover, we present, a possible migration path towards the Grid emphasising the advantages coming from the adoption of this technology.

INTRODUCTION

Virtual Organizations (VO) can be defined as a coordinated group of individuals and/or institutions who collaborate for a common interest and share, on the basis of some policies, a set of resources (processors, instruments, data and services). The element that characterizes the participants of a VO is the common purpose or business goal. The participants of a VO share resources and establish sharing rules in order to obtain a common objective. Members of a VO can be geographically distributed and can access to the resources any time they are allowed.

In order to realize a VO, many problems must be resolved. In fact, the VO is a dynamic environment, in which resources and/or individuals can join or resign in dynamic way. The resources are heterogeneous, distributed and shared. The resource sharing must be controlled from a set of rules that guarantee security, through mechanisms of authentication and authorization. The resources must be monitored in real time, since their state change quickly. The VO is a highly scalable environment, so it needs mechanisms for the discovery of the single resources. In brief, for being accessible and usable any time and any place technology solutions are crucial elements.

Among the technologies available for the realization of a VO, the Web service and the Grid ones offer many advantages. They are open and provide mechanism to address the aforementioned issues. A key factor for the realization of a VO is the adoption of technologies based on industrial standards. For example, VO paradigm is applicable inside the boundaries of an organization structure (a intra-organization view) and across organization boundaries (a extra-organization view) but, currently, only Web Service and/or Grid technologies allows the realization of the second view.

The following sections present the Diogene VO, which is a Web Service based VO for learning experience. We will present the major components of this VO and will describe a possible deploy of the Diogene VO in a Grid infrastructure. Finally as future work we also describe some interesting features of the upcoming Microsoft operating system, code name Longhorn, which provides an innovative file system and communication infrastructure very useful for development of semantic and collaboration based applications.

THE DIOGENE VIRTUAL ORGANISATION

Diogene [START_REF]Diogene: a Training Web Broker for ICT Professionals[END_REF] is an EC funded project aimed to design, implement and evaluate with real users an e-learning Web brokering environment for ICT individual training able to support learners during the whole cycle of the training, from the definition of objectives to the assessment of results through the construction of custom courses.

The e-learning system that is under development in the frame of the Diogene project uses state-of-the-art technologies like metadata and ontologies for knowledge representation and management, fuzzy learner modelling, intelligent course tailoring and includes a set of innovative features like dynamic learning strategies, Semantic Web openness, Web services for Learning Objects handling and IPR management, Curriculum Vitae maintenance and searching facilities, free-lance teachers support and assisted Learning Objectives definition [START_REF] Capuano | An e-Learning Platform for SME Manager Upgrade and its Evolution Toward a Distributed Training Environment[END_REF].

The Diogene scenario is modelled as a Virtual Organisation (VO) strongly based on the use of Web Services. The Diogene VO is populated by entities offering and consuming services. Such entities are grouped in four categories: users (humans that provide and consume services), organizations (physical entities that as software components provide and consume services), utility components (software components embedding the technology assuring the architecture integrity) and accessor components (software components providing the access from outside to the Diogene VO and from the Diogene VO to outside).

Diogene Users

Diogene Users can be grouped in the following main categories (it is important to note that the same physical user can play different roles in Diogene so it can belong to more of these categories).

Learner: is a student registered in the Diogene VO. He/she acquires knowledge through learning experiences provided by Diogene specific learning services.

Expert Learner: is a Learner skilled about some topics. He/she can offer mentoring support to other learners about such topics usually for free.

Freelance Tutor: is a professional tutor offering his/her specialized mentoring support to learners about specific topics usually under the payment of some price.

Skill Searcher is an enterprise manager interested in hiring certified staff. He/she performs queries on skill repositories.

Diogene includes further sets of users like Content Providers, Knowledge Managers and Administrators that, to improve simplicity and clearness, are not discussed in this paper.

Diogene Organisations

Organizations of different type offer services with respect to the specifications of the Diogene VO and collaborate for the realisation of their own services. The kind of organisations supported by Diogene are summarised in the following list.

Publishing Houses (PH). They store training content and provide remote access to it. They provide search and retrieval functions on the local repository via metadata-based queries. (WA). They are able to extract training content directly from Web and Semantic Web. Through a keyword-based text categorisation algorithm they are able, where absent, to automatically extract metadata from textual learning objects ad to link them to structures maintained by the KA.

Web Catcher Agencies

Tutor Agencies (TG). They work as entry point for freelance tutors, they manage the freelance tutor archive (containing tutor models) and provide searching facilities on such archive.

Brokerage Offices (BO). They research, prepare and provide training offers for learners on demand, based on customisation information (learner model, learning strategies, price, learning goals). They collaborates with PH and WA in order to retrieve didactical material that best fit the customisation requests. They collaborate with TG to retrieve and provide freelance tutors that best fit learner needs.

Training Agencies (TA). They provide the basic environment for learning experiences and tutoring activities. They are responsible for the delivery of courses and for the provision of course management and execution functions. They maintain learner models and are able to provide (on demand) course offers by exploiting services offered by BO.

Knowledge Agencies (KA). They maintain and manage knowledge structures (concept dictionaries and ontologies) for the whole Diogene Network. Café (CA). They support social interactions, mentoring and information exchange by providing users a set of collaborative synchronous and asynchronous facilities. They are able to automatically arrange groups among users of registered TA by individuating and grouping learners with similar needs and/or profiles.

Skill Agencies (SA). They provide search engine capabilities on Learner Models Databases of registered TA in order to let third parties interested to hire certified staff to find qualified professional (with respect to privacy requirements). They maintain, moreover, statistics of requests in order to rank required competencies. Bank (BA). It's a singleton organisation that executes and logs transactions information occurred inside the Diogene VO. It interacts with an e-commerce engine to execute transactions involving real payment processes.

More instances of the same Organisations live inside the VO. The various instances stand on different hosts and are managed (administered) by different users. Figure 1 depicts some interactions between Diogene organisations.

Following the principles of the Convergent Architecture [START_REF] Hubert | Convergent Architecture, Building Model-Driven J2EE Systems with UML[END_REF], Diogene Organizations can manage Processes, Resources and other Organizations. Resources live encapsulated within the Organizations and collaborate with them to accomplish their own tasks. Resources can also be used as containers for the information exchanged between organisations. Resources can manage its own data and other Resources.

Processes express and are realised by the collaboration between Organisations or by the collaboration between Organisations and internal Resources. Processes can create and consume/use Resources and can use other Processes.

Utility and Accessor Components

Utility Components have no business-domain relevance but embed the technologies that explicitly assure the Architecture integrity. The Diogene VO includes the following two singleton components.

Authentication Agency: it provides all services for the registration and authentication of users of the whole Diogene VO. After authentication, it releases a token that must be used as a ticket to access and be authenticated in all VO services.

Diogene Services Registry: it includes Diogene White Pages (containing information about services offered by organisations), Yellow Pages (organizing services in categories) and Green Pages (including information about how to execute services).

Accessor Components provide the access to the Diogene VO services and also the access through the Diogene VO components to external services. The only Accessor Component of the Diogene VO is the following.

Diogene Network Reception: the Internet entry point for all Diogene users. It provided features of user and organisation registration, it publishes characteristics and services offered by the Diogene VO, it provides administration features for the Services Registry.

Some Orchestrated Scenarios

In a first scenario, a Learner asks for a personalized training offer to his/her Training Agency(1) through its entry point (Training Agency web portal), starting from a concepts list that he/she wants to learn (Target Concepts). Training Agency calls the Knowledge Agency(2) passing to it the target concepts in order to build the learning path, it will be composed by all concepts necessaries to the learner to reach the target concepts. Knowledge Agency builds the learning path using the owned knowledge structure, ontology and concepts dictionary, and the learner acquired knowledge. Once the learning path is ready and fixed the best learning strategies for the learner the Training Agency calls the Brokerage Office(3) of the Diogene Virtual Organization in order to obtains the training offers to propose to the

ANATOMY OF THE ABSTRACT ORGANISATION

Organisations within the Diogene VO are seen as service providers. Therefore the VO is constituted by a set of cooperating services that give tangible results to the users through the available access points (web portals). Then Organizations live inside Internet and offer their services as Web-Services, they live inside a Web Server and are visible through a Web Portal.

Abstract Organisation Components

Each Organization included in Diogene VO has the same core infrastructure: the Diogene Abstract Organisation (DAO) shown in Figure 2. Main DAO elements are described below.

Ports are access points to particular services of an Organisation. Each service has to exhibit: a Notification Source Port (displaying an interface for those who want obtain a particular service) a Notification Sink Port (receiving the notification of the results of the required service) and a Notification Subscription Port (serving for the subscriber to manage in a source service the subscription to a particular service). Ports offer a general schema for a publish and subscribe pattern.

Service interfaces. To expose business logic as a service, it's necessaries create service interfaces that support the communication contracts (message-based communication, formats, protocols, security, exceptions, and so on) that different consumers require. Service interfaces are sometimes referred to as business facades. Organizations will use Façade Pattern in order to collect services invocations and dispatch calls to processes at the second layer. The business façade object authenticates and authorizes. Then façade invokes a Workflow that performs the business. The Façade Pattern provides an unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.

Workflows. Workflows define and coordinate long-running, multi-step business processes. Workflows could be wrapped in specific components that can be managed by an Application Server like COM+ in order to handle transactions.

Components. Regardless of whether a business process consists of a single step or an orchestrated workflow, your application will probably require components that implement business rules and perform business tasks. Components implement the application business logic and can be managed in an Application Server like COM+ to handle object pooling.

Entities. Applications require data to be exchanged between components. The business entities that are used internally in the application are usually data structures that wrap DataSets, DataReaders, or XML streams, but they can also be implemented using custom object-oriented classes that represent the real-world entities the application has to work with.

Service Agents. When a Component needs to use functionality provided in an external service, it is necessary to provide some code to manage the semantics of communicating with that particular service. Service agents DALC (Data Access Logic Components). Most applications and services need to access a data store at some point during a business process. DAL Components provide a standard and abstract way for accessing to the storage systems.

Some Technological Details

The Diogene Virtual Organization lives into Internet environment. Organizations expose their services as Web Services described by the WSDL standard. Actually, we think that Web Services choice is the best one for distributed environment because they are based on standards like SOAP, HTTP (protocol) and XML (metalanguage for message describing) that encourage interoperability. The DAO will be implemented using Micorosft Security Token will travel across the Diogene Network (from a service to another one) embedded in a SOAP message. In order to achieve a consistent Token passing across the Diogene Network we will use WS-Security. WS-Security is a piece of GXA specifications that describes how to attach signature and encryption headers to SOAP messages. In addition, it describes how to attach security tokens, including binary security tokens such as X.509 certificates and Kerberos tickets, to messages.

For the implementation of Diogene Services Registry we used the known UDDI (Universal Description, Discovery and Integration protocol) technology that is one of the major building blocks required for successful Web services. UDDI creates a standard interoperable platform that enables companies and applications to quickly, easily, and dynamically find and use Web services over the Internet.

UDDI also allows operational registries to be maintained for different purposes in different contexts. The UDDI project takes advantage of World Wide Web Consortium (W3C) and Internet Engineering Task Force (IETF) standards such as Extensible Markup Language (XML), and HTTP and Domain Name System (DNS) protocols.

Additionally, cross platform programming features are addressed by adopting early versions of the proposed Simple Object Access Protocol (SOAP) known as XML Protocol messaging specifications found at the W3C Web site. The UDDI protocol is the building block that will enable businesses to quickly, easily and dynamically find and transact with one another using their preferred applications.

MIGRATING TOWARD A GRID INFRASTRUCTURE

Among the technologies enabling the VO, the Grid ones are taking a leading role. The Grid computing, thought as the evolution of metacomputing, addresses issues related to access provisioning, coordinated resource sharing and problem solving in dynamic, multi institutional VO [START_REF] Foster | The Anatomy Of The Grid[END_REF]. This sharing capability and support for VO implementation has been one of the main key success factors of Grid as enabling technology for e-science infrastructure. The new research directions for the development of Grid technologies are moving towards a service oriented view by the definition of the Open Grid Service Architecture (OGSA) [START_REF] Foster | The Physiology Of The Grid[END_REF] that, joining Web Service and Grid technologies, defines an open and extensible framework for distributed and highly collaborative applications.

The Diogene model can become, in simple and feasible way, a Grid-Aware model. It presents several Grid features: it is strongly based on the use of open and standard based technologies and it adopts the VO model. Furthermore, it provides, as Utility Components, a single sign on authentication mechanism to access the VO services and a Service Registry. But it has some drawbacks that, using OGSA complaint technologies instead of the web service ones, can be easily addressed in order to enhance it.

OGSA is strongly based on the service orientation and virtualization, where the first is related to definition of a uniform exposed service semantic and the identification of protocols that can be used to invoke a particular interface, and the second is related to the encapsulation behind a common interface of diverse implementation, so everything (Resources, Learning Objects and so on) in this environment is a service.

Currently, Diogene doesn't take care of (Physical) Resource Management issues. The VOs are composed by heterogeneous and distributed resources and there must be a standard way in order to manage these remote resources. Local Organizations may use a wide variety of management mechanisms (schedulers, queuing systems, reservation systems, and control interfaces), but a client need to learn how to use only one mechanism to request and use these resources.

In a Diogene VO, the Organizations are seen as service providers but there is no agreement between a provider and a client on the service level guarantee. Organizations provide services "as they can", they collaborate between them but they use only the resources of the host where their instances run. Organizations have not a full vision of all the resources of the VO, so they are not able to promise a level of QoS. Moreover, the Diogene Services Registry is a single centralized component: it maintains only static information about the services and organizes services in categories. There isn't information about the physical resources and it hasn't mechanisms to store dynamic information related to the status of the VO resources (e.g. available memory, CPU usage and so on). The VOs are dynamic, resources in a VO join and resign and their status change quickly; so it is necessary to enhance and distribute it, to avoid bottlenecks, the Diogene Service Registry.

In order to shift Diogene towards a Grid Service Oriented infrastructure, the Organizations should act as distributed Grid Service Providers (GSP). They should provide OGSA compliant services (e.g. Grid Services [START_REF] Foster | Open Grid Service Infrastructure V1.0[END_REF] or WS-Resource

DAO Grid-Aware.

The figure 3 shows a the Grid-Aware version of the Diogene Abstract Organisation. The Organizations provide OGSA compliant services. The service interface exposes the business logic and extends the notification pattern, as described in [START_REF] Foster | Open Grid Service Infrastructure V1.0[END_REF]. A DAO Grid-Aware doesn't need the Ports, as they are described in the section 3.1. Indeed, they are directly available through the OGSA GRID services.

Organizations provide complex services obtained by composition and coordination of simple services. Workflows, in this Grid-Aware model, are BPEL4WS [10] scripts enhanced with metadata in order to manage the Grid features (e.g. lifetime management) of the services to compose. Each organization has a BPEL enhanced engine able to parse the enhanced scripts and execute the workflow. This engine is exposed as OGSA service and accessible, by the service interface, in a standard way.

Each Organization has a Component called "MDS Component", which is functionally equivalent to a Grid Resource Information Service (GRIS) [START_REF] Foster | The Anatomy Of The Grid[END_REF]. It maintains information about the service/s provided by the Organization and the resources of the Organization and it has the capabilities to monitor the resources in order to obtain updated information about their status. In the Grid-Aware DAO Components, we find the Business Components that implement business rules and perform business tasks, a QoS Component that performs the mapping between high level figures of QoS (e.g. Time response) and low level figures (e.g. Required memory, Bandwidth) that can be monitored and measured and a Resource Manager (RM) Component that implements logic to manage the local resources and exposes a standard interface.

The Organizations are GSPs but, by the other side, they take the role of clients when they negotiate or use services provided by other Organizations, so there is another interface (in figure 3 it is called "OGSA Compliant Client Interface") that allows an Organization to interact with other members of the VO. The communication with external services happens with this standard interface and it isn't needed the Service Agent.

A simple scenario.

To clarify the ideas, we explain a simple and not exhaustive scenario. In order to realize a real business scenario, the VO needs new Utility Components, besides the ones described in the sections 2.3. The first is the Resource Manager Utility (RMU), which is able to manage VO resources (virtualized as services) on demand based on the VO policies. The RMU has a complete vision of all the resources of the VO. The other Utility Components are a Negotiator (N), which provides negotiation facilities between a client (maybe a user or another Organization) and a "VO MDS". This last is equivalent to the Grid Index Information Service (GIIS) [START_REF] Foster | The Anatomy Of The Grid[END_REF] and it maintains information about the services provided by the VO and information about the resources of the VO (e.g. status, access policies and so on) It interfaces itself with the "MDS Component" of the Organizations in order to obtain and index the information about resources and services.

Referring to figure 4, a learner registered in the Diogene VO asks for a training session and he, through the Accessor Component, performs a query against the VO MDS (1). He obtains a list of services provided by different Organizations inside the VO. He decides to gain experience in the business field and to play with a Business Game, but he provide some visualisation constrains (he ask for 3D representations of business game data) so he requires narrowing requirements on the visualisation an performance of the service. Through the Accessor Component, he negotiates with the Negotiator Utility (2) the QoS for the required service in a transparent way. The Negotiator interacts with TA Organization (3), which starts a simple workflow. The first operation is to map the constrains required with the resource requirements needed to satisfy it. The QoS Component performs this task. Obtained the results, the second step is to query the VO MDS (4) to obtain a list of available resources and/or services of the VO that are able to satisfy the requirements, obviously on the basis of the current status. Once the TA has the list of the available resources, it contacts the RMU of the VO [START_REF] Foster | The Physiology Of The Grid[END_REF]. The RMU asks the RM Components of the Organizations, which are able to provide the resources required, the reservation of the resources (in the figure, we suppose that all the necessary resources can be provided by the BO, WA and PH Organizations and this operation is shown with the dashed lines). At the end, a SLA is caught up and returned to the learner.

The other steps, from (6) to [START_REF] De Roure | The Semantic Grid: A Future e-Science Infrastructure[END_REF] in figure 4, are equivalent to the first scenario presented in section 2.4 and the BO prepares and provides the business training offer for the learner based on the obtained SLA and other customised information. We suppose that the Diogene Bank Organization is able to perform a "pay per use" mechanism also on the resource usage. We haven't discussed the Accounting/Billing and SLA Monitoring issues for simplicity.

Another more complex scenario is the following, which emphasizes the features of a collaborative and experiential based learning model. Referring to Figure 5, we have a freelance tutor who wants to offer support to a group of learners. The step (1) and ( 2) are the same of the second scenario described in section 2.4. Furthermore, an added value of the Grid technologies is the capabilities to provide collaborative features creating a group and inviting some learners, with common needs and similar skills, to join a collaborative learning session Tutor can accesses the Café organization (3) providing some target concepts and he relies upon the collaborative features of the organization to provide highly realistic virtual scientific experiments. Café asks Brokerage Office to prepare and define, interacting with other organizations, a standard didactical model for the achievement and representation of such experiments. The learners belonging to the Group can access to the virtual experiment and interacts with it, using a group Accessor Component that interacts with the Café organization. In this type of model, a learner is immersed in a specific context, which, through appropriate simulations, develops active learning processes with progressive abstraction levels, leading to the construction of knowledge in a dynamic way. In this learning model, the student can also receive the support of other users (collaborative aspects) and, through the comparison with them, they can build a new "mediated" knowledge.

CONCLUSIONS AND FUTURE WORKS

In this paper we have presented a Service oriented VO for E-Learning. We have described the Diogene model placing particular emphasis on the interactions between the different members of Diogene VO in order to provide training services. Furthermore, we have showed some ideas in order to deploy the Diogene model in an OGSA complaint infrastructure, emphasising the benefits that the Diogene architecture could have from the adoption of GRID technology and in particular OGSA.

Our future work will be mainly focused on two key aspects: The implementation of GRID-aware version of DAO and the evaluation of the deployment over the new Microsoft Operating System code named Longhorn. Concerning the implementation of the Grid-aware version of the DAO we plan to use the middleware under development in the GRASP -GRID based Application Service Provision project taking into account the new development in the GRID domain concerning the WSRF (Web Services Resource Framework). Indeed, Grid community, for the motivations described in [START_REF] Foster | From Open Grid Service Infrastructure to WS-Resource Framework: Refactoring & Evolution[END_REF], is refactoring the Open Grid Service Infrastructure [START_REF] Foster | Open Grid Service Infrastructure V1.0[END_REF] in terms of web services specifications and technologies. The WSRF is based on the concept of WS-Resource, which is a stateful resource that participates in the implied resource pattern [START_REF] Foster | Modelling Stateful Resources With Web Services[END_REF]. The pattern is codified using existing web service technologies, as XML, WSDL and WS-Addressing.

on the other side we will investigate how to deploy the Grid-aware version of the Diogene DAO using the new Microsoft Operating System. Longhorn, represents the first operating system built with managed code (i.e. .NET code completely compiled into Intermediate Language to be executed inside a CLR). Longhorn presents three key innovations for Presentation Layer, for Data Layer and for Communications Layer. All these layers provide their functionalities in terms of Web Services.

For the Presentation Layer, Longhorn introduced Avalon Subsystem [13] representing a significant evolution of presentation technology with the goal of allowing developers to easily build rich and compelling user interfaces that can seamlessly integrate high-quality document and multimedia cointent.

For Data Layer, WinFS Subsystem [12] has been introduced. WinFS is the name of the new file system that provides data and storage model for "Longhorn" and has been introduced in order to simplify the process of finding and storing user data.

Indigo Subsystem has been released to fill the Communications Layer. Indigo is a set of technologies for developing connected applications on the Windows platform. It provides a complete and flexible messaging platform independent of network topology. With Indigo, developers can write applications on a simple yet powerful programming framework.

Furthermore, Longhorn exposes a set of comprehensive API, called WinFX, for writing Longhorn-based applications. WinFX APIs are entirely available in managed code.

In this frame our effort will be devoted to investigate how to extend Longhorn layers and in particular WinFS and Indigo in order to integrate the WSRF specifications. Both Indigo and WinFS provide a broad array of distributed systems capabilities in a composable and extensible architecture, spanning from data access, indexing, search and retrieval to transports, security systems, messaging patterns, encodings, network topologies and hosting models. In this way a developer can rely on an OGSA compliant infrastructure "embedded" in the operating system.

FIGURE 1 .

 1 FIGURE 1. Interactions among Diogene Organisations.

FIGURE 2

 2 FIGURE 2. Diogene AbstractOrganisation.

  [START_REF] Foster | Modelling Stateful Resources With Web Services[END_REF]) to clients. Organizations can share physical resources between them on the basis of VO business and security policies. They manage their own resources and they should be able to use and/or buy external resources from other Organizations. Furthermore, the Utility Components become OGSA compliant services. They are accessible, in a standard way, from internal Organizations and external users. The Diogene Services Registry has to be modified to become an OGSA compliant Monitoring and Discovery Service (MDS) [8].

FIGURE 3 .

 3 FIGURE 3. DAO Grid-Aware.

9 FIGURE 4 .

 94 FIGURE 4. Diogene VO.

FIGURE 5 .

 5 FIGURE 5. Collaborative scenario.

  Each Brokerage Office starting from the data received by Training Agency (learning path, learning strategies, learner model, etc..) will prepare a own training offer. To do this the Brokerage Office calls the Publishing House(4) and the WebCatcher Agency(4) asking them to provide the list (list entry are the metadata that describe the single Learning Object, included the price) of available material, that best fit the Training Agency requirement.

	In a second scenario, a Freelance Tutor
	accesses through Tutor Agency (1) to his/her
	jobs list and clicking on a specific job she/he
	can be redirected to a specific Training
	Agency (2). The Training Agency offers a
	tutoring environment where the tutor can control
	learner activities, status, profile, results and
	progresses. Training Agency offers also an
	entry point for the Café(3) where tutor can meet
	his learners and collaborate and communicate
	with them.

  .NET technologies. Ports are Web Methods exposed as Web Services. Workflows and Components they will live in COM+ Application Server in order to take advantage from enterprise services of this environment like the Transactions management, Object Pooling management, etc… For the running and tracing of the workflows we have also used Microsoft MSMQ. Entities are simple light weight Microsoft.NET components that we have modelled using ValueObject design pattern. They are used to transport simple or complex information through the different levels of the layered architecture. DALC builds a component layer that is used to abstract from communication with storage systems.Authentication services have been developed ex novo and have been released as a Utility Component called Authentication Agency. Services provided by Authentication Agency are: User registration, User authentication and Validity check of Security Token. Security Token is a representation of security-related information (e.g. X.509 certificate, Kerberos tickets and authenticators, mobile device security tokens from SIM cards, username, etc.).


Nicola Capuano
email: capuano@crmpa.unisa.it

Angelo Gaeta
email: agaeta@crmpa.unisa.it

Giuseppe Laria
email: laria@crmpa.unisa.it

Francesco Orciuoli
email: orciuoli@crmpa.unisa.it

Ritrovato Pierluigi
email: ritrovato@crmpa.unisa.it

Crmpa

How To Use GRID Technology for Building the Next Generation Learning Environments

Grid technologies promise to improve the way we think about e-learning allowing wide-scale learning resources sharing in heterogeneous and geographically distributed environments consenting, in this way, the implementation of distributed learning spaces where different organizations and individuals are able to cooperate in pursuing similar and complementary learning and training objectives. But is the e-learning ready for this evolution? In this paper we try, starting from an existing e-learning platform named IWT, to sketch a possible migration path toward a Grid based environment. IWT was selected because it presents a flexible, service-oriented, layered architecture suitable for migration in an OGSA compliant environment. The new approach will provide more flexibility, in fact, it will possible to leverage on the resources distributed across the Grid in order to build the learning experience that best fit student requirements. A use case scenario is also provided in order to emphasize differences between the two approaches. After a brief introduction of Grid and Learning technologies (section 1), a brief summary of IWT is given and the execution scenario is shown (section 2). A possible OGSA-based deployment of IWT is then sketched together with the new version of the execution scenario (section 3). Some conclusions are, then, presented (section 4). How to use GRID Technology for Building the Next Generation Learning Environments 2nd International LeGE-WG Workshop on e-Learning and Grid Technologies : a fundamental challenge for Europe 8

INTRODUCTION

Grid and learning technologies were born to solve different issues in different domains. The first, thought as the evolution of metacomputing, address issues related to access provisioning, coordinated resource sharing and problem solving in dynamic, multi institutional virtual organization [START_REF] Foster | The Anatomy of the Grid[END_REF]. This "sharing capability" is highly controlled, with resource providers and resource consumers defining what is shared, who is allowed to share and what are the conditions under whose sharing is allowed, based on resource management and security policies.

Learning technologies instead are tied to the binomial instruction/learning and how it is changed due to the explosive increase of the web and the web technologies. E-Learning refers to learning that is delivered or enabled via electronic technologies such as internet, television, videotape, intelligent tutoring system and computer-based training. This model of instruction/learning has many advantages with respect to classical models:

a better interaction between the learner and the learning resources he uses i.e. the learning is not passive; learning can happen anytime and anyplace i.e. there are not boundaries tied to time and place; a tutor, or the learner himself, is able to monitor the progress and to customize the learning experience basing on learner skills and preferences.

But actually there are some drawbacks related to current learning solutions. First of all they are mainly focused on the content delivery, leaving in the background the collaborative view. This is also due to the implementation of distance learning platform themselves, in which existing learning objects are platform-dependent and cannot be used outside the system. This makes more complicated the collaboration between actors of different systems. Furthermore, current learning platforms only support a specific learning-domain and are not able to support learning in different domains.

Here, but not limited to these issues, is where Grid technologies can help. Through the adoption of these technologies it is possible a wide-scale learning resource sharing in heterogeneous and geographically distributed environments, the implementation of learning organizations in which different actors (universities, teachers, learners), sharing a common target, are able to cooperate to obtain a result.

Grid technologies are now moving towards a service oriented view by the definition of the Open Grid Service Architecture (OGSA) [START_REF] Foster | The physiology of the Grid[END_REF] that, joining Web Service and Grid technologies, defines an open and extensible framework for distributed and highly collaborative applications. This is done through the definition of Grid Services, an extension to standard Web Services able to manage lifetime and to permit introspection of the service itself [START_REF] Foster | Grid Service Specification draft 05[END_REF]. This could be the missing link in order to obtain an interactive, open and collaborative environment for distance learning build upon emerging network technologies and upcoming standards, open to the integration of third party solutions and/or services.

This paper presents a possible architecture suitable for a learning grid obtained as reengineering of an already existing traditional e-learning platform named IWT.

THE INTELLIGENT WEB TEACHER PLATFORM

Intelligent Web Teacher (IWT) is a distance learning platform realized by CRMPA in order to fill up the lack of support for flexibility and extensibility in existing e-learning systems. IWT provides flexibility and extensibility characteristics for contents and services at a low level and for strategies and models at an higher level. Furthermore, IWT platform provides user-tailored didactic experiences based on user preferences and competences in order to offer personalized learning. IWT arises from the consideration that every didactic/formative context requires its own specific e-learning solution. It is not thinkable to use the same application for teaching, for instance, foreign languages at primary schools and mathematical analysis at universities. It should be not only the content to vary but also its didactic model, the typology of the formative modules to be used, the application layout and, also, all the tools connected. In practice, the need to introduce the e-learning in a new didactic/formative context brings to hard work for analysts, engineers and programmers. IWT solves this problem with a really innovative solution (at the level of technologies and of methodologies) modular and extensible so to become the foundation for building up a virtually infinite set of applications for either traditional or innovative e-learning. In the next paragraph, we want to go deeper in the details of IWT platform showing its logical architecture.

IWT Architecture

IWT logical architecture is divided in four main layers as presented in figure 1.

The first layer at the bottom of the stack is the Data Layer that provides a way to store persistent objects as learning resources, user account information, resource indexes, etc. This layer is composed by two storage mechanisms, the first, named Object Repository, provides to each accounted user a space for storing information and data (i.e. a Web file system). Single user can create folders and upload or download files in their folders, can create learning resources (formed by a content and a metadata [START_REF][END_REF]) directly in his/her piece of repository. The second storage mechanism, named IWT DB, is a relational database, that maintains data related to user account, user groups and indexing structures (metadata) used for efficiently retrieve learning material stored in the Object Repository.

The second layer of the stack is the Infrastructure Layer that provides Base Services towards higher layers and provides also the capability to extend the services set with Other Services. Base Services are exposed as API (Application Program Interface) instead, we can add new services installing some modules called plug-ins and plug-in drivers. Typical Base Services provided by the Infrastructure Layer include, but they are not limited to, Account & Group Services; File System Services providing an high level view of the Object Repository; Resource & Permission Services handling permissions over objects stored in the IWT data layer; Knowledge & Metadata Services providing a metadata-based searching and indexing engine for learning material in Object Repository; Driver Services providing a set of functionalities for driver handling.

The Other Services in IWT are represented by plug-ins. A Plug-In is an additional module installed in IWT platform in order to provide new services (domain independent or domain specific) to higher layer of IWT architecture. There are internal plug-ins and external plug-ins, the latter need a standard interface called plug-in driver for their integration with IWT. As examples of plug-ins we want to mention:

-Student Model Plug-In (internal plug-in) is a module that allows learner profile handling; -Ontology Plug-In (internal plug-in) is a module that allows to structure knowledge about a specific domain using ontologies [START_REF] Fensel | Ontologies: a Silver Bullet for Knowledge Management and Electronic Commerce[END_REF] The highest layer in the stack is Application Layer in which we find the specific applications we want to realize on the IWT platform.

As said before, IWT has an highly modular platform. Due to its characteristics of flexibility and extensibility, it is fit for migrating towards a grid environment and, in our vision, it could represent the core middleware enabling the creation of the learning Grid. Before to describe how to modify the IWT platform in order to make it GRID-aware we want to illustrate a typical IWT scenario.

Delivery of a Didactic Course Scenario

In this paragraph we want to describe and analyse the main execution flow of a typical application developed using the IWT environment, namely the "Delivery of a Didactic Course". For a better understanding of the scenario it is fundamental the introduction of the following key abstractions:

-Concept is a significant property in a particular domain i.e. "limit" is a concept in the domain of "mathematical analysis"; -Ontology represents a way to structure knowledge of a specific domain, they can be thought as graphs in which nodes are concepts and arcs are relations between concepts; -Target Concept is an objective fixed by a teacher for a didactic experience;

-Learning Object is a minimal unit of didactic material, the rendering of one or more learning objects represent a didactic experience, a learning object has to be described by a metadata; -Metadata is a standard set of data used in order to describe in a consistent way a resource, metadata links learning objects to concepts covered by them; -Student Model is a profile composed by account information, learner preferences and competences; -Didactic Course Specification is the set of specifications provided by a teacher to assemble a didactic experience, a reference to an ontology and a set of target concepts to assemble a course are needed; -Didactic Course Presentation is the list of learning objects that realize the didactic course described in a Didactic Course Specification. Now, we can move to the description of the execution flow and software modules involved in the "Delivery of a Didactic Course". Student Bob decides to access a didactic course, so he interacts with Course Manager Application to obtain a didactic course catalog and selects the course A. Course Manager Application asks for an instance of a suitable driver to manage the selected course A (see figure 2).

The Course Manager Application can ask to the obtained course driver instance for the delivery of course A. The course driver instance asks the Driver Services to get an instance of a LIA Plug-In Driver (i.e. the wrapper used to manage the ITS engine called LIA). LIA computation needs services provided by Ontology Plug-In and Student Model Plug-In. (see figure 3 and4).

When LIA Plug-In Driver obtains the result of needed computation (i.e. the transformation from Didactic Course Specification into Didactic Course Presentation) it sends this result to the course driver instance. The delivery of the course A presentation is realized by collaboration between the course driver instance and the Course Application Manager (see figure 5).

PROPOSED ARCHITECTURE ENABLING AN E-LEARNING GRID PROPOSED ARCHITECTURE ENABLING AN E-LEARNING GRID

In deploying the IWT platform in Grid environment it must be taken into account the new environment in which this platform will be developed and will operate. The new platform will be OGSA compliant, so it will inherit all the features of such architecture. Two aspects, in particular, are important:

In deploying the IWT platform in Grid environment it must be taken into account the new environment in which this platform will be developed and will operate. The new platform will be OGSA compliant, so it will inherit all the features of such architecture. Two aspects, in particular, are important:

- the service orientation and virtualization, where the first is related to definition of service interfaces and the identification of protocols that can be used to invoke a particular interface, and the second is related to the encapsulation behind a common interface of diverse implementation, so everything (Resources, Learning Objects and so on) in this environment is a service.

the service orientation and virtualization, where the first is related to definition of service interfaces and the identification of protocols that can be used to invoke a particular interface, and the second is related to the encapsulation behind a common interface of diverse implementation, so everything (Resources, Learning Objects and so on) in this environment is a service. This is done by the definition of a Grid Service [START_REF] Foster | The physiology of the Grid[END_REF], which is the building block of OGSA. In the figure 6 the architecture of Grid based IWT (GrIWT) is shown.

This is done by the definition of a Grid Service [START_REF] Foster | The physiology of the Grid[END_REF], which is the building block of OGSA. In the figure 6 the architecture of Grid based IWT (GrIWT) is shown.

The platform is built upon a grid-enabling layer. In our solution this layer should be based on existing OGSA compliant middleware such us GT3. It is composed by a core layer, which implements the interfaces and behaviours described in [START_REF] Foster | Grid Service Specification draft 05[END_REF] (e.g. Registration, Factory, Notification) and a base and collective layer that implements services for Resource Management, Information Services and Data Transfer in the Grid. It enables single sign-on and security mechanism based on the Grid Security Infrastructure (GSI).

The next layer represent a core layer that provides the Base Services of IWT platform with the addition of a set of services useful for the management of the architecture in a service oriented and highly distributed environment, like Service Orchestrator (S.O.) for the coordination of the sub-services, Service Discovery (S.D.) for locating and retrieving service description documents, Failure Handling (F.H.) to manage the various forms of failure and exceptions that can arise in this environment and Event Handler (E.H.) to manage events and notifications between services. These services should be OGSA compliant. The features of flexibility and extensibility of the IWT platform are a good starting point towards the deployment of the platform in a Grid environment, but much work must be done. The services of IWT should be wrapped by GSs and extended in order to adapt them to the new environment. For example, the Account & Group services of IWT should provide user authentication no more in a stand-alone platform, but in a dynamic and distributed Learning Organization, providing single sign-on mechanisms. Analogously, IWT Resource & Permission services should provide authorization on resources distributed across the Grid and belonging to the same Learning Organization, based on access policy of the community [START_REF] Foster | A Community Authorization Service for Group Collaboration[END_REF].

In GrIWT there is no need for the Plug-In mechanism of IWT. In the new environment new services can be added and removed dynamically and, furthermore, external services discovered by the use of S.D., can be provided by third parties, distributed across the grid, taking the role of Content/Service Providers and can be orchestrated with other services of the platform to build sophisticated new services. This two layers comprise the minimal set of services that the platform must have. With this set of services a Learning Management System (LMS) is able to access the Grid in a secure way, to discover services and resources and to orchestrate them with its services or resources.

On top of them, there is a learning-specific layer, including domain specific services. These services comprise Object Drivers and the Aggregate Driver as well as a set of specific services like LIA. These services should be OGSA compliant, but they could be Web Services invoked by GS, too. Like for the core layer, there is no need for the plug-in drivers. Finally, there is the application layer in which the applications can be composition of GS orchestrated between them.

In the next paragraph, we explain how the scenario, described in 2.1, changes according with the new Grid based architecture.

Delivery of a Didactic Course

The first step of the Didactic Course delivery concerns the selection of a suitable Course Driver for the course chosen by the student.

In this case, when the Driver Services is invoked by the Course Manager Application (step 2 of paragraph 2.1), it queries the S.D. grid service in order to obtain an appropriate reference (e.g. GSH, see [START_REF] Foster | The physiology of the Grid[END_REF] for details) to a Factory of the Driver hosted somewhere on the Grid. After the invocation of the Factory, the Driver Services receive a reference to a new instance of the Course Driver and returns it to the Application. Now Application can invoke the Course Driver, which provides the actual delivery of the course.

In this phase (step 2, 3, 4 of paragraph 2.1), the main difference, with respect to the IWT platform, is the introduction of the Orchestration service and the elimination of the Plug-In Drivers that become unnecessary with the migration towards a Grid Services based environment.

In order to deliver the course, the Course Driver (in this scenario it should be a Grid Service), invokes the Orchestrator, passing to it a description (defined in a specified language) of the workflow among the involved services. The Orchestrator runs the workflow definition and manages the interactions among services.

The Figure 7 shows how the Orchestrator enters in the scenario depicted in 2.1. The numeration of the lines reflects the steps described in 2.1. The dotted lines describe the logical execution flow among the services (it is the same we described in 2.1). While the continuous lines represent the actual execution flow. The Orchestrator manages the interactions among the Services. It is a general service, in fact, it, simply, runs the workflow description, which is generated by the opportune Driver (in this case the Driver suitable for course A).

We would like underlining the flexibility of this architecture, and the introduction of the modification to the K&M Service that is able to retrieve references to Learning Objects distributed around the Grid, querying the Service Discovery. This opportunity allows LIA to assemble more suitable courses to student profiles.

CONCLUSIONS

In this paper we have presented the possibility to use the Grid technologies in order to implement an innovative platform for distance and collaborative learning. We have placed particular emphasis on showing the advantages that can be obtained in deploying IWT in an OGSA compliant environment. Much work must be done both in the identification and in the implementation of the functionalities that the new platform must have but, as we argued, GrIWT can potentially facilitate the emergence of a new learning models, user centred and not content centred, built upon Grid technologies.

FIGURE 6 .

 6 FIGURE 6. GrIWT Architecture.

FIGURE 7 .

 7 FIGURE 7. Workflow for Course Delivery.

Base Services Metadata Services Account & Group Services File System Services Driver Services Resource & Permission Services Common Services Infrastructure Other Service Internal Plug-Ins Plug-In Drivers External Plug-Ins Data Drivers Object Drivers Aggregate Drivers … Applications Course Manager Application Virtual Classroom English Language Teaching IWT DB Object Repository Portal Services Portal Business Game Application FIGURE 1. IWT Logical Architecture.

  [START_REF] Decker | Knowledge Representation on the Web In[END_REF]; -LIA (Learner Intelligent Advisor, external plug-in) provides customisation of didactic experiences based on target objectives given by teacher, knowledge model chosen by teacher and student preferences and competences; manages student models[6] [9]. The third layer of the stack is the Driver Layer. Drivers are pluggable components used to extend IWT services and IWT content types. There are three types of Drivers: -Object Drivers, each of them manages, in a transparent way, a specific type of content (examples of contents are lesson pages, multiple choice tests, etc.); -Aggregate Drivers, that manage complex objects (simulations, virtual experiments, etc.) arising from the aggregation of simpler objects. -Plug-In Drivers, are required to adapt for IWT the work of external Plug-Ins.A Driver realizes IWT extensibility, in fact, Object and Aggregate Drivers can dynamically extend the set of IWT managed contents, instead Plug-In Drivers extend the set of IWT managed services.

2nd International LeGE-WG Workshop on e-Learning and Grid Technologies : a fundamental challenge for Europe