F e b r u a r y 1 8

Strategies and Techniques for Designers, Developers, and Managers of eLearning

A publication of

THIS WEEK — MANAGEMENT STRATEGIES

2003

SCORM incompati-bility across multi-ple Web domains is not a frequently-discussed problem,but it exists, and in some organiza-tions presents amajor obstacle to enterprise-wide distributed learn-ing. In this article,you will learn howthis may affectyour organization,and some strate-gies that may help you workaround it.

SCORM Deployment Issues in anEnterprise Distributed LearningArchitectureBY JEFFREY C. ENGELBRECHT

Enterprise distributed learning systems are required tosupport many technologies, subsystems, and specifica-tions that were initially designed for a campus environ-

ment. However many of these include functionality that pre-vents them from being expanded to support an enterprisearchitecture. Delivering content to distant users located indispersed networks, separated by firewalls and different Webdomains, requires extensive customization and integration.

Military systems are particularly difficultsince military environments often consistof conflicting and overlapping firewallrestrictions, and multiple local and widearea networks. In addition, Department ofDefense (DoD) and command-level securitypolicies require systems to comply withspecifications for interoperability and stan-dardization. This article outlines someof the problems of implementing theSharable Content Object Reference Model(SCORM) in the Marine Corps DistanceLearning System (MarineNet) and extendsthe discussion to other educational institu-tions as well as to the corporate sector.

SCORM is a content interface specifica-tion that is becoming widely accepted byDoD and the commercial learning technolo-gy industry world-wide. While SCORM pro-vides important benefits for interoperabili-ty, advanced dynamic tracking and sequen-cing of student progress, the specificationdoes not adequately support deploymentin enterprise architectures. This articlereviews the impacts of the DoD MobileCode Policy and the inherent restrictions ofWeb programming that require distributedlearning content to be located near theuser and prevents the content from com-

Continued on next page

W W W. E L E A R N I N G G U I L D . C O M

municating to a centralized Learning Man-agement System (LMS) via the SCORMspecification.

An introduction to coursewareinterface specifications

The goals of all courseware interfacespecifications are to promote interoperabili-ty, accessibility, durability, and reusability.The four organizations that are leading e-Learning developers toward standardsare:

• The Aviation Industry Computer-BasedTraining Committee (AICC),

• The Instructional Management SystemGlobal Learning Consortium, Inc. (IMS),

• The Institute of Electrical andElectronic Engineers (IEEE), and

• The Advanced Distributed Learning(ADL) initiative.

(Editor’s Note: Find more informationabout these bodies in the Guild ResourceDirectory, under “Design & DevelopmentStandards” category.)

All of the standards bodies have under-gone considerable evolution since their creation and many of them now share thesame guidelines.

The IMS is an international standardsbody that promotes many of the core dataformatting and packaging specificationsthat are used in both the AICC and ADLspecifications. Both the AICC and ADLgroups assist user communities in imple-menting the core IMS specifications. TheAICC group focuses on the aviation indus-

try and the ADL group focuses on the DoD.Both the AICC and ADL communitiesexpand on the IMS specifications, provid-ing additional guidance on how coursewareshould exchange the information with aLMS as well as for the sharing of contentand information between other programsand systems.

The AICC specification offers two web-based approaches for courseware to inter-face with an AICC-compliant LMS, theApplication Programming Interface (API)implementation and the HyperTextTransport Protocol (HTTP)-based ComputerManaged Instruction (CMI) Protocol (HACP)implementation. (Editor’s Note: See theGlossary at the end of this article for defi-nitions of terms that may be new to you.)While both implementations operate on thesame underlying IMS data structures andutilize similar function calls, the mecha-nisms providing the communication link arequite different.

The API implementation is a JavaScriptapproach, while the HACP implementationis a traditional HyperText Markup Language(HTML) approach. This is an important dif-ference that must be understood by everydistributed learning architect becausethere are several limitations with bothapproaches. This article, however, primarilydiscusses the API implementation in detail.

The SCORM specification developedthrough the ADL initiative is based directlyon AICC’s API implementation and thusshares its advantages as well as inherent

limitations. The SCORM specification doesnot provide a HTTP-based implementationas does AICC; however the API incorpo-rates the same course launch construct aswell as the information exchange functionsspecified by the AICC API specification.

While the differences between an APIand a HTTP implementation might seemtrivial, the impact on a distributed learningarchitecture is significant. Programmingtechnologies, their respective network pro-tocols, and inherent security constructsproduce very different outcomes andpotential problems and limitations forenterprise architectures.

The SCORM and AICC API interfacesThe SCORM and AICC API specifications

