Partager via

Thoughts on "Search as a Service"

  • Article

The buzzword on Software as a Service has been around for quite some time.  It has spawned many other "**** as a Service" (i.e. Database as a Service, Email as a Service, etc...) Some popular, some not so much.  So I would like to bring up a "**** as a Service" called Search as a Service. The idea here goes beyond a Search API. Search as a Service in my mind differs from Software as a Service.  If I were to truly use the Software as a Service model and apply it to search.  i would have a search API for my application to interface with and the search engine would be able to index my data.  There lies the problem for most organizations out there.  Most CIO's would not be thrilled with allowing an outside source to index their internal network.  So as of today, it probably would not be common place to see the SaaS model applied to Search. 

So then what could Search as a Service be? Well, it may contain an architecture that would allow any user interface to communicate with any search engine.  Effectively allowing any search application to pick and choice which search engine it utilizes.  It would also be able to send an application specific set of query-data that is translated into a search engine specific query langauge.  Finally, the output from the search engine would be translated into a common format that the application can understand.  This allows a single application to use any search engine and expect the results in a format it understands.  Search as a Service could also support federation between heterogenous search engines.

Implementation of such a service would probably involve of an intermediary set of components that could be leveraged directly or exposed via some sort of web service.  This service could support multiple search engines as well as multiple applications. A given application could send its query data as well as specify which search engine(s) to service it's request to this service where it would translate the query data into the search engine's query language. Then the service would return the search results back to the application in a format that the application understands.  This format could be XML, JSON or whatever works best for the application.

So why not OpenSearch?  Well while OpenSearch addresses some issues such as returned format, if use the RSS or ATOM resultset. It does not currently solve the issue have handling search engine query languages.  For simple searches this typically is not an issue, but if you want to use an advanced search interface.  Having to handle multiple search engine query languages can be a pain.

In my personal experience, every search UX implementation I have worked with has required too much custom design and development with little to no re-usable code produced. I think this concept could significantly reduce the amount of customization and increase the amount of re-usable components.

Comments

  • Anonymous
    March 20, 2009
    PingBack from http://www.anith.com/?p=21289

  • Anonymous
    March 20, 2009
    While this seems like an amazing idea up front, the practicality of 'Search as a Service' doesn't seem to hold up unfortunately (yet). Different search engines require different parameters as a general rule and, for some reason do not output to something ubiquitous like XML. However, with an intermediary, this could change. If you had a service that spoke the language of several search engines and translated it back into one, very standardized XML output, then we'd be in business. That would be something I'd use for sure.

  • Anonymous
    March 21, 2009
    Thanks for the comment cranjenny. I agree with you this 'intermediary' is exactly what I am thinking. I updated my post to include ideas to address the implementation.