[OAI-implementers] Trying to gauge interest on two features

zubair@cs.odu.edu zubair@cs.odu.edu
Sun, 11 May 2003 12:08:55 -0400

One of my students implemented a OAI-SOAP gateway. Here is the URL if you
are interested in looking at that.



|        |          Sandro Zic <sandro.zic@zzoss.com>   |
|        |          Sent by:                            |
|        |          oai-implementers-admin@oaisrv.nsdl.c|
|        |          ornell.edu                          |
|        |                                              |
|        |                                              |
|        |          05/11/2003 11:26 AM                 |
|        |                                              |
  |                                                                                                   |
  |      To:     herbert van de sompel <herbertv@lanl.gov>                                            |
  |      cc:     OAI-implementers@oaisrv.nsdl.cornell.edu                                             |
  |      Subject:     Re: [OAI-implementers] Trying to gauge interest on two features                 |

herbert van de sompel wrote:
> Sandro Zic wrote:
>>Has a kind of SOAP-OAI already been implemented somewhere or discussed
>>on this
> 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
> 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.
> 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,

OAI-implementers mailing list
List information, archives, preferences and to unsubscribe: