Page History

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

The three four broad areas of discussion under this proposal are:

1. Generally localized changes in service resolution and improved documentation, with minimal disruption to the existing implementation
2. More significant changes to the use of WSDL in service resolution, including additional http binding styles and verbs
3. SOAP support, either as a back-end binding to a service deployment or a front-end interface to POST-supporting service definitions
4. An overview of ways to model writeable endpoints, REST, and more flexible integration with various APIs through the SDef/SDep architecture

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

...

Support for WSDL Faults (API WSDL & SDef/p)

FCREPO-52 is really a documentation issue.  What fault types might there be?  org.fcrepo.server.utilities.AxisUtility relies on org.apache.axis.AxisFault for construction; for all subtypes of ServerException, detail is set as a buffer of <detail> elements; for AuthzExceptions, set by qname="Authz" with standard message.
We should be able to define two message formats to accommodate all the API messages.stub

FCREPO-52: WSDL Should Declare Faults

...

Variant on the ListMethodsServlet calls with xml=true.  Ideally, this would parse deployments rather than definitions.

...

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

Cons: People kind of hate it; changed characters for value substitution mean patterns aren't backward compatible; questionable whether it's necessary for REST support

FCREPO-500: Writeable disseminators; REST support; POST support

stub

FCREPO-500

3. SOAP Support

There are two broad areas of SOAP suport that may be pursued: SDep binding to SOAP services, and SDef specification of SOAP services.

...

Example: Document sdef with a getCalais service defined - sdep might have default user parms for API key; nullbind-style bind to paramsXML, bind to content datastream

Potential problems: Support for xsd types is easy; support for complex or user-defined types is more difficult.  Need to specify some rules for attempted type conversion.  Somewhat awkward reliance on Fedora admin to keep SDep wsdl and actual service wsd in synch.  Perhaps allow WSDL by reference?

If SOAP binding for SDeps is supported, how will faults be handled? Expected/unexpected?
Does MIMETypedDatastream need to be given a way to communicate response codes?  How should ExternalContentHandler communicate fault information?

Support mime:multipartRelated

...

The principal advantage is probably a follow-on to SDep SOAP binding: It would prevent the context object from being responsible for all data for a bound service.  It introduces an additional complication in having to translate the client input document into an appropriately formatted input for the bound service.  There is also the question of how to constrain message and fault types practically.

4. Strategies for services as different types of endpoints

WSDL-2 Support in Service Definitions

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

Cons: People kind of hate it; changed characters for value substitution mean patterns aren't backward compatible; questionable whether it's necessary for desired REST-like support

It woud be an open question whether the relatively rigid delineation of paths suits the needs of some previously indicated support for better mapping of external APIs to service definitions (eg FCREPO-405 ).

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

FCREPO-500: Writeable disseminators; POST support

Writeable disseminators are more than just post support- they suggest a view of the endpoint as a resource rather than a messaging address.

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

FCREPO-500

...

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

...