operate in the same manner. The keyadvantage of the API interface is thereduced complexity (compared to HACP) forthe courseware developer. Complexity isreduced since most of the direct interfac-ing with the LMS database is abstracted toa set of JavaScript functions. Additionally,the inclusion of the JavaScript functions issimplified by using a script within the con-tent to locate the API functions within theLMS browser windows.

Figure 1 illustrates the process of locat-ing and including the API functions andidentifies the sources and responsibilitiesof each of the code components. Upon initial launch of an API-enabled course,whether SCORM or AICC, the first step isto locate and include the API functions provided by the LMS so that the contentcan initiate communication with the LMS.The assignable unit (AU), which is called asharable content object (SCO) in SCORM,runs a JavaScript FindAPI() function thatsearches all of the available web browserframes and windows opened on the user’sworkstation. Once the search locates theAPI object, the function returns the objectso the SCO can execute the containedfunctions.

Three types of functions, specified in theAPI Adapter, are executed by the content:execution state functions, state manage-ment functions, and data transfer func-tions. There are two execution state func-tions that are responsible for initiating andterminating session connections with theLMS. There are also three state manage-ment functions that are responsible forhandling errors in the communications withthe LMS. Lastly, three data transfer func-tions exist that are responsible for transfer-

2FE

BR

UA

RY

18,

20

03

/ T

HE

EL

EA

RN

ING

DE

VE

LO

PE

RS

’ JO

UR

NA

L

MANAGEMENT / s t r a t e g i e s

FIGURE 1 Locating and including the API functions is the first step after launching a course.

ring data to and from the LMS. Theseeight functions are all that comprise theAPI Adapter from the content’s perspec-tive. The only other function that is part ofthe API specification is the FindAPI()function, which is programmed by the con-tent developer and contained within thecontent itself. The ADL web site located atwww.adlnet.org provides detailed informa-tion about each of the functions. Otherthan the FindAPI() function, thesedetails are not central to the theme of thisarticle.

One important point to understandabout the construction of the API imple-mentation is the relative owner or sourceof the code components. The FindAPI()function and the execution of the individualfunctions contained within the API are theresponsibility of the individual SCOs, how-ever the source of the API is the LMS.When content is launched from the LMS,the LMS must maintain a web browser win-dow or frame that contains the API and theSCO must be capable of locating andincluding the API functions as if the func-tions were an integral part of the content.

The problem with the API implementation in an enterprisearchitecture

As described in the previous section,when SCORM-conformant content islaunched, the first action that must takeplace is for the JavaScript code containedin the content to locate the SCORM APIthat is provided by the LMS. The SCORMAPI Adapter is typically located in a differ-ent web browser window or frame than thecontent. This implementation is feasible

as long as the content and the SCORM API Adapter are both in the same webdomain (For example, both are in themarinenet.usmc.mil web domain).However, if the LMS window is in a differ-ent web domain than that of the contentwindow, then security rules will prohibit thecode within the content window or framefrom accessing the SCORM API Adaptercontained within the LMS window or framebecause it is also in that other domain.

Figure 2 illustrates how the currentMarine Corps environment impedes theuse of SCORM. In this scenario, Marinestudents are located at two geographicallyseparated training locations, some withinthe Marine Corps domain and some withinthe Army domain. This scenario isdescribed because large populations ofMarine students attend resident training atother service locations. Figure 2 illus-trates the example of providing skill train-ing to tank crew members at both an Armyand Marine Corps installation. The courseon basic tank operation and maintenanceis applicable to Marine students attendingresident training at the Army’s Tank Schoolat Ft. Knox, Kentucky, as well as theMarines receiving refresher training atQuantico, Virginia. Marine students ateach location would interface with the cen-tral Marine Corps LMS to initiate the train-ing session, but would be redirected to alocal content server at the respective loca-tion to receive the high-bandwidth content.

The Marine Corps operates centralizedLMS servers located within the marinenet.usmc.mil web domain. Since DoD mobilecode policies make it problematic to cen-tralize content hosting, content servers

THE

EL

EA

RN

ING

DE

VE

LO

PE

RS

’ JOU

RN

AL

/ FEB

RU

AR

Y 18, 2

00

3 3

MANAGEMENT / s t r a t e g i e s

The eLearning Developers’ Journal™ is design-ed to serve the industry as a catalyst for inno-vation and as a vehicle for the dissemination ofnew and practical strategies and techniques fore-Learning designers, developers and man-agers. The Journal is not intended to be thedefinitive authority. Rather, it is intended to be a medium through which e-Learning practi-tioners can share their knowledge, expertiseand experience with others for the general betterment of the industry.

As in any profession, there are many differ-ent perspectives about the best strategies,techniques and tools one can employ to accom-plish a specific objective. This Journal will sharethese different perspectives and does not posi-tion any one as “the right way,” but rather weposition each article as “one of the right ways”for accomplishing a goal. We assume thatreaders will evaluate the merits of each articleand use the ideas they contain in a mannerappropriate for their specific situation. Weencourage discussion and debate about articlesand provide an Online Discussion board foreach article.

The articles contained in the Journal are allwritten by people who are actively engaged inthis profession at one level or another — not by paid journalists or writers. Submissions arealways welcome at any time, as are sugges-tions for articles and future topics. To learnmore about how to submit articles and/orideas, please refer to the directions in the side-bar on page 6 or visit www.eLearningGuild.com.

Publisher David Holcombe

Editorial Director Heidi Fisk

Editor Bill Brandon

Copy Editor Charles Holcombe

Design Director Nancy Marland

The eLearning Guild™ Advisory BoardRuth Clark, Conrad Gottfredson, John Hartnett,

Bill Horton, Kevin Moore, Eric Parks, Brenda PfausMarc Rosenberg, Allison Rossett

Copyright 2003. The eLearning Developers’ Journal™.Compilation copyright by The eLearning Guild 2003. Allrights reserved. Please contact The eLearning Guild forreprint permission.

The eLearning Developers’ Journal is published weeklyby The eLearning Guild, 525 College Avenue, Suite215, Santa Rosa, CA 95404. Phone: 707.566.8990.The eLearning Guild is an operating unit of FocuszoneMedia, Inc., 1030 Beatrice Street, Eagan, MN 55121.

The Journal is included as part of Guild membership.To join the Guild go to www.eLearningGuild.com.

FIGURE 2 SCORM incompatibility in an enterprise environment is illustrated by the currentMarine Corps scenario.

MANAGEMENT / s t r a t e g i e s4

FEB

RU

AR

Y 18

, 2

00

3 /

TH

E E

LE

AR

NIN

G D

EV

EL

OP

ER

S’

JOU

RN

AL

must be located within the security enclaveof each base network. The impact of themobile code policy is further explainedlater in this article. These distributed con-tent servers can operate within variousWeb domains as illustrated in Figure 2 onpage 3.

Content servers located on MarineCorps Base (MCB) Quantico are locatedwithin the marinenet.usmc.mil Web do-main, so that SCORM-enabled content caninteract with the SCORM API Adapter locat-ed within a LMS window or frame. How-ever, content servers located on otherbases such as Ft. Knox, which operatewithin the knox.army.mil Web domain, can-not operate SCORM-enabled content sincethe content code cannot interact with theSCORM API Adapter located in a differentWeb domain.

A review of web securityThe reason that SCORM-enabled content

cannot interact with a SCORM API Adapterserved by a different Web domain is attrib-utable to the core security restrictions ofWeb coding. Web browsers, includingNetscape Navigator and Microsoft InternetExplorer, allow potentially destructive codeto be embedded in a Web page, down-

loaded across the net, and executed on a local machine even without the user’sknowledge. The two most popularapproaches to protect users from mali-cious code are sandboxing and code sign-ing. Sandboxing, the approach implement-ed by Java, protects the user by restrictingthe untrusted code from operating outsidethe scope of the program space and thusrestricting it from interfering with otherapplications or processes. Code signing,the approach implemented by ActiveX, protects the user by allowing the user todetermine the authenticity of the code priorto it running, thus providing an authentica-tion model.

Both sandboxing and code signing arewidely accepted and implemented securityapproaches, but each has its detractors.ActiveX does not have an inherent securitymodel but rather uses a trust model.Thus, ActiveX requires that the user under-stand the purpose of the code and havesome amount of trust of the developer thatsigned the code. If the user understandsthe purpose of the code and trusts thedeveloper, then he or she can acknowledgethe trust and allow the code to function.One thing to note is that once the user

Symposium

The

A Winter Intensive for e-Learning Managers and DirectorsFebruary 27 & 28, 2003Scottsdale, Arizona

Produced by

www.eLearningGuild.com

Learn more about this symposium, it’s all online atwww.eLearningGuild.com!

Registrations are strictly limited so Register Today! You can register online or by phone by calling 707.566.8990.

SCORM-developedcourseware expects tohave access to the SCORMAPI functions provided bythe LMS, and traditionallythe API is contained with-in the code build of theLMS. However, if the APIfunctions were co-locatedwith the courseware, thusabstracted from the LMS,the courseware would beable to access the func-tions even if the contentwas located in a differentWeb domain.

explicitly trusts the code, it may operatewith the same system rights as other pro-grams that were installed by the user.(Whether the user can adequately deter-mine if the developer’s signature is authen-tic is not a concern for this article.)

