[OAI-implementers] SOAP-PMH

[Matthew Cockerill]

SOAP isn't by any means all about search interfaces - it's designed to  
be used for any web service.

  Remote search is one important kind of service  
[http://www.loc.gov/z3950/agency/zing/srw/ ], metadata harvesting is  
another, 'what's the weather' is another, stock prices are another,  
customer contact management is another  
[http://www.sforce.com/resources/api.jsp] , mailing list management is  
another  
[http://www.lyris.com/products/listmanager/beta_news.html?s=sdbr ], the  
NCBI eutilities are another  
[http://eutils.ncbi.nlm.nih.gov/entrez/query/static/esoap_help.html ]

The fundamental point of SOAP is well expressed in the comment:

>> "With a SOAP
>> interface, it would be fairly easy to build a harvester for
>> our search engine. It would be a very nice sample program for our
>> indexing interface. But with a one-of-a-kind XML protocol, it isn't
>> worth the trouble.
>> "

This is precisely the benefit of SOAP - it lowers the amount of 'one of  
a kind' work that an implementor has to do. And as a result it  
*dramatically* increases the chance that people outside the direct  
target area for the OAI protocol will actually use it.

Migrating OAI to use SOAP as its transport does seem long overdue...

Matt

==
Matt Cockerill
Technical Director
BioMed Central (http://www.biomedcentral.com)
34-42, Cleveland Street
London W1T 4LB
Tel: +44 20 7631 9127
Fax: +44 20 7580 1938
Email: matt at biomedcentral.com



On 7 Dec 2004, at 19:46, Roy Tennant wrote:

> But are we losing track of the fact that OAI-PMH is a _harvesting_  
> protocol and NOT a _searching_ protocol? Are potential SOAP users of  
> OAI data providers clear that the only thing they may be able to do is  
> request 85,000 records in order to get the ten they are really after  
> (the "professor's list of publications" example below)? The Google  
> API, for example, is searching of course, not harvesting. There is a  
> difference.
> Roy
>
> On Dec 7, 2004, at 11:36 AM, Joachim Wackerow wrote:
>
>> Just to clarify:
>> There is indeed an HTTP based approach of SOAP, it is called "The  
>> SOAP HTTP Binding". Here is an complete request example from the  
>> chapter "SOAP HTTP GET Usage" of the W3C SOAP Primer [1].
>>
>> GET /travelcompany.example.org/reservations?code=FT35ZBQ  HTTP/1.1
>> Host: travelcompany.example.org
>> Accept: text/html;q=0.5, application/soap+xml
>>
>> The answer is in an SOAP envelope, a specific client is needed (as  
>> with OAI-PMH?).
>>
>> For example Fedora (Open-Source Digital Repository Management System)  
>> is using such an approach in the Fedora-API-A-LITE [2].
>>
>>
>> Regarding the question on advantages of SOAP see the interesting  
>> discussion threads two years ago on "OAI-PMH & SOAP":
>> http://www.openarchives.org/pipermail/oai-implementers/2002-January/ 
>> 000294.html
>> http://www.openarchives.org/pipermail/oai-implementers/2002-February/ 
>> 000305.html
>>
>> A person of the Inktomi company is speaking for SOAP, see:
>> http://www.openarchives.org/pipermail/oai-implementers/2002-January/ 
>> 000296.html
>> http://www.openarchives.org/pipermail/oai-implementers/2002-February/ 
>> 000306.html
>> http://www.openarchives.org/pipermail/oai-implementers/2002-February/ 
>> 000309.html
>>
>> I think some of his arguments are still important. Here are some  
>> snippets of his arguments:
>> "With a SOAP
>> interface, it would be fairly easy to build a harvester for
>> our search engine. It would be a very nice sample program for our
>> indexing interface. But with a one-of-a-kind XML protocol, it isn't
>> worth the trouble.
>>
>> I believe that not using SOAP is a serious mistake. It means that
>> OAI will remain a niche protocol, with few implementations, few
>> users, and little positive effect.
>>
>> With SOAP, you get scaling support, test suites, development tools,
>> supported libraries, directory service, etc. A custom protocol can
>> never catch up. And implementors have much better things to do
>> with their time than re-invent RPC."
>> "I want that library information to be easily available to all,
>> not just people willing to run a library-only protocol."
>> "With a SOAP protocol, any scripted web page can make a call to OAI.
>> Servers like DP9 and the repository explorer become very easy to
>> write. A professor's list of publications could be built from
>> the eprint data."
>> "OAI is already using an XML RPC. Switching from a non-standard XML
>> RPC to a standard one should be an obvious decision."
>>
>>
>>
>> As fare as I know: Google is investing in SOAP [3] but not OAI-PMH.
>>
>> Regards, Achim
>>
>> References
>> [1] W3C SOAP Primer
>> http://www.w3.org/TR/2003/REC-soap12-part0-20030624/#L26854
>> [2] Fedora-API-A-LITE
>> http://www.fedora.info/definitions/1/0/api/#apialite
>> [3] Google Web APIs
>> http://www.google.com/apis/
>>
>>
>> Young,Jeff wrote:
>>
>> > It's not a question of SOAP vs. OAI, it's a question of SOAP vs.  
>> REST.
>> > OAI could, in theory, operate using either transport mechanism.
>> > Currently, the OAI protocol is based on the REST model, but some  
>> people
>> > prefer the SOAP model (although I can't imagine why. ;-))
>> >
>> > In general, REST refers to the use of HTTP URL requests that produce
>> > some form of HTTP response. This approach is so familiar to us with  
>> web
>> > browsing that we don't even realize it is a convention for providing
>> > lightweight web service like OAI and RSS.
>> >
>> > SOAP, OTOH, generally requires intelligent clients (compared to web
>> > browsers) that can encode requests in SOAP wrappers and decode the  
>> SOAP
>> > responses.
>> >
>> > Jeff
>>
>>
>
>
> _______________________________________________
> OAI-implementers mailing list
> List information, archives, preferences and to unsubscribe:
> http://www.openarchives.org/mailman/listinfo/oai-implementers