This guide describes how Service Deployment Objects are constructed in detail. For a conceptual overview of these and other special Fedora object types, please see the Fedora Digital Object Model document.
Introduction
In Fedora, a Service Deployment ("SDep") is a special kind of object that describes how the methods of a particular Service Definition are to be deployed for a particular Content Model.
Although you may author Fedora objects in other ways (e.g. by making a series of API calls to your repository), we will assume for this guide that the object is being constructed in FOXML format outside the repository, then ingested in a single step.
For a conceptual overview of these and other special Fedora object types, please see the Fedora Digital Object Model document.
On this page:
| Table of Contents |
|---|
Persistent Identifier
As with all Fedora objects, Service Deployments must declare a persistent identifier ("PID") that is unique within the repository. There are no special restrictions on the PID beyond those described in the Fedora Identifiers document. In FOXML format, the PID is declared in the root element of the XML document as shown below:
| Code Block |
|---|
<?xml version="1.0" encoding="UTF-8"?>
<foxml:digitalObject xmlns:foxml="info:fedora/fedora-system:def/foxml#"
VERSION="1.1" PID="demo:MyServiceDeployment">
<!-- Object Properties -->
<!-- Datastreams -->
</foxml:digitalObject>
|
Object Properties
There are also no special restrictions on the top-level object properties for Service Deployments. In the following FOXML fragment, we assert that the state of the object is Active and the label is My Service Deployment.
| Code Block |
|---|
<foxml:objectProperties>
<foxml:property
NAME="info:fedora/fedora-system:def/model#state"
VALUE="Active"/>
<foxml:property
NAME="info:fedora/fedora-system:def/model#label"
VALUE="My Service Deployment"/>
</foxml:objectProperties>
|
DC Datastream
The DC datastream describes the object in human terms using the Dublin Core Metadata Element Set. If you don't provide it yourself, Fedora will automatically add a bare-bones DC datastream for the object at ingest time. For an example DC datastream, please see the FOXML Ingest Example.
RELS-EXT Datastream
The RELS-EXT datastream expresses relationships and properties of the object in RDF. An object asserts that it is a Service Deployment Object through a special hasModel relationship to the fedora-system:ServiceDeployment-3.0 object. SDeps must also have two additional relationships asserted in RELS-EXT:
...
| Code Block |
|---|
<foxml:datastream ID="RELS-EXT"
CONTROL_GROUP="X" STATE="A" VERSIONABLE="true">
<foxml:datastreamVersion ID="RELS-EXT1.0"
MIMETYPE="application/rdf+xml"
FORMAT_URI="info:fedora/fedora-system:FedoraRELSExt-1.0"
LABEL="RDF Statements about this object">
<foxml:xmlContent>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:fedora-model="info:fedora/fedora-system:def/model#">
<rdf:Description rdf:about="info:fedora/demo:MyServiceDeployment">
<fedora-model:hasModel
rdf:resource="info:fedora/fedora-system:ServiceDeployment-3.0"/>
<fedora-model:isDeploymentOf
rdf:resource="info:fedora/demo:MyServiceDefinition"/>
<fedora-model:isContractorOf
rdf:resource="info:fedora/demo:MyContentModel"/>
</rdf:Description>
</rdf:RDF>
</foxml:xmlContent>
</foxml:datastreamVersion>
</foxml:datastream>
|
METHODMAP Datastream
The METHODMAP datastream in the Service Deployment object is similar to the one stored in the corresponding Service Definition, but it also indicates which datastreams (if any) are required as input to each deployed method. This information is specified in the Service Deployment Method Map format, which is an extension of the Service Definition Method Map format.
...
| Code Block |
|---|
<foxml:datastream ID="METHODMAP"
CONTROL_GROUP="X" STATE="A" VERSIONABLE="true">
<foxml:datastreamVersion ID="METHODMAP1.0"
+ FORMAT_URI="info:fedora/fedora-system:FedoraSDepMethodMap-1.1"
+ LABEL="Deployment Method Map" MIMETYPE="text/xml">
<foxml:xmlContent>
<fmm:MethodMap
xmlns:fmm="http://fedora.comm.nsdlib.org/service/methodmap"
name="N/A">
<fmm:Method operationName="methodOne"
+ wsdlMsgName="methodOneRequest"
+ wsdlMsgOutput="response">
+ <fmm:DatastreamInputParm parmName="FOO"
+ passBy="URL_REF" required="true"/>
+ <fmm:MethodReturnType wsdlMsgName="response"
+ wsdlMsgTOMIME="N/A"/>
</fmm:Method>
<fmm:Method operationName="methodTwo"
+ wsdlMsgName="methodTwoRequest"
+ wsdlMsgOutput="response">
<fmm:UserInputParm parmName="parm1" defaultValue="value1"
required="false" passBy="VALUE"/>
+ <fmm:DefaultInputParm parmName="uri" defaultValue="$objuri"
+ passBy="VALUE" required="true"/>
+ <fmm:MethodReturnType wsdlMsgName="response"
+ wsdlMsgTOMIME="N/A"/>
</fmm:Method>
<fmm:Method operationName="methodThree"
+ wsdlMsgName="methodThreeRequest"
+ wsdlMsgOutput="response">
<fmm:UserInputParm parmName="parm1" defaultValue="value1"
required="false" passBy="VALUE">
<fmm:ValidParmValues>
<fmm:ValidParm value="value1"/>
<fmm:ValidParm value="value2"/>
</fmm:ValidParmValues>
</fmm:UserInputParm>
<fmm:UserInputParm parmName="parm2" defaultValue=""
required="true" passBy="VALUE"/>
+ <fmm:DefaultInputParm parmName="pid" defaultValue="$pid"
+ passBy="VALUE" required="true"/>
+ <fmm:DatastreamInputParm parmName="FOO"
+ passBy="URL_REF" required="true"/>
+ <fmm:DatastreamInputParm parmName="BAR"
+ passBy="URL_REF" required="true"/>
+ <fmm:DatastreamInputParm parmName="BAZ"
+ passBy="URL_REF" required="true"/>
+ <fmm:MethodReturnType wsdlMsgName="response"
+ wsdlMsgTOMIME="N/A"/>
</fmm:Method>
</fmm:MethodMap>
</foxml:xmlContent>
</foxml:datastreamVersion>
<foxml:datastream>
|
DSINPUTSPEC Datastream
The DSINPUTSPEC datastream specifies additional information about each datastream. It is written in the Fedora Datastream Input Specification format.
...
Notice that the BAZ datastream input specification above has an extra attribute, "pid" specified. When present, the pid attribute tells Fedora that the datastream to be used as input is located inside a specific object. In this case, it is the BAZ datastream in the "demo:MyContentModel" object. Normally, each input datastream is expected to come from the particular data object from which the method is invoked. When a pid is specified, the associated datastream effectively serves as a constant.
WSDL Datastream
The WSDL datastream brings everything together, describing to Fedora exactly what needs to be done under the hood when a dissemination request is made. For each method, the WSDL provides enough information to Fedora so that it may do a URL replacement in order to fulfill a request.
...