Sandboxing does not require the user toexplicitly trust the code, rather all sandboxcode is considered to be inherently harm-ful. Thus, to prevent the code from damag-ing the user’s system the code is prevent-ed from interacting with other applicationsand processes on the user’s machine.The largest scope of the sandbox isrestricted to the Web domain under whichthe code is executed, but this scope canalso be further restricted by the applet orthe user’s Web browser.

A SCORM-conformant implementationspecifies that the LMS software implementthe SCORM API Adapter. The API Adaptermust also be coded in Java or JavaScript.Therefore the use of the ActiveX trustmodel, as a possible solution, is not sup-ported. Thus if SCORM is an enterpriserequirement, then the architecture mustdeal with the limitations of distributingcode that operates within a single sand-box. This means that the sandbox isrestricted to the Web domain where theLMS and the SCORM API is located. If thecourseware that is calling the SCORM APIis located in a different Web domain, thusa different sandbox, then it will not be ableto execute or locate the API.

The illustration used in Figure 1 is modified in Figure 3 to identify where thedomain conflict is located.

As illustrated in Figure 3, theFindAPI() function is unable to locatethe SCORM API Adapter since theFindAPI() function is located in a differ-ent Web domain than the API Adapter. Theresult of the FindAPI() function wouldreturn a null value and the content wouldreport that the LMS is unavailable or other-wise could not connect.

Mobile code policies — pushingcontent to the edge

Many distributed learning applicationsare not forced to confront the problemsassociated with operating in multiple Webdomains; however the DoD has strict infor-mation security policies that prevent course-ware from traversing security boundaries.The policy that impacts centralized contenthosting is the DoD Mobile Code Policy(http://www.c3i.osd.mil/org/cio/doc/mobil

e-code11-7-00.pdf).The DoD Mobile Code Policy restricts the

use of web technologies such as Java,JavaScript, ActiveX, Macromedia Shock-wave, Macromedia Flash and most otherclient-side programming technologies.Each mobile code technology is assignedto one of three categories:

• Category 1, which includes ActiveX, is fully authorized to operate.

• Category 2, which includes Javaapplets and other Java mobile code, isauthorized only if the code is obtained froma trusted source.

While category 1 and 2 technologiespossess the necessary tools to allowcourseware to effectively communicate tothe LMS, courseware without user interac-tivity is not likely to create a worthwhilelearning experience for the user.

• Category 3 contains the bulk of thetechnologies that allow for interactive andstimulating learning experiences. Category3 technologies include JavaScript,VBScript, Macromedia Shockwave,Macromedia Flash, and even Adobeportable document format (PDF).

The DoD Mobile Code Policy allows forCategory 3 technologies to be used onDoD information systems, however manymilitary firewall policies, including theMarine Corps’, prohibit some of thesetechnologies from breaching networkboundaries. Most distributed learning con-tent, including those employed by theMarine Corps, leverage heavily on Flash

and Shockwave for instructional purposes;however the use of Category 1 content,such as Java, is also critical to content.

With courseware relying heavily onCategory 3 technologies, DoD distributedlearning programs must find ways to deliv-er content to distributed users without vio-lating policies. The typical solution is tohost the content at each of the militarybases, thus behind the firewall boundaries.Since it is too costly to operate an LMS ateach user site, a centralized LMS is forcedto interact with numerous content servers,each located behind a firewall. Course-ware being delivered to the user from with-in the firewall boundary can operate allmobile code technologies; however theSCORM interface between the coursewareand the central LMS server must now dealwith the problem of multiple Web domains,which is the motivation of this article.

DoD is not the only organizationaffected

The military example described in thispaper may be the most convenient way tohighlight the problems with SCORM inenterprise architectures; however it is notthe only example. Large geographicallydispersed organizations must also con-front this problem. Moreover, organiza-tions that are consolidated in a singlelocation may have similar problems if theyattempt to use content provided by third-party organizations.

Many commercial companies have con-

THE

EL

EA

RN

ING

DE

VE

LO

PE

RS

’ JOU

RN

AL

/ FEB

RU

AR

Y 18, 2

00

3 5

MANAGEMENT / s t r a t e g i e s

FIGURE 3 Cross-domain problems in SCORM arise when the content and the LMS are indifferent domains.

MANAGEMENT / s t r a t e g i e s

solidated many of the information technolo-gy (IT) services to centralized or regionalheadquarters to reduce costs and consoli-date resources. The benefits of operatinga single centralized LMS are easy to justifyand the justification to extend the storageof high-bandwidth content to the outeredges of the network is also justifiable.The cost of purchasing, administering,

