Page History

...

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. 

1. bind to DC element
   • DCInputParm could be marked up similarly to existing parms, with the @parmName value indicating the dc predicate to search for the value on
   • Alternately, an extension to the existing InputParm types that added a @predicate value, whose object would be bound to @parmName
   • Could cause errors if predicates with multiple statements are used in urlReplacement context
2. bind to object of RDF triple from RELS-EXT or RELS-INT
   • As above, requires both @predicate and (if RELS-INT supported) @dsSubject
   • As above for multiple value concerns
3. bind to value of a system or environment property
   • @parmName could map to system property relatively easily
   • Correspondence to String-String hash should eliminate mutiple value concerns

Improving Documentation and Validation Tools

...

Supporting changes would need to be made to HttpOperationInOut and WSDLParser (to support the value) and DisseminationService.assembleDissemination (to build the URL).  This appears to be a less dramatic change than some others, and would offer a way to support multiple-value input parms without WSDL2 support.  Along with some of the other proposed features, a key component is probably refactoring DisseminationService into an interface, with supporting implementations for different operation types.

Note: In WSDL-1.1, these http binding options are all-or-nothing.  WSDL-2 has a more sophisticated reckoning of serialization style application/x-www-form-urlencoded .

Rudimentary support for HTTP POST

...

It might very well be flexible enough to model a known external API, so there's a possible path of defining WSDL-2 SDeps, and having them proxied by a simpler WSDL-1.1 SDef

See also this :

• IBM developerWorks article on REST and WSDL-2.
• XML.com on WSDL-2

FCREPO-500: Writeable disseminators; POST support

...

This is a problem considered in Asger's REST API proposal and in Aaron's sketch of a Read Write CMA .

FCREPO-500

Other Things to Chew On:

A thread in which a savvy developer doesn't want to deal with SDef/p

...

Proposal Outline

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?)

...