Versions Compared

Old Version 9

changes.mady.by.user Benjamin Armintor

Saved on

compared with

New Version Current

changes.mady.by.user Benjamin Armintor

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

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

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.  It would also be helpful to implement a debugging tool to identify common error patterns in SDef/SDep pairings (maybe even a service definition for SDep objects!)

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

...

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

If the ServiceMapper class is refactored to allow multiple bindings, it opens the door to supporting additional http verbs.   This would require some additional refactoring of the binding classes to key on verb, and elaborating org.fcrepo.common.http.WebClient to support POST.  This is only considering support for the verb (for example, to skirt URL length restrictions on bound services), not its role in REST or the requirement of idempotency.

Deliver Composed WSDL for Object Disseminations

...

Necessary to support SOAP with attachments or MTOM, allows for some transport efficiency of b64 encoding.

Allow SDefs to Specify SOAP Services

...

4. Strategies for services as different types of endpoints

WSDL-2 Support in Service Definitions and/or Deployments

Pros: Better language for multiple verbs; better support for serialization of multiply-valued parts into URLs for GET requests or XML for POST; request header support; multipart/form-data support; supported by Axis2

...

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:

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

...