Erik, Thanks for the comments. But they raised some doubts in my mind.
What I need to do is to integrate Solr to an environment that communicates via wsdl/SOAP. There will be lots of web services communicating to Solr. Solr will be used like a web service, so I need to make possible for the other side to send a wsdl based message to my web service, and my service to communicate with Solr. Expected message volume is 60.000 messages per hour, peaks of 100.000 messages per hour. And it will scale in months. That's why I am trying to figure the most performance wise way to things. I understood what you said about putting the SOAP at Solr. I agree. That's not smart. Now, I am thinking about the web service talking with an embedded Solr server. Is that you were talking about? 2008/5/12 Erik Hatcher <[EMAIL PROTECTED]>: > On May 12, 2008, at 9:18 AM, Alexander Ramos Jardim wrote: > > > Wouldn't you use a SoapRequestHandler? > > > > First of all, *I* wouldn't really want to be caught coding up any kind of > client or server SOAP call to Solr. Seems mostly ridiculous to me when > Solr's response is malleable to practically any kind of hash/array data > structure format you want already. > > But no, I wouldn't build a request handler for SOAPifying Solr, I don't > think. I'd go as simple as possible and use the Axis web stuff (last time I > did this stuff was ages ago, caveat) and talk to Solr's API - which could be > a call to a request handler internally. > > Would you use SolrJ to make the > > wiring? > > > > No. SolrJ is for Java -> Solr communications, and it does just fine with > out any SOAP in there at all. In fact, the latest incarnations do this with > serialized Java objects of some sort making the data smaller and faster to > process than XML. > > Or would you put the SOAP on the solr server side? > > > > Only on the server-side, if you're a masochist. Otherwise, just use Solr > without SOAP and do something else with your free time :) > > Erik > > -- Alexander Ramos Jardim
