CopperCore Technical Documentation

 Interfaces

CopperCore is a Learning Design engine capable of processing IMS Learning Design. It is not designed be used as a stand-alone learning environment but to be used in a service oriented framework. Such a framework consists of different services that are combined to create a complete e-learning system. CopperCore implements a service that processes learning design.

Services are implemented as software components that provide well defined functionality. To expose the functionality of a service each component provides one or more well defined application programming interface. These interfaces form the contract between the service provider and the service consumers. To prevent unwanted dependencies between the services the components hide their internal workings from the other components in the system.

CopperCore implements four interfaces: CopperCore, CopperCoreAdmin, LDEngineDelegate and the LDCourseManagerDelegate interface. These interfaces are grouped in two packages that each have their specific usage. The first package is the CopperCoreDelegate package. This package contains the LDEngineDelegate interface and the LDCourseManagerDelegate interface. This interface is a native Java client façade interface. This package is used by other components that need to call CopperCore via a native Java interface. It is a client façade package because the package itself is used in the context of the Java service consuming the CopperCore service. The second package is the CopperCoreSoap package. It consists of the CopperCore and the CopperCoreAdmin interface. As the name already implies these interfaces are SOAP interfaces and enable other services to call the CopperCore service via the SOAP protocol.

Internally the CopperCoreSoap interfaces make use of the two CopperCoreDelegate interfaces to provide the functionality of CopperCore to the service consumers. Both packages provide the same functionality but they enable different kinds of service consumers to connect to CopperCore.

The following figure shows the packages with their respective interfaces. For each interface all operations of that interface are shown. It shows clearly that both interface packages expose the same functionality. Although the interfaces contain the same operations their parameters and return values are not always exactly the same. This stems from the differences between the calling protocols of Java and SOAP.

 

Figure  1 CopperCore interfaces

 

All these interfaces are documented using javadoc. Some of these operations return strings containing xml. Mainly the operations from the CopperCore interface (and its twin companion LDEngineDelegate) return these xml blobs. These xml fragments represent fragments of the original LD. They consist out of those parts of the LD that are relevant for the operation that returns them. So for example the getActivityTree operation returns a personalized subset of the LD method section. These schemas for these xml fragments are documented on the CopperCore site (http://coppercore.org).

Service implementation architecture

Figure 2  Service implementation architecture UML model

The figure gives an overview of the layered architecture of CopperCore. The bottom three layers form the actual CopperCore component implementation and the other two represent the two interface packages that expose the functionality of the LD service either via a native Java interface, the client façade package, or via the SOAP protocol, the CopperCoreSoap package.

The Data access layer is responsible for all direct interactions with the database and uses BMP entity beans to access the database. A major component in this layer is the dossier package which provides low level access to properties. Not only does CopperCore implement LD properties, it reuses this concept to store the learning design and to keep state of each individual’s progress through the learning design. The other components deal with course administration, which involves concepts like users, runs, unit of learning etc.

The next layer of the architecture is the Business layer and contains all components representing the business logic of CopperCore. The parser and the validator package implement the business logic for importing (parsing) and for validating an IMS LD package. This functionality is exposed via the CourseManager. The other business components either represent course management components like users, runs, uols etcetera which are also exposed via the Coursemanager or they represent parts of the learning design that are directly or indirectly accessible through the Engine. These latter components are grouped in the component package. Each component contains all the business logic it needs to adapt itself to the profile of the user accessing the LD component. For this purpose the container makes intensive use of the property mechanism which contains its own business logic about retrieval and storage of properties.

The next layer is made up out of three session beans. The first bean is the LDCourseManager bean. It deals with all administrative calls necessary in preparation of delivering an IMS LD instance. Typical interface offered deal with the publication of an XML LD instance, creation of user, creation of runs and assignment of roles. This layer only imports an IMS LD manifest instead of a complete content package. This is due to restrictions in the J2EE application server regarding accessing the file system.

The second bean is the LDEngine. This is the heart of the delivery mechanism. This bean deals with the personalization of the IMS LD instance for a particular user at a particular moment in time. Typical calls that deal with the retrieval of personalized activity trees, environment trees and content are available.

The third and last bean is the Timer bean which deals with all time constraints formulated in LD. This bean should be called on regular intervals.

The fourth layer is the Client facade. It is made up of business delegates that implement a native Java interface to the CopperCore EJB components. They contain all code to make the actual connection to the EJB interfaces, making life easier for implementers. The layer adds the additional functionality to validate the IMS LD content package. Several checks are made to see if the package is complete, if the learning design is well formed and valid against the schema and if the learning design is semantically correct. Further the layer enhances the import functionality of the ejb bean layer by adding explicit validation before actually importing the package. This prevents the uploading of invalid content packages into CopperCore. Importing itself is enhanced by allowing the import of a complete content package. The client façade is responsible for unpacking the package and storing all resources in a specific location on the file system. The imsmanifest file which is a required part of the content package is passed to the ejb layer where it is imported into CopperCore.

 The fifth layer adds a SOAP interface to CopperCore by exposing the delegate interfaces through Axis SOAP toolkit for Java.

Figure   3 UML component diagram of CopperCore interfaces

 

The figure above shows the different interfaces and the relationship between them. The CopperCore layer provides three interfaces through EJB’s which are LDEngine, LDCourseManager and Timer. These three interfaces are used by CopperCoreDelegate encapsulating the intricacies of calling the remote EJBs. The CopperCoreDelegate exposes it’s functionality through three Java APIs. We expect that client application never will call the EJBs directly but always use the CopperCoreDelegate or the CopperCoreSoap interfaces. The latter only has two interfaces because we expect that the timer handling is done on the J2EE application server.