and maintaining simple web-enabled con-tent servers at each company location isconsiderably lower than the cost of thebandwidth consumption of multiple userstrying to pull identical content from a single location.

Additionally, many organizations see thevalue of accessing content from third-partylocations such as the Library of Congress,

Carnegie Mellon’s Artificial IntelligenceRepository, the National Archives, or simplybetween each other. In order to enjoyeconomies of scale, eliminating duplicationof effort through the consolidation of simi-lar functions may be necessary. Thereforehaving the content owner also host theinformation relieves each subscriber organ-ization from duplicating the same infra-structure and associated costs.

Allowing other organizations to re-hostthird-party content creates the potential forlegal as well as lifecycle managementissues. Beyond just the economic benefitsof consolidating resources, copyright andother legal restrictions can prevent organi-zations from re-hosting content in their owndomain. Furthermore, once an organiza-tion re-hosts the content, the link betweenthe content owner and the user increasesthe probability of out-of-date or incorrectinformation.

The solutions in sightThere are several potential alternatives

for overcoming this issue. These solutionsinclude:

1. Modify the SCORM API Adapterenabling it to be hosted on the distributedSCORM content servers.

2. Modify the Web domain structure ofthe enterprise system to bring the LMSand all distributed SCORM content serversunder a single Web domain.

3. Continue using other protocols suchas the AICC HACP specification untilSCORM is updated to be compatible withenterprise systems.

Solution 1 would entail recoding theLMS’s SCORM API Adapter, enabling it tobe hosted on remote content serversinstead of the LMS servers. By porting theAdapter to the content server, both thecontent code and the Adapter code wouldbe within the same sandbox. The resultingcomplication is that the LMS vendorswould have to modify the back-end commu-nication to the LMS database or middle-ware software to accept, store, andretrieve the information for the distributedSCORM API Adapter that is located on aremote content server. Furthermore, thecommunications between the Adapter andthe LMS would have to be developed tooperate using acceptable network proto-cols to avoid firewall security restrictions.

Solution 2 does not require reprogram-ming, however it does require the authority6

FEB

RU

AR

Y 18

, 2

00

3 /

TH

E E

LE

AR

NIN

G D

EV

EL

OP

ER

S’

JOU

RN

AL

This publication is by the people, for the people.That means it’s written by YOU the readers and members of The eLearning Guild!We encourage you to submit articles for publication in the Journal.

Even if you have not been published before, we encourage you to submit a queryif you have a great idea, technique, case study or practice to share with your peersin the e-Learning community. If your topic idea for an article is selected by the edi-tors, you will be asked to submit a complete article on that topic. Don’t worry if youhave limited experience writing for publication. Our team of editors will work withyou to polish your article and get it ready for publication in the Journal.

By sharing your expertise with the readers of the Journal, you not only add to thecollective knowledge of the e-Learning community, you also gain the recognition ofyour peers in the industry and your organization.

How to Submit a QueryIf you have an idea for an article, send a plain-text email to our editor, Bill Brandon,at bill@eLearningGuild.com, with the following information in the body of the email:

• A draft of the first paragraph, written to grab the reader’s attention and identifythe problem or issue that will be addressed.

• A short outline of your main points addressing the problem or resolving theissue. This could be another paragraph or it could be a bulleted list.

• One paragraph on your background or current position that makes you the oneto tell this story.

• A working title for the article.

• Your contact information: name, job title, company, phone, email. This informa-tion is to be for the writer of the article. We are unable to accept queries fromagents, public relations firms, or other third parties.

All of this information should fit on one page. If the topic fits our editorial plan, Billwill contact you to schedule the manuscript deadline and the publication date, andto work out any other details.

Refer to www.eLearningGuild.com for more details.

Get It Published in...

Do you have an interesting story to tell?

THE

EL

EA

RN

ING

DE

VE

LO

PE

RS

’ JOU

RN

AL

/ FEB

RU

AR

Y 18, 2

00

3 7

MANAGEMENT / s t r a t e g i e s

to manipulate third-party networks and topotentially mislead users. While the Webdomain model was initially developed topreclude users from manually entering IPaddresses, the domain model has devel-oped into an identification of ownershipand accountability. Hosting systems onother domains is permitted by some net-work owners based on the desire to con-solidate resources; however the foster sys-tems do not typically fall under the jurisdic-tion of the hosting network. Thus, if thefoster system malfunctions, violates securi-ty policies, or simply has to be upgraded,then the responsibility falls on the systemowner rather than the network owner whois hosting the system.

