It is quite often that we come across requirements in BPM/SOA projects to implement search functionality. Search is a ubiquitous functionality and is becoming an integral part of every software suite. A lot of product suites have in built search capabilities, but are limited, not customizable and extensible and quite cumbersome needing off the shelf implementation for the advanced search functionalities. Again implementing search functionality on a BPM SOA can be quite complex since the purview of such projects are not specific to single applications tied to specific platforms.
Traditionally, developers have implemented search functionalities using powerful APIs like Lucene, Compass etc. Venturing into search APIs for BPM SOA projects would quickly turn the implementation into nightmare. And on top of this the data to be searched might live on the bus or MOM.
What would ideally constitute good search functionality?
1. Should require less effort to implement and shouldn’t involve any core search APIs to be embedded in the applications. In other words, developers should not do any specific coding related to search functionality.
2. A stand alone search engine not tied to a specific system. The search engine itself should reside and function as a separate application.
3. Should be interoperable with other systems - RESTful, JSON, SOAP based queries for searching.
4. Should support XML search, Word/PDF handling and basic text search.
If your requirements sound similar to the above points, the Apache Solr might be your next search engine. Checkout Apache Solr.
No comments:
Post a Comment