# Crossing the Borders: Re-Use of Smart Learning Objects in Advanced Content Access Systems
## 4 Materials and Methods  
### OpenDSA as a Tool-Consumer  
Historically, OpenDSA started as only an LTI tool provider. OpenDSA modules could be added to Canvas through the Canvas API. Over time, instructors wanted to add support for coding exercises in OpenDSA modules. Our original design involved using CodeWorkout [2] as another tool provider in Canvas. To accomplish this, OpenDSA content creators would add CodeWorkout exercises as a part of the OpenDSA module. Then instructors would create their courses on OpenDSA and OpenDSA would populate the Canvas course through the Canvas API. The Canvas API calls would not only create OpenDSA modules in Canvas but also would create CodeWorkout assignments separately. Unfortunately, this goes against the model of \"OpenDSA as a textbook\" that has understanding and control of its exercises (while communicating necessary information to the LMS). Instead, separate Canvas assignments are required, which means that students had to navigate away from the OpenDSA module and open the assignment in a separate page. Also, OpenDSA did not have a complete picture of students' performance, because under this model CodeWorkout and Canvas directly communicated with each other. Finally, OpenDSA could not group multiple assignments onto a page as might be the more natural presentation, because Canvas requires that each of its assessments be mapped to separate Canvas pages.  
To overcome these problems, the OpenDSA development team implemented a new architecture that allows OpenDSA to act as both a tool provider and a tool consumer. This new architecture enables OpenDSA to integrate with other external tools. In this particular example, OpenDSA uses CodeWorkout as an external tool and includes the CodeWorkout assignments within its modules, as shown in Figure 7. Now, Canvas uses OpenDSA as an external tool and has no direct interaction with or information about, CodeWorkout. Canvas sends an LTI launch request to OpenDSA and then OpenDSA sends an LTI launch request to CodeWorkout to display coding exercises in the textbook. CodeWorkout responds to the LTI launch request from OpenDSA by displaying the requested exercise, which is shown within an iframe in the OpenDSA module, while the OpenDSA module is itself displayed within an iframe in the Canvas page.  
Figure 8 shows a CodeWorkout exercise embedded within an OpenDSA module as it appears within Canvas. This allows students to solve programming exercises from within the same Canvas page where they read prose and see visualizations. This also allows OpenDSA to have a more complete picture of how a student is performing on other exercises, since it knows when the CodeWorkout exercise has been accessed, as well as what scores students get on CodeWorkout exercises. We believe that this approach offers a richer model for the future of online textbook construction. While inclusion of external interactive content has been used in several online textbook projects [11; 20], it was done using proprietary integration approaches making it impossible to use interactive content across  
Figure 6: A program visualization (animated example) loaded from the Mastery Grids interface.  
multiple projects. Using standard interaction protocols opens a way to a broad re-use of smart content. The approach used by OpenDSA, whereby intermediaries stand between the LMS and the individual smart object types, points the way to richer ecosystems of collaborating components. Unfortunately there still remains the problem that CodeWorkout does not share details about student interactions within the programming exercise with OpenDSA (or any other third party accessing it). This is a communications deficiency that deserves attention in future work but becomes no longer a problem inherent in the communications architecture.