Hosting all of the content servers withina single Web domain operated by a singledistributed learning provider might simplifythis problem, but this scenario requiresthat hosting networks allow the LMS sys-tem to publicize IP addresses as beingowned by the application provider ratherthan the hosting network. For example,the Navy might allow the Marine Corps to advertise a Navy-owned IP address as a Marine Corps component (thus,www.marinenet.usmc.mil would resolve to the Navy-owned IP address of205.70.115.15), but current policies pro-hibit advertising external commercial IPaddresses as being a Marine Corps com-ponent (www.marinenet.usmc.mil resolvingto the commercial IP address of198.175.96.33).

Both solutions 1 and 2 are attractive inthat they do not deviate from the API speci-fication used by both AICC and SCORM,however these solutions may not be com-patible with all enterprise distributed archi-tectures. Solution 1 is completely depend-ent on the LMS since the API Adapter is asoftware component of the LMS. If LMSvendors could develop a capability of port-ing the API to a remote content server,then that LMS might be closer to meetingan enterprise LMS requirement as previ-ously described. However, to date, thisfeature is not an advertised capability ofany commercial LMS product.

Distributed learning programs that imple-ment solution 2 also benefit by not deviat-ing from the API specification, howeverthey must incorporate network manage-ment into their responsibilities. Managingdomain naming servers or even elaboratevirtual private network systems may

exceed the capabilities and resources atthe disposal of many organizations.Commercial companies and educationalinstitutions may have the ability to alter thenetwork and employ such network tech-nologies, however this does not guaranteea solution since the ownership and hostingof some content may still be restricted. Aslong as content is hosted by a third party,such as the National Archives, and policies

restrict the re-advertising of such resourc-es, the ability for distributed learning sys-tems to offer these resources to theirusers will be restricted.

From the Marine Corps perspective, nei-ther solution 1 nor 2 has proven to beviable since they require customizationseither to the network or the LMS software.While it may be feasible to customize theLMS, these customizations would inherent-

API adapter: A Java applet provided by the LMS and running in the learner’sbrowser. The API adapter makes it possible for the content in the SCO to communi-cate with the LMS.

Application Programming Interface (API): A set of routines, protocols, and toolsfor building software applications. A good API makes it easier to develop a programby providing all the building blocks, and all programs using a common API will havesimilar interfaces.

Assignable Unit (AU): The Assignable Unit refers to the actual content level inhierarchies defined by ADL/SCORM and by AICC. It is the smallest element of acourse that can be assigned to a learner by a Computer Managed Instruction (CMI)system. One or more Assignable Units constitute a lesson, or nested instructionalblock. The highest level hierarchy is the Course level.

Code components: The elements (specifically, the API Adapter and theFindAPI() function) that make it possible for the Learning Management System(LMS) to find, launch, and communicate with lessons in courses.

Function: In programming and scripting languages, functions are commands thatperform specific tasks (routines) and (usually) return a value. A function call in ascript or program invokes the function. Calling a function consists of specifying thefunction name and, optionally, parameters (values that are needed in order for thefunction to carry out its task). In using an LMS, FindAPI() is a function thatsearches all of the available web browser frames and windows to find the API andpermit an Assignable Unit or lesson to run.

HyperText Transport Protocol (HTTP): The underlying protocol used by the WorldWide Web. HTTP defines how messages are formatted and transmitted, and whatactions Web servers and browsers should take in response to various commands.

JavaScript: A scripting language developed to enable Web authors to design inter-active sites. Although it shares many of the features and structures of the full Javalanguage, it was developed independently. Javascript can interact with HTML sourcecode, making it possible for sites to deliver dynamic content. JavaScript is an openlanguage that anyone can use without purchasing a license.

LMS browser window (or frame): The window or frame within the browser in whichthe API Adapter is located.

LMS server: The physical server where the Learning Management System is running.

LMS specification: A standard that details how a Learning Management Systemlaunches a lesson, and how data is communicated between the LMS and the lesson

Web browser frame: A feature supported by most modern Web browsers thatdivides the browser display area into two or more sections (frames). The contents ofeach frame are taken from a different source; in the case of a Learning ManagementSystem, the API Adapter is typically located in a different frame or window than thecontent. As the article points out, code in the content window may not be able toaccess the API Adapter in the LMS window or frame.

(Editor’s Note: Additional definitions may be found online at www.webopedia.comand at www.whatis.com.)

GLOSSARY

MANAGEMENT / s t r a t e g i e s

ly be tied to that specific LMS build, thuslimiting or even preventing future upgradesand replacement without additional cus-tomization. Furthermore, when dealingwith content hosted by other organizations,the new portable API Adapter would haveto be contained within, or provided with,the courseware.

