Lineamientos de Referencia y Contrarreferencia:

as 6/29/2011

Wait Time Okay, do nothing

Activity: Check for Active Request

Activity: Check if wait time over Activity when found: Check the Request Status

Retry Count Exceeded

Activities:

1) Mark Request Inactive, 2) set Status to Error and 3) Send Email about Failed Retries

Retry Count Not Exceeded

Activity: Check Retry Count for Max

Request Sent Start Here

Figure 17. LLMA WSCP State Chart

The two main states available for active requests were either waiting or open (ready for processing). New event request rows were created with the open status when they were inserted into the Event Request table. When the WSCP found an open request, it was immediately processed by sending a Web Service request message to the

state were evaluated to see if the WSCP should continue to wait or process the request immediately. If it was determined that the wait time had elapsed and more retries were permitted, then the request was processed immediately. Otherwise, if the wait time had elapsed and no more retries were permitted, then the request was marked as an error.

Event requests were processed in order of priorities that were assigned when the row was created by the Web-based interface or the WSCP as it processed steps for a series of tasks. As a rule of thumb, metadata event requests were given a higher priority (0-5) and the data movement requests were given a lower priority (6-9). The priority ranking design approach allowed for the processing of events to be controlled by the application administrators and thus provided flexibility. This approach was supported by the panel of CIS experts.

Although the rankings were hard coded in the prototype, this functionality could have been easily designed to make the ranking process data driven from values in an Oracle table. For example, instead of a function assigning a hard coded ranking of 2 to a request to get LO list metadata, the process could have been enhanced to find the rank in the Event Type table. Had this enhancement been added, administrators could have easily tuned the event execution processing order by changing the priority values in a table.

Results from the Web-based Interface Web Page Design Process

The following series of screen captures show the web page designs that were created by the researcher and approved by the panel of CIS experts. The first LLMA web page was the initial login window (a.k.a. the default web page) that asked LLMA users to enter a user ID and password (shown in Figure 18).

Figure 18. LLMA User Login Webpage

If it was the first time the user accessed the LLMA web application, then the user was given the option of creating a new user ID and password by registering their name and email address. As an added security measure, all of the other LLMA web pages checked for a validated user ID prior to displaying that webpage. Therefore, if a validated user was not found during the page initialization, then the user was automatically routed to the default web page.

As part of the login process, the user ID and password were validated against values stored in the Oracle Metadata Repository. Password information was encrypted in Oracle database using a built-in Oracle 11g feature called column level data encryption. Although the encryption process was transparent to the application, the password data was stored in the Oracle database files using a 32-byte encryption key.

This encryption process prohibited unauthorized access of password information via direct access of the data files on hard disk. As a user logged into the application, the value of the password was hidden from display during the login process. This particular login code snippet was part of a C# ASP .NET login control that was leveraged for this project.

After the LLMA user ID and password were validated, the user was directed to the main navigational web page of the application (shown below in Figure 19).

Figure 19. LLMA Main Navigation Webpage

The top push button on the Web page allowed the user to flow through a series of additional web pages to gather the metadata necessary to request data movement of a LO from a particular LMS or LOR. The second push button allowed a user to check the status of a prior data movement request (e.g. request log). The third push button allowed the user to select from a list of LMS or LOR repositories and then register specific connection details for their user ID. The fourth push button facilitated the establishment

of new user IDs and user information such as name and email address. The fifth push button allowed a user to document connection information for a LMS or LOR repository, such as the name, description and URL. The sixth push button supported the rating of a LO, whereas the last push button facilitated the export of a LO to an external application, such as a LO design tool.

One of the main objectives of this web interface was to allow a user to assemble the necessary metadata needed to send a request to a LMS to copy LO data to a LOR. The web pages that are shown in this section allow the user to accomplish this task of metadata selection. Note that the metadata that was displayed on these web pages was retrieved from the Metadata Repository and was either entered by the user or sourced from external LMSs or LORs using SOA Web Services. For example, to display a list of LORs and LMSs, the user would have had to first define the LMS/LOR using the LMS and LOR Maintain Connection Detail Maintenance web page (shown in figure 20).

User access to a specific LMS or LOR was documented via the following web page (shown below in figure 21).

Figure 21. LLMA Register a LMS or LOR for your User ID Web Page

For this web page, the user picked from a list of valid LMSs or LORs and then entered their unique LMS or LOR user ID and password. This activity would then trigger the addition on an event on the event request table. A Web Service would then make a request to the LMS to validate the user ID/password and also to return a list of LOs that are available for the user ID. The list of available LOs returned from the LMS was then stored in the Metadata Repository for later use.

The web pages shown below demonstrate the data movement process (e.g. happy path) with the assumption that a user had already: (a) documented a valid LMS and LOR, (b) registered their LMS and LOR user ID and password, (c) had access to LOs stored within the LMS, and (d) had authorization to copy data into a the LOR via a valid user ID and password. Figure 22 contains an example of a registered LMS and LOR. In

addition, the user can decide via the push buttons which direction the LO data should move. For example, data could have been copied from the LMS to the LOR or it could have been copied from the LOR to the LMS.

Figure 22. LLMA Select a LMS and LOR web page

The next web page (shown in Figure 23) lists LOs that are available for

movement (copy) from the LMS to the LOR (or vice versa). The user selected a LO from the list and then indicated using the push buttons if the entire LO, partial LO or refresh of the student assessment data was needed.

Figure 23. LLMA List of LOs which are available for copy or refresh.

The next web page (Figure 24) was where the request was finalized by the Web- interface user. At the top of the page was a summary of the request. In the example shown below, the request type was a complete copy of a LO called Botany – 101, Introduction to Botany. After the user clicked the Submit the Request button, the event request row was created in the Metadata Repository. Immediately, the event request was read by the WSCP and then a Web Service call was sent to the LMS. When time

permitted, the LMS processed the message from the Moodle message queue and then replied to the Web Service with a SOAP message that contained a summary of the data that was moved. The WSCP Web Service received the message, processed the LO based on the user request parameters, and then sent a SOAP message to the FLORI Fedora with a request to store the LO data.

Figure 24. LLMA Submit a Request Web Page.

After the request was submitted, the user was notified with a message at the bottom of the web page that the request was submitted. Also, a button labeled View Report History became active on the bottom of the window (see figure 25).

Figure 25. LLMA Message about submitted request.

The users then navigated to a web page that contained a list of LO data movement requests (see figure 26) that were relevant to them. Other users that navigated to this web page would see a list of requests that pertained to their user ID. The list was sorted by open requests at the top, followed by closed requests at the bottom. Within open and closed requests, the requests were sorted in descending date order. This sort order

allowed a user to easily find and monitor requests that were being processed. The refresh button at the bottom of the window allowed the user to refresh the request status from the Metadata Repository.

The WSCP made changes to the status of a request as the various steps were completed. This allowed the WSCP to retry the request if the LMS or LOR became temporarily unavailable for maintenance. Note that there are many internal processing events that were logged by the WSCP server that are not displayed on this web page. The WSCP kept a log file of all major activities that served as an audit trail.