[OAI-implementers] Trying to gauge interest on two features
Sun, 11 May 2003 17:26:08 +0200
herbert van de sompel wrote:
> Sandro Zic wrote:
>>Has a kind of SOAP-OAI already been implemented somewhere or discussed
> When working on version 2.0 of the OAI-PMH we have decided to stick to the HTTP
> GET approach used in versions 1.x, but have made sure that the protocol responses
> would be SOAP-ready. I know some OAI-implementers have done SOAP-related
> experiments, and I guess they will reply to the list to detail such work. With
> the OAI, we plan to create a spec for a SOAP version of the OAI-PMH, but so far
> no concrete schedule has been set with this respect. However, I expect/hope that
> this work would start in the course of 2003.
Actually, I am a REST advocate so I can happily live with the OAI-PMH
approach ;) Nevertheless, SOAP and related technologies offer a broader
variety of applicances, especially with WSDL, support of various
protocols (HTTP, SMTP, TCP/IP, etc.), SOAP attachments, and so on.
Hence, SOAP is better suited if you implement OAI related harvesting
technologies in heterogenous or business environments, who very often
follow the Web Services Hype.
I would very much be interested in best practices to implement a SOAP
wrapper to an OAI data provider. For example:
How to pass the OAI arguments or how should the method signature look
like? Do you prefer passing an associative array containing all
arguments with the OAI arguments as the keys or each argument at a
certain place in the method signature?
What does a remote procedure call return? Simply the complete OAI
response as a string? A struct with the OAI header split to several
values and e.g. the metadata from a getRecord() call in another
parameter of the struct?
How about integrating OAI error responses and SOAP faults?
Thanks for any feedback,