Additionally, the Marine Corps DistanceLearning Program does not own any net-work infrastructure. In fact, distributedlearning applications use the MarineCorps Enterprise Network and thereforemust accept the policies and service lev-els set forth by government and commer-cial network service providers. Customconfiguration of such an infrastructure toaccommodate specific distributed learningneeds is not feasible in this environment.Therefore, the Marine Corps DistanceLearning Program is pursuing solution 3while continuing to investigate otherpotential sub-optimal options such as theintegration of a HACP solution with theSCORM specification.

The case for integrating SCORM and AICC

There is one rather straightforwardapproach to bridging the gap between dis-tributed courseware and a central LMSwithout customizing courseware or theLMS. SCORM-developed coursewareexpects to have access to the SCORM APIfunctions provided by the LMS, and tradi-

tionally the API is contained within thecode build of the LMS. However, if the APIfunctions were co-located with the course-ware, thus abstracted from the LMS, thecourseware would be able to access thefunctions even if the content was locatedin a different Web domain. Figure 4 illus-trates this potential solution.

The problems with this approach arethat the back-end communications to theLMS would have to be able to communi-cate with the centralized LMS databaseand the entire functionality of the inter-change between courseware and the LMSwould be limited to the capabilities of theback-end communication.

Most LMS vendors would require adirect database connection from the APIfunctions to the LMS database in order toreuse the existing courseware interfacemodules contained in the API Adapter. Allof the distributed content servers wouldalso have to establish Open DatabaseConnectivity (ODBC) connections. Thiswould impact both the content serverssince most would not already have data-base capabilities. It would also impact net-works since the database transmissionswould occur over database ports instead oftraditional Web HTTP ports. This approachmay work for some organizations, howeverdatabase communications across unpro-tected networks create several securityconcerns and within the DoD environmentare strictly limited.

A potential solution is to have the APIfunctions operate the basic SCORM func-tions for the courseware, and then trans-late the requests into AICC HACP interac-tions with the LMS. This approach wouldrequire that the LMS be AICC-compliant,but that is the only requirement. The APIfunctions would allow the hosting of bothAICC and SCORM courseware yet the LMSwould only know of AICC courseware. Themajor limitation is that the LMS would nowonly be able to track AICC information,thus preventing upgrades to support futureSCORM capabilities (such as sequencing)unless the AICC specification implementedby the LMS also supports the identicalspecification.

While this solution would not satisfy theleading-edge distributed learning applica-tions that are focused on advancing thestudent’s experience through the use ofsequencing and other advancements, itwould allow for enterprise distributed learn-ing systems to deploy both SCORM andAICC courseware to distributed users.

The advantages of AICC HACPThe advantages of the AICC HACP speci-

fication to enterprise architectures arebased on the underlying design of thespecification. The AICC HACP specificationdoes not require the use of either Java-Script or ActiveX and thus does not haveeither of their security limitations. TheAICC HACP specification uses conventionalHTML request and response messages toexchange AICC IMS-based information.

Since the interactions between the con-tent and the LMS are HTML-based thereare additional requirements placed on thecontent. In the AICC HACP specificationthe content is required to manage moresession variables, extract information fromthe client’s universal resource locator(URL) line, encode and decode URL encod-ed strings, and most importantly, know theaddress of the LMS server. The complexityof implementing the HACP specificationincreases when the architecture includesremote courseware servers located in dif-ferent domains and security policiesrestricting plaintext transmissions via HTTP.

ConclusionOne conclusion that can be derived from

this article is the acknowledgement thatowners of enterprise distributed learningsystems are forced to adopt technologiesoriginally developed for the typical campus

8FE

BR

UA

RY

18,

20

03

/ T

HE

EL

EA

RN

ING

DE

VE

LO

PE

RS

’ JO

UR

NA

L

FIGURE 4 Porting the API Adapter to the remote content server allows courses toaccess the API.

THE

EL

EA

RN

ING

DE

VE

LO

PE

RS

’ JOU

RN

AL

/ FEB

RU

AR

Y 18, 2

00

3 9

learning environment and manipulate them tomeet their unique organizational goals. Thedevelopers of the SCORM specification and themanagers of the network security policiesemployed by DoD appear to be moving alongdiverging paths. Until the ADL community recog-nizes the current limitations of implementingSCORM in enterprise environments, distributedlearning providers will be forced to find solutionsoutside of SCORM or continue to use sub-opti-mal distributed learning management architec-tures which are undesirable cost drivers for thetraining organization.

AUTHOR CONTACTJeffrey C. Engelbrecht is a Senior Information

