Re-Implementing Service Deployment

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
• DynamicAccessModule: Not directly involved in service resolution, but may offer a model for impl loading

org.fcrepo.server.storage

• DOManager

Relevant "Private" Interfaces

org.fcrepo.server.access.dissemination

• DisseminationService : Instantiated by DefaultAccess, with a parameter ServiceDeploymentReader, and DatastreamResolverServlet for (basically) access to static members/methods

org.fcrepo.server.storage

• DefaultDOManager : Redundant implementation of methods for getServiceDefinitionReader; getServiceDeploymentReader
• DirectoryBasedRepositoryReader : Redundant implementation of methods for getServiceDefinitionReader; getServiceDeploymentReader
• SimpleServiceAwareReader
• SimpleServiceDefinitionReader
• SimpleServiceDeploymentReader

org.fcrepo.server.storage.service

• ServiceMapper

org.fcrepo.server.resourceIndex

• ServiceDefinitionTripleReader_3_0 : Instantiates ServiceMapper to get abstract method defs.  This method is available through SimpleServiceDefinitionReader, and the instantiation is in a private method, so seems refactorable.  Could follow DefaultAccess model and request reader from DOManager.
• ServiceDeploymentTripleGenerator : Doesn't do anything!
• ModelBasedTripleGenerator : Maps the above to generator classes by RDFName, the map generation is hard-coded

org.fcrepo.common.http

• WebClient : Only supports HTTP GET

Cached Lookups and the Internal Db

( Indexing into internal Db; incomplete definitions )

Proposing New and Refactored Interfaces

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

org.fcrepo.server.service.storage

• ServiceDefinitionReader
• ServiceDeploymentReader
  • ServiceMapper becomes a package-internal mechanism

org.fcrepo.server.service.dissemination

• DisseminationService
  • To be provided by a generating method in ServiceDeploymentReader

org.fcrepo.server.service.resourceIndex

• ServiceDeploymentTripleGenerator
  • must provide an indicating cmodel uri
• ServiceDefinitionTripleGenerator
  • may not be necessary yet?
  • must provide an indicating cmodel uri

( 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 )

DOManager

If the existing service resolution functions are better encapsulated behind an implementation of ServiceDeploymentReader provided by DOManager, DOManager becomes the logical place for the steering decision (based on the SDep's content model).

4.x CMA Sketch

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