Page History

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

1. Refinements in the scope of the Fedora 3.3 Service Mapping
   1. Tweaking the ServiceMapper class
      1. More robust port-to-method binding
      2. Define and Implement a pluggable interface
      3. FCREPO 619: ServiceDeployment WSDL cannot specify relative URIs in http:address
   2. More input parm binding options
      1. bind to DC element
      2. bind to object of RDF triple
      3. bind to a system or environment property
   3. Improving documentation and validation
      1. Documenting the role and relationship of similar structures in SDef/SDep
      2. A trouble-shooting/analysis tool to identify problems (perhaps part of an EZService bundle)
2. WSDL Descriptions: Front-end and back-end
   1. WSDL 2 support
   2. Delivery of composed WSDL for clients at service endpoints
   3. FCREPO-52: WSDL Should Declare Faults 
   4. FCREPO-500 ; writeable disseminators, REST-as-service, POST support for (hopefully) idempotent services?
3. FCREPO-16: SDeps with SOAP Bindings
   1. Back-end with Datastreams (SOAPInputParm? DSInputParm@passBy='VALUE'?)
   2. Front-end as service (follow-on to FCREPO-500?)

3.2 Notes

...

1. Only supports one wsdl:service definition (contra WSDL 1.1), multiple wsdl:service elements will override previous
   • This is dependent on the WSDLParser, which only allows a single service; as well as the ServiceMapper, which only expects one
2. FCREPO-16: Does not support SOAP message bindings
3. Effectively limited to one port (operations are all mapped to the first port with an HTTP binding)
   • see ServiceMapper.merge();
   • Consequence: Operations can't be grouped according to http:address, so different service hosts mean only LOCAL addressing can work
4. FCREPO 619: ServiceDeployment WSDL cannot specify relative URIs in http:address
   • Does allow local.fedora.server variable as location
5. Effectively limited to a single portType (WSDLParser has one Service, Service class has one PortType)
6. Appears to require all portTypes to include all abstract message types? (still looking into this)

...