|
Search | Back Issues | Author Index | Title Index | Contents |
 |
D-Lib Magazine
|
|
Daniel R. Rehak Nick Nicholas Nigel Ward |
|
AbstractEducation resources and learning objects are stored and maintained in a multitude of collections and repositories. Having multiple, distributed sources makes resource discovery, access and use overly complex for most users. Resource federations provide a single point of discovery and access to a larger number of resources. In this paper we present a service-oriented model for a scalable infrastructure that supports resource federations for educational content, including support for publishing, federated search, federated metadata registries, and federations of federations. The model is driven by overall business requirements and provides services that support the broad range of capabilities needed to create, use, maintain and manage a resource federation. The services themselves provide abstract interfaces to the resources, repositories, collections and federations and are independent of actual implementation technologies, but utilize open standards for technological interoperability. In addition to the overall federation model, we outline the components of a broader service-oriented infrastructure for managing education resources and describe how the services from the federation model can be incorporated into end-user applications. Our models are fully detailed and documented using the approach from the e-Framework for Education and Research, an open service-oriented approach used to model and describe educational and research technology systems. 1 IntroductionHow do you find learning objects? Using one of the popular web search engines is often ineffective in trying to find learning objects. If available, learning objects are not readily differentiated from other web resources. But more importantly, the content of educational resource collections usually is not included in the search engine web crawl; the resources are hidden within repositories not accessible by the crawler, or the crawler does not support the repositories' harvest and discovery interfaces. Thus, several organizations have formed their own educational resource federations, e.g., the ADL-Registry [1], ASPECT [2], GLOBE [3], LORN [4], LRE [5], MELT [6]. Each of these federations has established its own rules for participation and its own model of a resource federation. While these community federations provide an effective means to discover educational resources, all of the capabilities that a user may require or desire (e.g., publishing, harvesting, accessing, delivering, annotating, classifying, tagging, ranking, browsing, syndicating) may not be supported, or most likely will be supported in different ways in different federations. Such differences may not be important, or even obvious, to an individual instructor or student trying to find resources, but they present challenges to a developer who wants to integrate the federation into their environment, or to a more sophisticated user who wants to create a mashup of tools or widgets. Across these federations, the capabilities vary, the data formats and representations are different, and the behaviors are inconsistent. The multitude of different conceptual models, collections of features, and interface technologies results in complexity. Even if a single federation arrives at an agreed set of interfaces, tools such as content editors or virtual learning environments may want (or need) to interface with multiple federations. Different educational resource collections and repositories may want to participate in different federations. No single solution will meet the needs of all communities, and selecting the lowest common denominator may not satisfy core requirements. One approach to address part of this mismatch is for the federations, the tools, and the underlying repositories to use interoperability standards. However, there are competing standards, thus adding to the complexity, and many interoperability standards address only technical issues, e.g., defining particular data models and representations. They do not specify how the representation is used to provide a useful behavior, e.g., the data model is expressed only as an XML schema, and cannot be used without using that technology. Additionally, they may not specify a conceptual data model: the standard is defined in terms of a single technology binding, so it cannot be used when a different binding is needed, and it does not establish what the components actually mean for the business. Other standards may describe behaviors but may be tied to a particular interface and messaging standard, e.g., the standard is defined only as a web service in WSDL using SOAP over HTTP. Thus, standards alone are not the solution. A complementary approach is to describe the behaviors of the federation in terms of independent "services", where a service provides an interface that exposes a behavior to clients, but hides details behind the interface; invoking the service results in a response or a change in the state of that which the service manages [7]. A consistent set of services, defined through their standardized interfaces, allows any client or user to integrate with any repository, federation or other tool that supports the service interface. But again, no single set of service definitions currently exists. While the service abstracts the behavior from the details, an implementation still requires the full specification of all the details for the interface and behavior. Often these are documented by standards. Even though the services needed to create and operate a resource federation may not yet have been fully defined, a service-oriented approach has promise. A service-oriented approach focuses on the business problem by modeling capabilities and then aligning services with needs. The service-oriented approach abstracts service interfaces from their underlying technologies. This allows technology-independent comparison of systems and provides models that can withstand technological change or that can be used with different technologies. The service-oriented approach relies upon existing standards to define representations and behaviors. The service-oriented approach is distinct from service-oriented architecture in that it does not require implementations to follow a particular architecture. In this article, we describe a comprehensive service-oriented model for building and using educational resource federations. The model is driven by business needs and organized around reusable, composible services. It advocates a service-oriented approach (not a service-oriented architecture) and does not tie the definitions of services to any particular implementation or messaging technology. The model assumes services, data and behaviors are represented, primarily, in formal standards or specifications. The model is fully open (published under a Creative Commons license) and formally documented. It can be used to describe different types of resource federations, with different features, capabilities and operational models. The service-oriented model of resource federations provides an informed vocabulary of modeling terms, services and standards that can be used in different ways: to describe and compare the structure and organization of different federations; to understand how standards are used or needed to provide interoperability within resource federations; and to design and build operational educational resource federations. In addition to describing how the model could be used, several applications of the model are presented. 2 Federation Business ModelingWhat are the business objectives for an educational resource federation? The primary goal of a resource federation is to form a single interface point to a group of educational content repositories or collections, for the purpose of discovery and access to the resources. Such a federation addresses the problem of finding and accessing disparate content sources by presenting the educational resources in a consistent manner. A user can view the resource federation (presented through a portal or search interface) as a single entity. The federation hides the complexity and differences between the individual repositories, and integrates their collections into a larger, single entity. The resource federation provides:
From a business perspective, the resources are assumed to remain in the repositories that are part of the federation, allowing the repositories to impose their own access controls, operational and business models. Participation in the federation is managed; governance and business rules establish service-level agreements between the participating repositories and the federation. While a resource federation could be used for many purposes, the federation model described focuses on educational and learning resources. An educational resource is assumed to be described by educational metadata standards. Other appropriate educational content representation and packaging standards may be used in conjunction with repository and registry standards. The capabilities of the repositories in the federation, and the capabilities of the federation as a whole, are exposed through "services". These services can be used by other systems directly, integrating the resource federation into their scope, e.g., imbedding the resource federation publishing service in an authoring tool. Or the services could be used to build end-user applications, such as a discovery portal. The layering of applications over the federation, and the layering of the federation over the repositories themselves, through services and interoperability standards, is illustrated in Figure 1 [8]. The registry element shown within the federation supports many of the key capabilities of the federation. Two alternative business models are supported:
In either case, the registry also contains information about the individual repositories in the federation and their capabilities.
Illustration Copyright © 2009 LSAL and University of Southern Queensland. The illustration may be used under the Creative Commons Attribution-ShareAlike 2.5 Australia License [http://creativecommons.org/licenses/by-sa/2.5/au/]. The appropriate attribution for a derivative is: "This illustration is derived from work created by the LSAL and Link Affiliates 2009." The Illustration is derived from work created as part of the Federated Repositories for Education (FRED) project under the Australian ADL Partnership Laboratory in 2007. Original Illustration Copyright © 2007, University of Southern Queensland and University of Memphis. Combinations of these models can also be used, and may incorporate other approaches, such as harvesting the resource itself, e.g., to provide an escrow capability or permit direct access to the resource from the federation registry. The model also supports learning objects being stored in repositories (as physical entities) and in resource collections (as logical entities). Resource collections may span repositories. The resource federation supports three types of users, each with different primary motivations:
In all cases, the capability may be provided to a person directly through an end user interface such as a portal or the capability may be used by a software agent via a service. For example, resource users include teachers, students and tools such as virtual learning environments; resource managers include authors and authoring tools. The key capabilities, from requirements [9], supported within each group are listed below. Resource Discovery Capabilities:
Resource Delivery Capabilities:
Resource Management Capabilities:
System Management Capabilities:
3 Business-to-Service ModelingHow do you go from business models to services? The business modeling above outlines the capabilities of the federation. The process supporting each capability may involve a multi-step workflow, with any mixture of manual and automated steps. Each of the steps uses one or more of the defined services needed to support the resource federation. A complete service model maps the functionality for each capability to business processes. The business process centers on the workflow needed to provide the capability. The workflow choreographs a set of services, passing requests and responses between the services. The overall process and its constituent services are tied to particular key targets, e.g., the discovery via search of the federated metadata registry is targeted at the metadata registry; obtaining from a resource repository is targeted at the repository; the overall process of getting content is targeted at the repository. The overall mapping of capabilities to business process, and then to services and their associated targets is shown in Figure 2 (system management capabilities have been omitted for simplicity). This provides an easy-to-understand, high-level view of the entire resource federation business and service model. Each column presents the key components supporting a capability. Grouping across columns indicate sharing and reuse of common services and business objects in the federation. In the services layer, individual services are differentiated from compositions of multiple services (compositions such as Access Management are shown in bold). Details of these compositions are described in other business models, and are thus abstracted from this model, for simplicity.
Illustration Copyright © 2009 LSAL and University of Southern Queensland. The illustration may be used under the Creative Commons Attribution-ShareAlike 2.5 Australia License [http://creativecommons.org/licenses/by-sa/2.5/au/]. The appropriate attribution for a derivative is: "This illustration is derived from work created by the LSAL and Link Affiliates 2009." The Illustration is derived from work created as part of the Federated Repositories for Education (FRED) project under the Australian ADL Partnership Laboratory in 2007. Original Illustration Copyright © 2007, University of Southern Queensland and University of Memphis. The resource federation model includes the processes listed in the table below (for brevity, system management processes are omitted). Each entry summarizes the process: identifies the capability, lists the core service in the workflow, identifies the primary target of the service and links the process to a business capability. In the complete model [8], [10], each process is fully detailed and includes the workflow in pseudo code and enumerates all services, business objects and external systems used. A more detailed prototypical description of a business process is illustrated in Figure 3.
Figure 3. Prototypical Business Process Description 4 e-Framework Service-Oriented Modeling ApproachWhat is the formal modeling approach used to document the resource federation model? The service-oriented federation model is fully documented using the service-oriented approach from the e-Framework for Education and Research [11], [12] an international joint collaborative effort developing both service-oriented models and a methodology for describing service-oriented systems. The e-Framework provides a consistent vocabulary used to document service components, and a knowledge base of service-oriented artifacts designed for adoption and reuse. These reusable components are based on identified standards (de jure, de facto or informal), and are designed to provide plug-and-play interoperability.4.1 Service Usage Models: Business-Oriented CompositionsThe complete federation model, developed in the Federated Repositories for Education (FRED) Project [13], is documented in a set of discrete, interrelated components following the e-Framework model. The core of these descriptions is two Repository Federation Service Usage Models [8], [10]. In the e-Framework, a Service Usage Model (SUM) describes a composition of components that addresses a specific business problem area and can be used to design, deploy and compare applications and software systems that follow the SUM. A SUM describes a service-oriented solution to a business problem and builds upon reusable service descriptions. The documentation of a SUM includes an overview of goals and objectives, augmented with a description of use cases and business modeling that detail overall behavior of the solution. Together these provide a business-oriented view of what the SUM does and how it solves the designated business problem. The different business capabilities provided by the SUM are individually detailed within the SUM by mapping the capability to a process and workflow that choreographs a set of services (or SUMs) operating on a set of business objects (managed resources, data, requests, external systems) to meet the established business requirements. These business processes describe, in an implementation-independent manner, how the services are combined to solve the problem. This description is augmented with information outlining how to structure and implement the solution in an actual software design, though it does not specify the design itself. The SUM identifies all the services, other SUMs, business objects and standards that are used in the solution; all are linked to their descriptions in the e-Framework knowledge base. The SUM as a whole can be used to design and implement software systems that provide the designated capabilities and utilize the identified services, it can be used in other SUMs, or can become the basis for other derivative works. 4.2 Service Genres: Classes of ServicesWithin the e-Framework, the services that provide discrete functionality are documented individually. An e-Framework service description provides a formal description of the interface to a discrete behavior. The e-Framework model separates a technology-independent, abstract description of a service from the descriptions that use specific implementation approaches and specific standards. The general description of a service is denoted a service genre. It describes, in business terms, what the service does, how it is used, and when it should or should not be used. The description documents the interfaces to the service through a list of function points, each defined by a set of service requests or responses and the corresponding business objects and data passed between the client and service. The description does not otherwise describe how those requests and responses are formulated. Each function point defines a single behavior. All of the data and behaviors reference classes of standards that describe the data representations and behaviors. For example, the search service genre defines a search function point that has a query request and a query response set. Within the service genre, the query request would be defined in terms of the conceptual class of query language standards (i.e., the collection of all query language standards), not a particular query language. Like a SUM, a service genre description includes general information describing how to design and implement the service in software and includes links to all the associated items in the e-Framework knowledge base. 4.3 Service Expressions: Interoperable Service DefinitionsEach service genre is further detailed in one or more service expressions. A service expression description takes a service genre description and provides additional details about exact interfaces and standards used as an aid to interoperability. The general description of the service from the service genre is specialized to a specific description used to create an actual operational service. The scope and capabilities of the service expression is a subset of its parent service genre. The standards, representations, data models and behaviors for all of the requests or responses are specified and fully defined, e.g., using the search example above, all of the specific query languages supported by a specific search service would be specified. A messaging technology is selected (e.g., web services/WS-*, REST, POX, CORBA) and a machine-readable interface definition is provided. For example, a harvest service genre might be specialized into many different service expressions: one that uses OAI-PMH as its overall model and communicates via web services, harvesting Dublin Core metadata; or one that uses OAI-PMH with a POX interface and harvests LOM metadata, etc. Service expressions can be handed to developers for implementation and deployment. While the service expression description includes general implementation guidance, a developer is free to choose implementation technologies, e.g., Java, C++, etc., the internal organization, and system-internal data models, but should not make any design choices that impact interoperability. Since the service expression description provides the formal interface definition for the service, these different implementations and deployments are designed to be interoperable. Thus, for example, an initial rapidly-developed prototype implementation for a service expression could be directly replaced with a more robust, enterprise-scale solution. 4.4 Model and Knowledge BaseThe e-Framework model defines the various components of the e-Framework (SUMs, service genres, service expressions, etc.) and the rest of the e-Framework vocabulary, along with guidance and best practice documents on how to use the e-Framework to describe service-oriented systems. The e-Framework knowledge base contains a collection of artifacts including SUMs that describe specific service-oriented systems and the reusable service genre and service expression descriptions that can be implemented and deployed to support SUMs and other applications. 5 e-Framework Description of a Resource FederationWhat goes into the description of an educational resource federation? The service-oriented resource federation model is documented in several e-Framework artifacts. 5.1 Service Usage Models: CompositionsThe overall FRED model of a resource federation is defined in two SUMs. The primary is the "resource" SUM [8] that describes all of the capabilities for 1) resource object discovery and delivery: finding and getting learning objects from registries and repositories in the federation; and 2) resource management within the federation: publishing resources to repositories, updating registrations, etc. This SUM addresses the capabilities described above. The second is the "provisioning, operations and maintenance" SUM [10] that describes how to initially set up and then operate and manage a federation, e.g., initial provisioning of system registries, managing users, providing backup, archive and escrow capabilities, inspection, monitoring, and analytics. These capabilities are split from the first SUM since they address a different audience: federation administrators versus federation and educational resource end users. 5.2 Services: Reusable ComponentsThe FRED SUMs are built upon several other SUMs and 30+ individual services. Many of these services provide basic capabilities used in other service-oriented systems, e.g., filtering results, packaging data, transforming data, transaction logging, basic data collection management. Other services are related to infrastructure capabilities such as managing identity, authentication, authorization and providing an identifier infrastructure. e-Framework précis (short definitions) for services that can be used to model education resource federations are listed below [14]. Component names and précis are harmonized across all components in the e-Framework, providing a single vocabulary for a broad range of business and service models, enabling broader service-level interoperability. Note, to focus the description on educational resources, the e-Framework service genre précis have been modified in the presentation below; in general, the service genres are defined to operate on any type of business object, not just learning objects. Service expressions used to fully define a resource federation would specialize the service genres. While the service genres are defined in terms of general business objects, the corresponding service expressions operate on educational resources and learning objects that are defined and represented using appropriate learning object, education resource and related domain-specific interoperability standards. Resource object management and transformation services provide basic operations on an individual resource or learning object, either directly or on objects that are part of a data collection (e.g., repository, registry):
Data interchange services aid in communicating data between end points:
Metadata services manage data associated with other learning or resource objects:
Notification services support communications:
Operational data management services provide operational support:
Authorization and authentication services control access:
Logging and audit services record and process event records:
Several key services are specific to the resource management and learning object domain. Complete service genre descriptions have been developed for these [14]:
In projects such as FRED [13] and D3UI [15], one or more service expressions and corresponding service implementations have been developed for each of these service genres. 5.3 Standards: Interoperability DefinitionsThe e-Framework approach identifies the standards needed (or lacking) to provide business-level service component interoperability. These standards are distinct from the technical interoperability standards for messaging, service behavior and representation standards, such as XML, SOAP, WS-*, HTTP. The classes of domain standards used within the FRED SUMs and services, and useful in modeling resource federations, include:
Service expressions for each of the service genres listed above would specify all of the actual standards used or profiles of these standards, or would note where standards are missing and where the service uses its own or a community agreement for data representation and behavior specification. As noted, the behaviors and representations used in a service expression need to be fully specified to ensure plug-and-play interoperability between multiple implementations of the same service expression. 6 Resource Federation Model Design and Design AssumptionsHow do you design an educational resource federation using the model? The FRED SUMs and related services do not describe the complete design of a single federation. Rather they describe many of the capabilities that any given federation might include. Some of these capabilities are essential for any federation, e.g., search or discovery, while others provide "value added" features, such as harvesting from the federation. A particular federation will need to profile or specialize the FRED SUMs and services, selecting what capabilities to provide, extending the SUM when needed capabilities are missing, picking what standards to use, and deciding how to structure the design of an overall application. Each of the component services needs to be specialized in service expressions, thus defining all resource and learning object models and representations supported by the federation, actual service interfaces, user interfaces, operating rules, policies, etc. The FRED SUMs are designed to be a part of a larger service-oriented infrastructure for education. That infrastructure model includes a SUM describing an identifier system [16], [17] and one describing identity and access management (some of the services from these SUMs are listed above) [18]. The FRED model further assumes other SUMs that define additional capabilities such as managing individual repositories and data sets (e.g., the searchable collection SUM) and providing end-user interfaces or portals to the federation. While end-user authentication and authorization are included in the SUMs, the model assumes that most of the underlying services operate within a known trust environment, and that access to and control of services within the trust boundary is different from access by external agents. Individual requests from external agents must be fully authenticated and authorized. Services called from within the federation, by the federation, may be implemented with fewer and less stringent controls. The design of an actual federation will dictate the security requirements and resulting trust controls for individual services. The model does not include details of how to manage resource access. Even in "open resource collections" some access controls are needed, e.g., particular cultures or communities may impose cultural-based restrictions on who can discover or access resources, or during an assessment, a learning management system or virtual learning environment may restrict access to resources. The model assumes these controls can be added to the defined services; access management is a shared responsibility of the federation and the individual repositories. All workflows, however, do include satisfying access constraints and obligations as one of the key steps in the service choreography [19]. Most of the defined service genres specify only a single behavior. While this increases the number of services, it increases potential reuse of any service and simplifies modeling. It's important to remember that a service genre is just a logical description of capabilities. Actual deployed software may combine the implementation of multiple services and function points into a single unit of code that is deployed at a particular network end point. The resource federation model does not specify (nor restrict) most implementation choices. For example, an actual federation might use simple tools and underlying software, or might be built using enterprise-grade components. Likewise, a federation might be deployed on a single hardware platform, or may require distributed or replicated servers and multiple service instances and resource sets for load balancing and performance. The SUMs do not specify the design or details of the implementation of a particular application or system. Each application will make the appropriate choices based on its requirements. One design view of the resource federation, combining a repository federation, a metadata registry, and using web services, is illustrated in Fig. 4 [8]. The diagram includes the services from the "resource" SUM and the "provisioning, operations and management" SUM.
The SUM does not define a single or an overall application through which users and administrators access the federation. Applications would be independently designed and layered upon the services and SUMs. Other than using the shared metadata registry and system resources, the services are independent and uncoupled. The resource collections and repositories that participate in the federation expose their own service interfaces, but logically, these repositories are external to the federation, i.e., they are owned, managed and maintained by their respective owners. These repositories must agree to service-level agreements to participate in the federation. They may also expose other services and interfaces to clients outside of the federation, but such interfaces are not modeled. Further details of the design assumptions and implementation guidance are provided in the SUMs, service genre descriptions and service expression descriptions. 7 How to use the Resource Federation ModelHow can the service-oriented model of an educational resource federation be used? While the federation model was developed specifically to document and develop a service-oriented infrastructure for discovery and sharing of learning and resource objects, the model serves a variety of additional purposes. A Vocabulary for Shared Communications and Analysis. The federation model components, along with the e-Framework methodology, provide a vocabulary of terms and a list of services and standards used to describe resource federations. Many of the terms commonly used to describe business modeling and service-oriented systems are not well defined or have multiple, conflicting definitions. The e-Framework model provides a consistent, well-defined glossary of specific terms and a documentation strategy for defining service-oriented systems. The list of services provides a set of names and specific definitions of business processes and associated behaviors. Having this vocabulary has proven useful in discussions; communication within a community is not hampered by terminological misunderstandings and communication is more precise. The model, along with the use of a consistent set of service names and definitions, enables the comparison and analysis of different approaches and potentially a way to compare and contrast other similar federation models. Institutional Planning and Provisioning. Identifying the range of service expressions and business objects needed to implement education federations helps infrastructure planning. From a SUM-based analysis of proposed or functioning systems, planners can identify recurrent services and prioritize them for centralized provisioning. e-Framework analysis can also help abstract from deployed systems in a domain to an abstract set of services common to all of them. Because the e-Framework uses a service-oriented approach rather than a specific architecture, such analysis can proceed even if some of the deployed systems are monolithic and not built on services. A Source for Derivative Models. As previously noted, the model does not describe a specific resource federation. The model is similar to a reference model: it outlines a general approach. Different specific models can be derived from the more general model; examples of such use are described below. These derivatives can originate at the business level by selecting (or extending) the business capabilities to be supported, or at a more technical level by redefining the behavior of the business process and the overall structure of an implementation. Each of the different service genres can be specialized into any number of service expressions, each defining different specific interfaces and specific behaviors taken from the selected standards. Thus many different resource federations can be realizations of the original model. Note, all of the e-Framework artifacts are published under Creative Common Licenses to encourage such reuse and adoption. An Implementation Guide. While the model does not provide the details needed to create a specific implementation of a resource federation, the model (or a derivative) does provide sufficient high-level information that can be used to design a complete federation. The model outlines assumptions, applicability criteria, a schematic design and implementation guidance; all of these can be considered when developing the actual implementation. Furthermore, each of the service expressions provides a concrete description that can be implemented directly. An Exemplar of e-Framework Modeling. The FRED SUMs and the related services and SUMs are one of the largest examples of use of the e-Framework model approach. While developing an exemplar was a secondary goal, the experience in developing the components has helped to refine the e-Framework modeling approach, its vocabularies and its recommended practices. Such modeling refinements are consistent with the overall goal of having the e-Framework continually evolve based on use and feedback. Interoperability Standards Identification. Within each service genre and service expression, all of the data exchanged between the service and the client, and the behaviors of the services, need to be formally defined, preferably by referencing appropriate representational or behavioral standards. Thus the services clearly identify where, how and what kinds of standards (open, proprietary, de jure, de facto) are used to address business needs. When standards and specifications do not exist, the component description will reference a community approach, or a service-specific solution. These cases may be used to identify where new standards are needed. Since the same standard may be used by different services within a SUM, a consistent approach to using the standard is needed; thus standard use is harmonized across the entire SUM, and harmonization efforts may yield best practices of how to use the standard. Also, as service expression interface definitions are precise, standards must be examined to identity and clarify any ambiguities or to select a single solution when multiple options are defined by the standard or when the standard is designed to defer choices to implementors. 8 Applications of the Resource Federation ModelHow has the educational resource federation model been used? The services and SUMs of the FRED model for resource federations have been used in several other projects. Some of these applications are described. ADL-R. The ADL-Registry (ADL-R) [1], [20] is an operational repository federation with a central metadata registry. Operated by the US Advanced Distributed Learning (ADL) Initiative, the registry federates US Department of Defense managed learning content repositories. These repositories are manually registered with the federation, and publish LOM metadata records describing SCORM content packages to the central metadata registry. Users can search the metadata registry for content and are referred to the hosting repository to obtain the content. The ADL-R is a subset of the model described herein as it contains only some of the features described. SUMs for the ADL-R [21], [22] have been created as derivatives of the FRED SUMs, describing the subset of capabilities present in the ADL-R. Thus, the FRED SUMs provide the generic model that has been used to illustrate how the ADL-R is situated within the larger landscape of resource federation models. LORN. The Australian Vocational Education and Training (VET) Sector has developed a SUM that describes their Learning Object Repository Network (LORN) [4]. The federation consists of a set of repositories that are harvested to form a central metadata registry that is used for content discovery. The VET LORN SUM [23] is not a derivative of the FRED SUMs: it follows the same conceptual model, is a simpler SUM that uses the same vocabulary of services and is documented in the same manner. Additionally, the VET LORN SUM is defined using service expressions and actual standards (OAI-PMH for Harvest, The Australian VET profile of LOM for metadata, SCORM for content models, IMS Content Packaging for exchange), not service genres. It describes a real implementation derived from the more general model. Thus, the use of the e-Framework vocabulary provides a consistent document strategy, again permitting comparison and analysis of the different design choices and illustrating how to describe resource federation models at different levels of specificity. JADL IPA. The Joint ADL Integrated Prototype Architecture (IPA) is a model for an enterprise-wide learning environment, encompassing resource repositories, registries, structured learning experiences delivered through a learning management system, gaming or simulation, management of learner profiles and competencies, content authoring processes and linkages to human resource or educational administrative systems [24]. The IPA supports a life-cycle training process in an ADL environment. The IPA includes resource repositories, metadata federations (through the ADL-R), content authoring, publishing, discovery and delivery. A SUM for the IPA has been developed [25] that builds upon the ADL-R SUMs (and thus the FRED SUMs) and uses most of the services described herein. The JADL IPA SUM illustrates how to incorporate a resource federation model into a comprehensive service-based learning management and delivery infrastructure. D3UI. The ADL Deposit to Discovery to Delivery (D3UI) project [15] focused on how to provide seamless interfaces and integration of content authoring and resource delivery tools with resource federations. In one example, an open source content authoring tool/editor (Reload) was linked, via web-service interfaces, to a resource federation (the ADL-R), repositories (including those using DSpace) and other tools. The authoring tool was extended to support direct discovery from the federation, obtaining a resource from the source repository, automated metadata generation for the edited/revised resource, publishing (depositing) the revised resource back to the repository and updating the federation registry metadata for the modified resource, all within a single-sign on authentication environment. All content was labeled with persistent identifiers used throughout the management process (using the Handle System). The new application was documented as a SUM [26] that 1) interfaces with the services provided by the ADL-R SUM, and 2) uses other services from the FRED SUM that are not part of the ADL-R. The workflow that supports this service integration is shown in Fig. 5 [26]. In this application, the SUMs and services described herein provide the reusable building blocks needed to develop the application and interface with the registry and repositories. The services used to develop the integrated application specialize the service genres outlined herein. A set of service expressions, specific to the ADL-R and Reload environment, have been developed, documented and implemented.
9 ConclusionsRequirements gathering, business analysis and use cases help determine the scope of an educational resource federation. From these, the business modeling process yields a set of needed capabilities and business functions. The work described herein takes a general approach, attempting to cover a broad range of resource federation business capabilities as a base from which to extrapolate. In a service-oriented approach, these business capabilities are mapped to business processes, each of which choreographs a workflow of services. The identified services can be used in designing a federation, or can be reused in other systems. The FRED model enumerates these services, provides a particular composition of these services, and, as described, can be used as a prototype for modeling other resource federations, placing resource federations within the larger landscape of service-oriented educational computing systems. Using the formal service-oriented modeling and documentation approach of the e-Framework provides a way to separate the overall resource federation model from the model of the individual services; a way to split the general description of a service from its many possible forms that use different interface and messaging technologies; and a way to identify the role and use of interoperability standards both within the behavior and representation descriptions of a service and across multiple service interactions. The e-Framework approach and the FRED model provide a vocabulary of terms and list of services that can be used to model, document, analyze, compare, or implement a variety of different educational resource federations. The open licenses to all of the e-Framework artifacts provide an opportunity for the community to refine, reuse and build upon the work described. AcknowledgementsThe FRED SUMs and Services were developed as part of the Federated Repositories for Education (FRED) Project within the Australian ADL Partnership Laboratory, with work done through the University of Southern Queensland and University of Memphis. The FRED project was funded from October 2006 to June 2007 by the Australian Commonwealth Department of Education, Science and Training (DEST) under the Framework for Open Learning Programme and from July 2007 to December 2007 by DEST and the Australian Department of Innovation, Industry, Science and Research (DIISR) under the Systemic Infrastructure Initiative (SII) as part of the Commonwealth Government's Backing Australia's Ability - An Innovation Action Plan for the Future (BAA). The D3UI and JADL IPA work was funded in part by the Joint ADL Co-Lab under contract with the Workforce ADL Co-Laboratory at the University of Memphis. Any opinions, findings, conclusions or recommendations expressed herein are those of the authors and do not reflect the views of the Australian Government, the U.S. Government, the University of Southern Queensland, the University of Memphis or other project sponsors. References[1] ADL-Registry, <http://www.adlregistry.org/>. [2] ASPECT: Adopting Standards and Specifications for Educational Content, <http://aspect.eun.org/>. [3] GLOBE: Global Learning Object Brokerage Exchange, <http://www.globe-info.org/>. [4] LORN: Learning Object Repository Network, <http://lorn.flexiblelearning.net.au/>. [5] LRE: Learning Resource Exchange for Schools, <http://lre.eun.org/>. [6] MELT: Metadata Ecology for Learning and Teaching, <http://info.melt-project.eu/>. [7] C. M. MacKenzie, K. Laskey, F. McCabe, P. F. Brown, R. Metz (eds.), "Reference Model for Service Oriented Architecture 1.0," OASIS Standard, 2006, <http://www.oasis-open.org/specs/index.php#soa-rmv1.0> [8] D. R. Rehak, N. Nicholas, N. Ward, K. Blinco, "Repository Federation Service Usage Model," version 1.0, 2008, <http://fred.usq.edu.au/eframeworkoutputs.html>. [9] D. R. Rehak, "Features and Requirements for Federated Metadata Registries," version 1.0, Technical Report, Workforce ADL Co-Laboratory, Memphis, TN, 2007 [10] D. R. Rehak, N. Nicholas, N. Ward, K. Blinco, "Federated Metadata Registry Provisioning and Management Service Usage Model," version 1.0, 2008, <http://fred.usq.edu.au/eframeworkoutputs.html>. [11] e-Framework for Education and Research, <http://www.e-Framework.org/>.
[12] B. Olivier, "Having Your Cake and Eating It: The e-Framework's Service-Oriented Approach to IT in Higher Education," EDUCAUSE Review, vol. 42, no. 4, pp. 58-67 (July/August 2007), <http://www.educause.edu/EDUCAUSE+Review/EDUCAUSEReviewMagazineVolume42/ [13] FRED: Federated Repositories for Education, <http://fred.usq.edu.au/>. [14] e-Framework Service Genre Registry, <http://www.e-framework.org/Default.aspx?tabid=655>. [15] D.R. Rehak, "D3UI: Deposit to Discovery to Delivery – A User-Focused Infrastructure for Content Management in an ADL Environment," Technical Report, Workforce ADL Co-Laboratory, Memphis, TN, 2007. [16] PILIN: Persistent Identifier Linking Infrastructure, <http://www.linkaffiliates.net.au/pilin2/>. [17] N. Nicholas, N. Ward, "PILIN Service Usage Model," version 1.1, Technical Report, Link Affiliates, 2008, <http://resolver.net.au/hdl/102.100.272/L8ZDW6PQH>. [18] Federated Identity and Access Management Service Usage Model, version 1.0, 2007, <http://www.e-framework.org/Default.aspx?tabid=854>. [19] D. R. Rehak, "Identity Management, Authentication, Authorization and Process Workflow for Federated Metadata Registries," version 1.0, Technical Report, Workforce ADL Co-Laboratory, Memphis, TN, 2007. [20] H. Jerez, G. Manepalli, C. Blanchi, L. W. Lannom, "ADL-R: The First Instance of a CORDRA Registry," D-Lib Magazine, vol 12, no. 2 (February 2006), <doi:10.1045/february2006-jerez>. [21] D. R. Rehak, "Service Usage Model, ADL-R Repository Federation," version 1.0, Technical Report, Workforce ADL Co-Laboratory, Memphis, TN, 2007. [22] D. R. Rehak, "Service Usage Model, ADL-R Federated Metadata Registry Provisioning and Management," version 1.0, Technical Report, Workforce ADL Co-Laboratory, Memphis, TN, 2007. [23] VET Learning Object Repository Network Service Usage Model, version 1.0, 2007, <http://www.e-framework.org/Default.aspx?tabid=942>. [24] JADL IPA: Joint ADL Integrated Prototype Architecture:, U.S. Joint ADL Co-Laboratory, 2006. [25] D. R. Rehak, "Evolving the JADL Integrated Prototype Architecture: Alignment with the e-Framework," Technical Report, Workforce ADL Co-Laboratory, Memphis, TN, 2007. [26] D. R. Rehak, "Service Usage Model: D3UI Content Authoring," version 1.0, Technical Report, Workforce ADL Co-Laboratory, Memphis, TN, 2007. Copyright © 2009 Daniel R. Rehak, Nick Nicholas, and Nigel Ward |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Top | Contents | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
D-Lib Magazine Access Terms and Conditions doi:10.1045/november2009-rehak
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
