1. (slide share)glue-integrationofexternaltools

Editor's Notes

• #3: The outline of this presentation includes: -Introduction. -The description of the integration problem -Brief analysis of existing proposals -GLUE! Architecture. That is our proposal to integrate external tools developed with multiple technologies in VLEs. -Prototype including Demonstration -Conclusions and future work -References
• #4: So, let’s start with the introduction
• #5: -Virtual Learning Environments, Learning Management Systems, Content Management Systems. -For this presentation that is not a relevant issue. -For this presentation just think in a VLE as a software platform or system that may support the design, enactment, and evaluation of learning situations by including a set of tools. -Some examples of VLEs according to this definition are Moodle, LAMS, .LRN, Sakai, Blackboard, MediaWiki, etc.
• #6: One of the main limitations of VLEs is the number of available tools that are included in their distributions to support learning situations. Moodle screenshot: - Chat - Forum - Multiple choice - Questionnaire - Wiki (collaborative text editor). - File system - Calendar … - and few more tools
• #7: LAMS includes more tools than a Moodle distribution LAMS (apart from the aforementioned in Moodle) ADDITIONALLY - Map tool - Mindmap - Notice board - Voting system - Spreadsheet tool
• #8: -Include other tools. I would like to design a learning situations including for instance… -Tools included in the VLE distribution do not like the educators or do not fit the requirements expected in a learning situation.
• #9: Gridcole and Pelican are two examples of PhD dissertations that have designed a VLE to include tools developed as grid services and web services respectively. More specifically, Gridcole has more than five years and was presented by one of my advisors to defend the integration of loosely-coupled external tools in learning situations. However these approaches: -Entail a high design and development effort. -Besides, requirements imposed by the VLE have to be accepted by tool providers. In Gridcole, such requirements did not become mainstream and the number of tools to be integrated was reduced. -There are several VLEs in the market that are already used in education (Moodle, LAMS, …) -A final drawback, is that educators that are used to a VLE may be reluctant to change to another one despite expected benefit; the reasons: learning effort, adaptation period; institutions promoting the use of a specific VLE. For instance, my university promotes the use of Moodle as a VLE in a Virtual Campus
• #10: Design and develop more tools for a specific VLE distribution with the functionality I do not have or do not fit my requirements -Development effort to use a new tool in just a VLE -The most important issues is that there are lots of tools in the web that educators are already using in their classes Examples: Google Docs, Wikipedia, Picasa, Delicious, Dabbleboard,…
• #11: Example: Let’s take Moodle and Google Docs, and let’s try to imaging a Google Document as part of a Moodle activity Moodle. - Courses - Learning design (quite limited but it is a learning design) - Some tools in the distribution - Manage roles and groups. Google Docs - External tool that can be used in a Moodle activity as a collaborative text editor allowing the educator to review the different versions of a document… It would be also great if groups and users defined in Moodle will be in Google Docs.
• #13: First, let’s try to offer a global vision of the integration problem 1 M VLEs with different features, APIs and architectures. N tools developed for a varied range of purposes, with different technologies and interfaces. 2 From different VLE and tool providers 3 Every tool and every VLE may impose different conditions to be integrated These conditions are defined as part of the VLE and tool CONTRACTS A contract can be defined as the set of expected behaviors, APIs, URL that a tool or VLE needs to implement to accomplish their integration. Each tool can offer one or more contracts that can be specific for one single tool or offered by several ones. The same can be said for VLEs but they are most frequently specific. 4 The difference between contracts is the integration cost. 5 Due to the technological and functional heterogeneity between tools and VLEs this cost is directly related with a software development effort. 6 This effort should be assumed by the integration agents. They are anybody willing to accomplish the integration: for example the VLE provider, the tool provider or a third party. This agents normally expect a benefit in return: recognition, reputation, economical compensation, but behind this, is that people use this integration. Benefit in terms of community acceptance. 7 The higher benefit would be achieved by integrating the higher number of tools in the higher number of VLEs. This could imply a huge development effort that would not be worthwhile to be assumed by the integration agents. So, it is important to analyze several design issues when developing a solution for the integration problem OTHER THINGS THAT CAN BE INCLUDED IN 7 The higher the number of tools integrated in a VLE => the higher the number learning situations that can be performed => the higher the number of educators that will choose such VLE for their courses. However some educators may be reluctant to change the VLE they are accustomed, or some institutions may impose a specific VLE. Therefore the higher benefit will be achieved by the integration the higher number of tools in the higher number of VLEs
• #14: SOME ADDITIONAL COMMENTS The integration problem is not new at all. But, now there is a recent renewed interest due to two factors -The spreading use of VLEs -The spreading use of educational tools available on the web It is important to consider the lessons that can be learnt from the previous work And so, the paper identifies the main design issues and alternatives when dealing with the integration problem. This issues should be considered by VLE providers, tool providers or a third-party willing to accomplish the integration of tools in VLEs. And analyze the existing proposals This analysis should be useful for those developing new tools or VLEs but also for those trying to propose a solution for the integration of tools on VLEs.
• #15: Very brief analysis of existing proposals
• #16: Moodle modules or specific extensions such as Blackboard Building Blocks, MediaWiki extensions, LAMS modules… -The integration agent normally makes the whole development effort to integrate a specific tool in a specific VLE. -Drawback: This effort cannot normally be reused for any other tool or VLE. It is a specific integration. -Advantage: You can get a tighter integration between the tool and the VLE. -However, you can have a tighter integration, such as the one in the project Sloodle (that integrates Second Life in Moodle). -Another example can be Moodle Rooms that integrated Google Apps as an additional activity in Moodle. To do so, a domain account in Google Apps is necessary. -One more example is EduJudge project to integrate Questournament in Moodle. SLOODLE and MOODLEROOMS are third-party agents that want to integrate this tools. In the third example the tool provider assumes the development effort.
• #17: IMS Global Learning Consortium initiative Loose integration. Web service-oriented Generic architecture what normally means loose integration. This architecture is oriented to web services and includes several additional services.
• #18: They try to reduce the development effort. They are focused to different kind of tools. They allow only generic interactions. As a conclusion this architectures try to decrease the development effort of integration agents. The price to pay is a loose integration.
• #20: My research tries to propose an architecture that allows the integration of external tools developed with multiple technologies in different VLEs. This architecture has been inspired in the previous work of my group in the integration of loosely coupled services in VLE but also by your work with the integration of Widgets in learning systems. Some initial requirements: -Reducing the development effort that must be made by the integration agents to integrate several tools in several VLEs. -Increasing the expected benefit allowing the integration of several tools in several VLEs -Keeping the original functionality of VLEs with respect to CSCL situations: Groups and learning design if they are available in the VLE -Educators and student should watch the external tools as another VLE tool. -Easy to install in a VLE, just as another module or extension.
• #21: Just the idea. I can add an activity in Moodle called GLUElet that includes all the external tools that can be integrated.
• #22: Just the idea. I can add an activity in LAMS called GLUElet that includes all the external tools that can be integrated.
• #23: The architecture is composed mainly by three parts. -VLE ADAPTORS. *They provide an interface for the interaction of the educators and students with the GLUE! architecture. *This interface is embedded as part of the functionality of the VLEs. *These adaptors are equivalent to any module or extension of the VLE, so they do not modify any code in the original distribution of the VLE. *Due to the heterogeneity of VLEs, every VLE needs an adaptor *Their main functionality is to request the creation and configuration of tools instances to the next element of the architecture (GLUElet Manager) depending on the users/groups that compose an activity. It can also delete tool instances. *After the creation of the tool instances a reference that includes the VLE activity, the tool that is going to be used and the reference to the tool instance in the gluelet repository is stored in the ID REPOSITORY. This repository is just a new table in the internal VLE database. -GLUELET MANAGER *It stores the tools that can be integrated in the INTERNAL REGISTRY (database) and return them to the VLE adaptors when requested (when creating a new gluelet activity). *This REGISTRY contains information about the tool and about the tool adaptor that must be used. *When requested the GLUElet Manager contacts the tool adaptor to create or delete the tool instances. *The main functionality of the GLUElet Manager is to manage the tools instances. -IMPLEMENTATION MODEL ADAPTOR *This element is in charge of creating or deleting instances. *It also contains different configuration templates for each tool that will be requested from the VLE adaptors. *This element should know the interfaces and APIs of the tools. In this case, several tools may have the same interface (some Google Apps, widgets, etc.). So, one tool adaptor can be used for several tools. This is the reason for the name implementation model adaptor. *The main requirement for these adaptors is that they have to return a URL representing the tool instances for each educator/student. If the tool is not a web tool, this adaptor should wrap it in a web interface. The learning cycle in this architecture is the following. 1.- The educator creates a new activity and selects an external tool from the ones available in GLUE! 2a.- The educator configures the external tool following a configuration template contained in the implementation model adaptor. 2b.- The architecture creates instances depending on the users/groups in the activity 3.- After that the student performs a learning situation 4.- He can use the tool through the URL provided by the architecture. Finally the ideas behind the GLUE core and periphery is that GLUE core is something that we provide because it is mandatory for this to work, while periphery elements are those expected to be developed by third-parties. Of course we will provide some of these adaptors. -GLUElet Manager -Implementation model adaptors
• #24: GET tools from GLUElet Manager GET configuration from Implementation Model adaptor POST configuration from VLE adaptor GET instance from VLE adaptor DELETE instance from VLE adaptor
• #25: -GLUE has REST interfaces. VLE adaptors makes REST requests. GLUElet Manager receives REST requests and make REST requests, Implementation model adaptor receives REST request -Atom for data exchange format
• #27: We are currently developing a LAMS adaptor and planning a MediaWiki as VLE adaptor. Regarding the tools we have to prioritize the adaptors for the experiences that we want to carry out in the next course Adaptors (specially tool adaptors are expected to be developed by third-parties
• #40: SECURITY We need to provide a compromise solution for security OAUTH=> But what about the tools that do not use OAuth => Two-legged Oauth (signing) or three-legged Oauth (delegating the authorization) => How to get the key and secret => Off-line like in Basic LTI?? Every tool can offer an authentication API with their own credentials. Another idea could be OpenID (if everybody would use OpenID) => Problem solved. Another idea keep credentials of different tools in an external server (LDAP) in the VLE (adaptor) associated to every VLE account (but you have to publish this credentials). PROTOTYPE Develop more VLE adaptors and implementation model adaptors. But they are expected to be developed by third-parties. VALIDATION Evaluation in real courses with real students. To measure the number of tools that can be integrated and the effort to develop a tool adaptor.