Page History

...

( 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 obviously touches depends on the discussion of changes to the module architecture.  If it was acceptable to include some additional libraries Spring is included in a 3.4 release, it's possible that these changes could provide a laboratory setting for the module architecture changes to come (assuming that the overall change is a 4.0 feature).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.