...

The previous example demonstrated how to aggregate imported content into a Fedora digital objectDigital Object. There are many reasons why importing content into a repository might not be appropriate such as rights restrictions or the dynamic nature of the content. To accommodate these restrictions, digital objects in Fedora FDOs may contain Datastreams that reference externally managed content, and in fact may mix local and distributed data sources.

This section describes how to do this where the motivating example is the creation of a hypothetical learning object in an educational digital library, such as the NSDL}. The digital object FDO created in this example combines three frog images from the NSDL collection and some locally-managed text.

...

You're done! Figure 11 illustrates the role of the redirected Datastream at the time of digital object FDO access via the Fedora REST-based interface (API-A-LITE). You can see this by going to the digital object FDO profile page at: http://localhost:8080/fedora/get/demo:200

You can access the Datastreams for this digital object FDO by viewing the item linked to from the object profile page. Then, select the link for one of the redirected Datastreams. Fedora will redirect your browser to the location of the Datastream content, without streaming the content through the Fedora repository server.

{center}
!worddav908cefe719739375d93c8585ac14aa7e.png|height=289,width=545! 
*Figure 11 -- Example _Fedora Digital Object_ and Redirected _Datastream_* 
{center}

Using Fedora to Produce Dynamic Content

The examples described so far demonstrate the basic content aggregation features of Fedora. As mentioned already, the power of Fedora lies in its ability to associate the data in a digital object with web an FDO with Web services to produce dynamic disseminations. Some examples of this capability are as follows:

1. Rather than packaging multiple formats of a document as in Example 1, it is possible to have a digital object FDO with one Datastream in a source format (e.g. TeX) and then associate a service with the digital object FDO to transform the source format into multiple output formats (e.g. PDF and HTML). An obvious advantage of this is that any changes to the source format propagate out to the derived formats. Furthermore, less content is stored and/or duplicated in the repository.

• Rather than packing multiple metadata XML-based metadata formats in a digital object FDO, it is possible to package a single base metadata format in a digital object FDO (for example, fully qualified Dublin Core) and use that base format as the basis of metadata crosswalks. To do this, one could associate an XSLT engine (e.g. Saxon) service with the digital object FDO that processes the base format with a transform XSL document (packaged as a Datastream in another digital object FDO) to derive one or more additional formats.
  In both cases, static and dynamic, disseminations are available via REST or SOAP requests from clients to the Fedora Access service (API-A and API-A-LITE). The nature of the disseminated content – the format of the underlying data, where it is located, and whether it is static or dynamically generated – is invisible from the client perspective. As a result, a repository manager can significantly alter the nature of a digital object FDO and the web services that it uses while maintaining the same interface vis-à-vis the client. Correspondingly, two digital objects FDOs with entirely different structure can appear the "same" from the perspective of consuming clients.

The remainder of this section presents a series of examples demonstrating how to create digital objects FDOs that exploit web Web services. The initial examples make use of services available in the Fedora software release (they run as "local services" within the Fedora server container). Later examples demonstrate how to construct your own custom objects with external web services. Before proceeding with the examples, this introduction summarizes the concepts and defines the terms used in the examples. Don't worry if the concepts are not entirely clear at first. You should read them now and then refer back to them as you work through the examples.

Figure 12 shows an abstract view of the different components of the Fedora repository architecture that are key to how Fedora produces "disseminations" of digital FDO object content.

{center}
!worddavd2a3455b17ad8f4c77993ff48496a668.png|height=197,width=206! 
*Figure 12 -- Abstract View: Key Fedora Components for Producing Disseminations of Content*  
{center}

...

