Page History

...

Figure 1 – Fedora Repository as Mediator for Services and Content
Figure 2 – Fedora Administrator Login Screen
Figure 3 – New Object Dialog
Figure 4 – Configuring an Object
Figure 5 – Datastream Display
Figure 6 – Adding a New Managed Content Datastream
Figure 7 – Complete Datastreams for Example 1
Figure 8 – Example 1 Fedora Digital Object and Datastreams
Figure 9 – Adding a Datastream with Type Redirect
Figure 10 – Example 2 Datastream Display
Figure 11 – Example Fedora Digital Object and Redirected Datastream
Figure 12 – Abstract View: Key Fedora Components for Producing Disseminations of Content
Figure 13 – Relationships Between Data objects and CModel/SDef/SDep Objects for CMAthe Content Model Architecture
Figure 14 – Dynamic Dissemination Access
Figure 15 – Example 3 Linking a Fedora Digital Object to a Content Model
Figure 16 – Example 3 Dissemination via CMAthe Content Model Architecture
Figure 17 – Dissemination with Redirect Datastream

...

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 FDO. A 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 FDO content. While the default mode of accessing a FDO delivers the Datastreams (i.e., repository returns 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 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 FDO content. Note that the Fedora repository itself is a Web service to access the default services of FDOs. Also, Fedora can interact with other Web services to product custom access services that transform 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: FDOs objects are stored by the Fedora repository service. Datastreams are constituent parts of FDOs – essentially metadata about the bytestreams. Fedora interacts with low-level storage to access 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).

...

1. Service Definition (SDef): A 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 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 FDO, thereby augmenting all of them with the same operations.
2. Service Deployment (SDep): A 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 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, FDOs make references to SDefs, SDeps and CModels as the way of providing extended access points for 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.

{center}
!worddav260b00704cd49b2f81797bbe01694fa5.png|height=510,width=724!
*Figure 13 -- Fundamental _CMAContent Model Architecture_ Relationships* 
{center}

Figure 14 illustrates the interactions among Fedora and Web services in response to an access request. As indicated, a client makes a request to the Fedora API (with a URL in this case.) The Fedora repository service then determines the content model that is associated with the FDO for which the request is being made. Once it knows the content model, the Fedora repository can discover what SDefs and SDeps are in play for this FDO. Once all of this information is gathered, the Fedora repository can construct a request to the appropriate web service to transform the Datastreams of the target FDO (demo:2). The Fedora repository service invokes a REST-based request to the web service via HTTP, sending along arguments to enable the web service to obtain the required Datastream inputs to fulfill the request. The Fedora repository mediates all invocations with the external web service. When it receives a response from the web service it streams it back to the original calling client. In this case, the response is a transformation based on the raw material of Datastream1 and Datastream2 in the FDO.

{center}
!worddav16a77ff05b7cb41adf9bea82f2a3933d.png|height=560,width=765! 
*Figure 14 -- Dynamic Dissemination Access*
{center}

Example 3: Using SDefs, SDeps and CModels

This example makes use of a SDef, SDep and CModel supplied with the Fedora tutorial. This will help you understand the basics of dynamic disseminations in Fedora under the Content Model Architecture, without writing a SDef, SDep or CModel. The next example describes how to do that more advanced task.

The web service used in the example performs an XSL transform using the well-known Saxon XSLT processor. This service requires two inputs, an XML source document and a XSL transform document. In this example, both of these XML documents are stored as managed content in a Fedora Digital Object. The XML source is data for a poem with tags for the structural elements of the poem (stanzas and lines). The XSL transform produces a HTML output of the poem that can be viewed in a browser. This example is borrowed from the web available source for Michael Kay's excellent XSLT book.

Ingesting Pre-defined SDef, SDep and CModel Objects

First we will ingest a sample SDef object into the repository.

...

Browse the file system to select the ingest file for the SDef object whose file name is FEDORA_HOME/userdocs/tutorials/2/example3/SDef.xml. Since this ingest file is encoded as FOXML 1.1 select the FOXML 1.1 radio button as below:

...

This will create the FDO with PID demo:ex3SDef in your repository. This SDef defines one method getContent. This generic method name is intentional – one could imagine this one SDef being used as the basis for several SDeps, each of which produces "content" via a unique transformation of an underlying source. This is one of the advantages of Fedora – providing a common interface despite multiple underlying representations.

Follow the same procedure to ingest a sample SDep object into the repository. Select the file FEDORA_HOME/userdocs/tutorials/2/example3/SDep.xml. This will create the FDO with the PID demo:ex3SDep. This SDep represents a concrete implementation of the abstract service operations defined in the SDef demo:ex3SDef. The SDep object contains metadata that specifies the following:

• Service Contract: the SDep indicates the PID of the SDef that it is related to. This is like saying that the SDep provides and implementation of the SDef.
• Service binding metadata (i.e., in WSDL) : concrete binding for the getContent method that is defined. Specifically, the WSDL indicates that the getContent operation binding exists at the base URL of http://localhost:8080/service/saxon. Note that this service is hosted at the same host and port as the Fedora repository. As noted earlier, this is a local service that is packaged with Fedora.
• Data input profile that indicates that the SDep service operation getContent will take the following inputs at runtime:
  • "xsl" with MIME type text/xml.
  • "source" with MIME type text/xml.

Next follow the same procedure to ingest a sample CModel object into the repository. Select the file FEDORA_HOME/userdocs/tutorials/2/example3/CModel.xml. This will create the FDO with the PID demo:ex3CModel. This CModel describes the Datastreams that should be present in data objects that conform to this content model, it also has a RELS-EXT hasService relationship link to the FDO demo:ex3SDef ingested previously.

...

Now you need to create the new FDO based on this SDef, SDep and CModel. To get started follow the same procedure as illustrated in Figure 3, this time entering demo:300 as the Datastream ID and Example 3 as the Label.

...

{center}
!worddav99c4468a3a6c6a98dba66f8cd6c30ba1.png|height=553,width=765! 
*Figure 16 -- Example 3 dissemination via _CMAthe _Content Model Architecture_* 
{center}

Example 4 – Modifying Example 3 Using a Redirect Datastream

...

You should now understand the basic mechanisms through which SDefs, SDeps and CModels interact with Data objects to provide a richer dynamic view of the data stored in those objects. The next tutorial (Tutorial 3 – Not yet available) steps you through the process of using the admin client to create a SDef, a SDep, and a CModel from scratch and a Data object Object that will function with the control objects to provide customized services similar to those described in the last example of this tutorial. To explore the other features of Fedora, refer to the Fedora Repository Documentation. You can also join the Fedora-users mailing list to ask questions and learn from the experience of other Fedora users.