Technology Engineer at the MITRE Corporationand has been a key architect for distributedlearning programs since 1997. He holds aBachelors and a Masters degree in ComputerScience from Virginia Tech. Jeffrey has func-tioned as one of the key architects for theMarine Corps Distance Learning Program(MarineNet) since its creation in 1997. For theMarineNet program, he has been involved in vir-tually all aspects of distributed learning with par-ticular focus on Learning Management Systems(LMS) and courseware integration and fielding.He was the lead developer of the Marine Corps’first LMS and he has played a key role in theevaluation and selection of all successors. Hewas also the primary author of the Marine Corpstechnical courseware development manual.Currently at MITRE, Jeff leads the research onidentifying the solution for implementing SCORMin the MarineNet architecture. Jeff can bereached by email at jengelbrecht@mitre.org.

ONLINE DISCUSSIONSExtend your learning beyond the printed page!

If you are looking for more information on thistopic, if you have questions about an article, or if you disagree with a viewpoint stated in thisarticle, then join the online discussions andextend your learning.

Follow these easy steps to participate:

1. Go to www.eLearningGuild.com and sign in.2. Click on the Online Discussion button on

the main menu.3. Using the pull down menu, select the Online

Discussion: Journal Topics4. Select this article from the Subject list.5. Click on ADD A NEW MESSAGE.6. Enter your message. It will be posted as soon

as you hit the Submit button on the form.

Additional information on the topics coveredin this article is also listed in the GuildResource directory.

The eLearning Guild™ isa Community of Practicefor designers, developers,and managers of e-Learn-

ing. Through this member-driven community,we provide high-quality learning opportunities,networking services, resources, and publica-tions. Community members represent a diversegroup of instructional designers, content devel-opers, web developers, project managers, con-tractors, consultants, and managers and direc-tors of training and learning services — all ofwhom share a common interest in e-Learningdesign, development, and management.

The eLearning Developers’ Journal™

The Guild publishes the only online “e-Journal”in the e-Learning industry that is focused ondelivering real world “how to make it happen inyour organization” information. The Journal ispublished weekly and features articles writtenby both industry experts and members whowork every day in environments just like yours.As an active member, you will have unlimitedaccess to the Journal archive.

People Connecting With People

The Guild provides a variety of online membernetworking tools including online discussionboards, and the Needs & Leads™ bulletinboard. These services enable members to discuss topics of importance, to ask others tohelp them find information they need, and toprovide leads to other members.

Resources, Resources, Resources

The Guild hosts the e-Learning industry’s mostcomprehensive resource knowledge database.Currently there are over 2,300 resources avail-able. Members have access to all of theseresources and they can also post resources at any time!

Guild Research

The Guild has an ongoing industry researchservice that conducts surveys on 20 topicseach year. These topics are identified by theResearch Advisory Committee. The data collect-ed is available for all members.

It’s About Leadership

The Guild draws leadership from an amazingAdvisory Board made up of individuals who pro-vide insight and guidance to help ensure thatthe Guild serves its constituency well. We arehonored to have their active engagement andparticipation. The Guild has also establishedthree committees made up of active memberswho help steer its editorial, events program andresearch efforts.

Discounts, Discounts, Discounts

Guild members receive discounts on all Guildconferences and on other selected productsand services. Your Guild membership will saveyou 20% off the list price of Guild events!

Join today at www.eLearningGuild.com!

Become a member today! Join online at www.eLearningGuild.com.

THANK YOU TO THESE GUILD ENTERPRISE SPONSORS

To learn how to become a Guild Enterprise Sponsor, please contact David Holcombeat dh@eLearningGuild.com or call 707.566.8990.

Spectra InteractiveLearning is a unique,full service, e-Learn-ing consulting com-

pany — growing and expanding in NorthAmerica and Europe to meet the grow-ing need for expertise in e-Learningstrategy development, instructionaldesign and program implementation.www.spectrainteractive.comContact: Brenda Pfaus, Presidentbpfaus@spectrainteractive.comOttawa, Canada (613) 230-9978

Cyclone Intera-ctive is an inter-active media and

web development firm creating online, CD and presentation solutions for a wide range of clients and industries. www.cycloneinteractive.com Contact: Earl Dimaculanganearl@cycloneinteractive.com617.350.8834

CLARK Training &Consulting (CTC) is a glob-al leader in instructional

design offering both training and con-sulting services. Our award-winningseminars are based on the latestresearch in instructional psychologyand human performance improvement. www.clarktraining.comContact: Kimberly Perkins602-230-9190

About the Guild

Because the mostdramatic learning happens through

first-hand experience, everything we do is focused on creating experiences —engaging, challenging and yes, fun, expe-riences — that people will take back towork and use every day to improve theirperformances.www.alleninteractions.com Contact: Jackie McMillanjmcmillan@alleni.com800.204.2635