Api hooks

This contains the api hooks.

This is the management section in the fedora.fcfg file. As can be seen, we have added three invocation handlers. This means that every API-M invocation will be fed through these handlers.

  <module role="fedora.server.management.Management" class="fedora.server.management.ManagementModule">
    <comment>The management subsystem. This implements the methods necessary
		to fulfill API-M requests without regard to:
                 - how the service is exposed
                 - how bytestreams and java types might be marshalled/demarshalled over the wire
                 - how the storage subsystem is implemented.</comment>
    <param name="decorator1" value="fedora.server.messaging.NotificationInvocationHandler"/>
    <param name="decorator2" value="dk.statsbiblioteket.doms.fedora.server.management.DomsForbiddenInvocationHandler"/>
    <param name="decorator3" value="dk.statsbiblioteket.doms.fedora.server.management.DomsStateInvocationHandler"/>
    <param name="decorator4" value="dk.statsbiblioteket.doms.fedora.server.management.DomsValidatorInvocationHandler"/>
    <param name="autoChecksum" value="false">
      <comment>Controls whether a checksum is automatically computed for
			every datastream as the datastream is added to the repository. This
			will allow the integrity of datastream contents to be periodically
			checked to insure the object is not corrupted.</comment>
    </param>
    <param name="checksumAlgorithm" value="MD5">
      <comment>Specifies which checksumming algorithm is to be used when
			automatically computing checksums as specified by the above
			parameter. Valid values are: MD5  SHA-1  SHA-256  SHA-384  SHA-512.</comment>
    </param>
  </module>

First, we have the DomsForbiddenInvocationHandler which throws exceptions on the purge methods. Our system should not allow data to be purged, but you can safely disregard this requirement.
Then there are the DomsStateInvocationHandler. This handler checks the state of the object about to be modified. If it is in Active, an exception is thrown, except of the method would change the
state to Inactive.

Then lastly, of the invocation passed to two previous handlers, it hits the DomsValidatorInvocationHandler. This handler checks if the method is ModifyObject, and it would change the state to Active. If so, the validater webservice is invoked on the object. If the object validates, the operation completes, otherwise the errors are collected in the message of an exception, and thrown back.

Todo

DomsForbiddenInvocationHandler and DomsStateInvocationHandler should really be done via XACML, not by API hooks. DomsValidatorInvocationHandler needs to be a hook.