1. Client: Clients make requests for content disseminations through the Fedora Access service APIs (i.e., API-A-LITE and API-A). These interfaces include operations for discovering and accessing all disseminations that are available for a particular digital object FDO. A digital object FDO can have both static and dynamic disseminations, which are described below.
2. Fedora APIs: The Fedora repository service is exposed via a uniform set of APIs. Fedora's API-A and API-A-Lite provide operations (methods) for accessing digital object FDO content. While the default mode of accessing a digital object directly FDO delivers the Datastreams (i.e., repository returns a bitstream for a the bitstream represented by the Datastream un-transformed), the CMA (Content Model Architecture) enables defining any number of custom services for accessing Datastream content. These custom services are produced when the Fedora repository service calls another Web service to transform Datastream content. Such transformations can be thought of "virtual" views of digital object FDO content, since these views are created dynamically at runtime.
3. Web Services: These are Web-accessible programs that are invoked by HTTP to produce disseminations of digital object FDO content. Note that the Fedora repository itself is a Web service to access the default services of digital objects FDOs. Also, Fedora can interact with other Web services to product custom access services that transform digital object FDO content on-the-fly. In this tutorial we will describe how Fedora interacts with simple REST-based services to product such custom services. Custom services are produced when the Fedora repository service itself makes outbound service calls to other Web services using simple REST-based requests. We will not discuss Fedora interacting with SOAP-based web services here.
4. Storage: Digital FDOs objects are stored in by the Fedora repository service. Datastreams are constituent parts of digital objects – essentially the content streamsbytestreams. Fedora interacts with low-level storage to access digital objects FDOs to fulfill client requests for access to content. Datastreams capture the raw content. As shown in the previous examples, Datastreams can be directly disseminated via the Fedora Access service. Also, Datastreams can serve as input to other custom services that are produced on-the-fly when the Fedora repository service calls upon another Web service at run time (using a raw Datastream as input).

The process of creating digital objects FDOs with dynamic content disseminations involves creating linkages between these layers. During this process you will create and employ the following:

1. Service Definition (SDef): A digital object FDO that is a template for client-side services, defining a set of abstract operations (methods) and their client-side arguments. Association of a SDef with a digital object FDO augments the basic behavior of the object with the operations defined in the SDef template. A SDef may be associated with more than one digital object FDO, thereby augmenting all of them with the same operations.
2. Service Deployment (SDep): A digital object FDO that registers within Fedora the capability of web service(s) to perform the operations defined by a specific SDef. This registration includes defining service binding metadata encoded in the Web Service Description Language (WSDL) and also a data profile of the SDep. The data profile defines the types of inputs that are considered compatible with the service. In particular it declares the MIME types that are needed by the respective web service to perform its task. Multiple SDeps may be registered for an individual SDef, thereby exposing a generic client-side interface (defined by the SDef) over multiple data and web service foundations (defined by the SDep).
3. Content Model (CModel): A digital object FDO that is used to store information which will allow Fedora to determine whether a data object, which asserts conformance to a content model, is valid. The Content Model is also important for performing disseminations in Fedora, based on the Content Model Architecture. A Data Object will indicate which Content model they represent via a special RELS-EXT relationship. The Content Model will in turn indicate which SDef(s) it is associated with (also with a special RELS-EXT relationship).

These three kinds of special Fedora objects are stored in Fedora repositories. The set of all SDefs represents a "registry" of all the kinds of abstract services supported by the Fedora repository. The set of all SDeps represents a "registry" of all the concrete service bindings for the abstract service definitions supported by the Fedora repository. The set of all CModels represent a "registry" of the different user-defined types of data objects that exist in that Fedora repository.

At the end of the day, digital objects FDOs make references to SDefs, SDeps and CModels as the way of providing extended access points for digital objects FDOs (i.e., dynamic content disseminations.) This is done by adding special relationships between the objects that are stored in the RELS-EXT Datastreams of those objects.
Figure 13 indicates the relationships that exist between the four object types. Data objects assert that they conform to a particular Content Model using the hasModel relationship. Content Model objects assert they provide the services included in an SDef using the hasService relationship. Service Deployment objects assert the services for which they provide binding information by using the isDeploymentOf relationship, as well as asserting the Content Models for which they provide service bindings using the isContractorOf relationship.

...