You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Table of Contents

This page is to follow up on a number of conversations at the 2010 London Committers' Meeting relating to a re-working of the service deployment implementation under the Fedora 3.x CMA.

The consensus at the meeting was that the existing implementation of service deployments left much to be desired: It's implementation of WSDL-defined services is partial, and WSDL itself is a strained choice for describing many of the actual service deployments, which are more likely to be simple HTTP services or REST endpoints.

Desiderata included:

  • Support for a much simpler description language for http services, cf. Asger's Datastream Methods
  • Support for SOAP service bindings
  • Support for additional HTTP verbs
  • REST-style endpoint support
  • Tooling and Documentation improvements to support authoring and debugging of service deployments
  • More complete WSDL support, for deployments using WSDL

Broadly, we want to sketch out two categories of proposals: One in that works in the 3.x CMA and doesn't invalidate existing SDep objects, but allows for entirely different types to be deployed, and (if necessary) one that is targetted at a 4.x CMA with only a consideration for translation of 3.x objects.

3.x CMA Sketch

SDep Object Definition and Markup Considerations

For a hypothetical service deployment <hypothetical:SDep>, there are a number of triples encoded in the object that make it actionable:

<hypothetical:SDep-3.0> <fedora-model:hasModel> <info:fedora/fedora-system:ServiceDeployment-3.0>
<hypothetical:SDep-3.0> <fedora-model:isDeploymentOf> <hypothetical:ServiceDefinition>
<hypothetical:SDep-3.0> <fedora-model:isContractorOf> <hypothetical:ContentModel>

... with no defined or effective restrictions on the cardinality of the latter two.

To allow for new service deployment mechanisms without invalidatng existing service deployments we might introduce a new content model:

<info:fedora/fedora-system:ServiceDeployment-3.0> <fedora-model:hasModel> <info:fedora/fedora-system:ServiceDeploymentType>
<hypothetical:SDep-3.0> <fedora-model:hasModel> <info:fedora/fedora-system:ServiceDeployment-3.0>
<hypothetical:SDep-3.0> <fedora-model:isDeploymentOf> <hypothetical:ServiceDefinition>
<hypothetical:SDep-3.0> <fedora-model:isContractorOf> <hypothetical:ContentModel>

... such that we infer that <hypothetical:SDep-3.0> is a service deployment from its deployment and contractor statements, and determine the type of service deplyment from its content model when said model has itself the <info:fedora/fedora-system:ServiceDeploymentType> model.  This leaves all existing service deployment objects unchanged, but alows for the introduction of new types.

( type issue /  inheritance of cmodel; whether inference is appropriate )

SDep Interface and Code Considerations

Relevant Pluggable Interfaces

org.fcrepo.server.access
  • Access
org.fcrepo.server.storage
  • DOManager

Relevant "Private" Interfaces

org.fcrepo.server.access.dissemination
  • DisseminationService
org.fcrepo.server.storage
  • DirectoryBasedRepositoryReader
  • ServiceDefinitionReader
  • ServiceDeploymentReader
org.fcrepo.server.storage.service
  • ServiceMapper
org.fcrepo.server.resourceIndex
  • ServiceDefinitionTripleReader_3_0
other
  • HttpClient

( Indexing into internal Db; incomplete definitions )

( Defining interfaces to allow new implementation / pluggability; Spring/OSGi considerations )

( Moving all existing resolution / binding logic into an implementation indicated by fedora-system:ServiceDeployment-3.0, defining interfaces and loading faculty for completely different implementations )

4.x CMA Sketch

More to come, but presumably moves away from any WSDL specification as the default type.

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels