Notes on SDef and SDep Improvements

Proposal notes for London Committers' Meeting, Feb. 23-24, 2010

The three broad areas of discussion under this proposal are:

Generally localized changes in service resolution, with minimal disruption to the existing implementation
More significant changes to the use of WSDL in service resolution
SOAP support, either as a back-end binding to a service deployment or a front-end interface to POST-supporting service definitions

1. Refinements in the scope of the Fedora 3.3 Service Resolution

Changes to ServiceMapper

More Robust Port-to-Method Bindings

Allow multiple bindings to a service. This involves simply changing the search logic for constructing the MethodDefOperationBind array to search available HTTP bindings for an operation name (defaulting to the first), rather than defaulting to the first HTTP binding for all operations. This aligns with canonical documentation for WSDL services, creates an opening to distinguish bindings by verb, and allows for less cumbersome markup of services, e.g.:

           <wsdl:binding name="risearch_http" type="this:examplePortType">
            <http:binding verb="GET"></http:binding>
            <wsdl:operation name="getSize">
              <http:operation location="/risearch?type=tuples&amp;lang=itql&amp;format=count&amp;query=select%20%24member%20from%20%3C%23ri%3E%20where%20%24member%20%3Chttp%3A//purl.oclc.org/NET/CUL/memberOf%3E%20%3C(objuri)%3E"></http:operation>
              <wsdl:input>
                <http:urlReplacement></http:urlReplacement>
              </wsdl:input>
              <wsdl:output>
                <mime:content type="text/plain"></mime:content>
              </wsdl:output>
            </wsdl:operation>
          </wsdl:binding>
          <wsdl:binding name="lamp_http" type="this:examplePortType">
            <http:binding verb="GET"></http:binding>
            <wsdl:operation name="listMembers">
              <http:operation location="/fedora-svc/aggregator/listMembers/bag-aggregator.php?nullbind=(NULLBIND)&amp;objuri=(objuri)&amp;callback=(callback)"></http:operation>
              <wsdl:input>
                <http:urlReplacement></http:urlReplacement>
              </wsdl:input>
              <wsdl:output>
                <mime:content type="text/xml"></mime:content>
              </wsdl:output>
            </wsdl:operation>
          </wsdl:binding>
          <wsdl:service name="aggregator">
            <wsdl:port binding="this:risearch_http" name="risearch_port">
              <http:address location="http://local.fedora.server/fedora"></http:address>
            </wsdl:port>
            <wsdl:port binding="this:lamp_http" name="lamp_port">
              <http:address location="http://php.example.edu"></http:address>
            </wsdl:port>
          </wsdl:service>

ServiceDeployment WSDL cannot support relative URIs in http:address

FCREPO-619 is a reasonable expectation given the W3C docs for wsdl . The principal question is what the context for resolution should be.

Define and Implement a Pluggable Interface for the Creation of ServiceMapper Instances

One way to cordon off most any proposed change to service deployment bindings to minimize disruption would be to extract an interface from the few public methods of the ServiceMapper class, re-implement the existing class as an implementation of the interface, and define a factory interface as an extension of Pluggable. This is extending the use of the plugin architecture to mimic SPI:

 interface ServiceMapperFactory extends Pluggable {
    public ServiceMapper getServiceMapper(String parentPid);
}

 interface ServiceMapper  {
    public MethodDef[] getMethodDefs(InputSource methodMapSource)
            throws ObjectIntegrityException, RepositoryConfigurationException, GeneralException;
    public MethodDefOperationBind[] getMethodDefBindings(InputSource wsdlSource, InputSource methodMapSource)
            throws ObjectIntegrityException, RepositoryConfigurationException, GeneralException;
    public DeploymentDSBindSpec getDSInputSpec(InputSource dsInputSpecSource)
            throws ObjectIntegrityException, RepositoryConfigurationException, GeneralException;
}

... with the existing ServiceMapper becoming an AbstractServiceMapper (initializers) & ServiceMapperImpl

Implement More InputParm Binding Options

Service definitions still focus on a minimal set of UserInputs, but service deployments might have a richer array of options made available to it. This would require a change to the Service Deployment Method Map document type definitions, and code changes in DefaultAccess to accommodate what are functionally akin to DefaultInputParms

bind to DC element
bind to object of RDF triple from RELS-EXT or RELS-INT
bind to value of a system or environment property

Improving Documentation and Validation Tools

Existing documentation focuses on SDefs and SDeps as Fedora objects, explaining the required datastreams and their expected content. It is less concerned with what SDefs and SDeps are, how they are related. Similarly, runtime errors in service resolution often have opaque, wrapped Null Pointer exceptions, or throw 500's. Finding ways to improve error messages and documentation would make the service resolution architecture much more approachable.

2. Changes to Parsing and Use of WSDL, Front and Back end

stub

3. SOAP Support