Page History

...

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

org.fcrepo.server.service.storage.impl.default_3_0

• SimpleServiceDefinitionReader (moved from org.fcrepo.server.storage.SimpleServiceDefinitionReader)
• SimpleServiceDeploymentReader (moved from org.fcrepo.server.storage.SimpleServiceDefinitionReader)
• All classes from org.fcrepo.storage.service?

org.fcrepo.server.service.dissemination

• DisseminationService ( interface derived from existing org.fcrepo.server.dissemination.DisseminationService )
  • Implementation to
  • To be provided by a generating method in ServiceDeploymentReader

org.fcrepo.server.service.dissemination.impl.default_3_0

• DisseminationServiceImpl (moved partially from org.fcrepo.server.dissemination.DisseminationService )

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 )

Module Architecture

DOManager

Assuming the persistence of the Fedora 3.0 plugin architecture for 3.4+: 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).  One hitch is the resource index rebuild:  A DOManager isn't necessarily available to the triple generators.  Perhaps DOManager could share a delegate for driving this behavior with DirectoryRepositoryReader?

Spring Modules

Even in a scenario that preserves existing CMA 3.0 object markup, the proposed change to a model-dependent loading of deployment readers and triple generators depends on the module architecture.  If Spring is included in a 3.4 release, then the DOManager is not necessarily the arbiter of cmodel-indicated implementations.  Is it reasonable to propose that areas of code that provide one or more implementations based on cmodel are application contexts?

If so, then the separate interface definitions for the SDef and SDep triple generators are probably unnecessary.  Instead, we may have an application context for triple generation, one for service definition, and another for service resolution?

Returning to ModelBasedTripleGenerator as an example:

 <beans>
  <bean id="ModelBasedTripleGenerator"
   class="org.fcrepo.server.resourceIndex.ModelBasedTripleGenerator">
   <constructor-arg>
     <map>
       <entry key="info:fedora/fedora-system:ServiceDefinition-3.0">
         <bean class="org.fcrepo.server.resourceIndex.ServiceDefinitionTripleGenerator_3_0"></bean>
       </entry>
       <entry key="info:fedora/fedora-system:ServiceDeployment-3.0">
         <bean class="org.fcrepo.server.resourceIndex.ServiceDeploymentTripleGenerator"></bean>
       </entry>
       <entry key="info:fedora/fedora-system:ContentModel-3.0">
         <bean class="org.fcrepo.server.resourceIndex.ContentModelTripleGenerator_3_0"></bean>
       </entry>
       <entry key="info:fedora/fedora-system:FedoraObject-3.0">
         <bean class="org.fcrepo.server.resourceIndex.FedoraObjectTripleGenerator_3_0"></bean>
       </entry>
     </map>
   </constructor-arg>
  </bean>
</beans>

This works because the triple generators are re-usable.  To implement service-aware readers, the model driven behaviors need to provide a factory method of some kind.

(service-aware reader example)

(model-driven behavior example)

4.x CMA Sketch

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