> response. How a query is split up into different queries is the
> responsibility of the target system and we do not have to worry. For the
From what I understand, it's more that they want to receive multiple,
separate queries at the same time rather than one per connection.
For example, say I run a portal site which searches 40 of their databases.
I get 3 searches a second, averaging 20 of their databases as targets.
That's 60 searches a second, with 60 http connections and no chance of
optimisation. Hardly a slashdotting, but multiply that over 20+ portals
and it is.
So you need to be able to send multiple queries and receive multiple
responses, identifying which query and which response match up.
As I've said, I would prefer not using HTTP pipelines, as (a) not all SOAP
kits will allow them and (b) SOAP can be transported over other
protocols than HTTP. It also only really solves the connection issue,
rather than optimization (etc) as you still likely process each query
before getting the next one.
My preferred solution would be something like:
<searchRetrieveRequest> ... </searchRetrieveRequest>
Remember that requests might also be scan not just search.
,'/:. Dr Robert Sanderson ([log in to unmask])
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Nebmedes: telnet: nebmedes.o-r-g.org 7777
____/:::::::::::::. WWW: http://nebmedes.o-r-g.org:8000/
I L L U M I N A T I