: of the components as well as the flow of data and queries. The result is : a conceptual architecture diagram, clearly showing how Solr relates to : the app-server, how cores relate to a Solr instance, how documents enter : through an UpdateRequestHandler, through an UpdateChain and Analysis and : into the Lucene index etc.
Looks really good, but two bits that i think might confuse people are the implications that a "Query Parser" then invokes a series of search components; and that "analysis" (and the pieces of an analyzer chain) are what to lookups in the underlying lucene index. the first might just be the ambiguity of "Query" .. using the term "request parser" might make more sense, in comparison to the "update parsing" from the other side of hte diagram. the analysis piece is a little harder to fix cleanly. you really want the end of the analysis chain to feed back up to the searh components, and then show it (most of hte search components really) talking to the Lucene index. FWIW: the last time i tried to do an arcitecture diagram for solr was my "Beyond the Box" talk a few years back, targeted at people interested in writing plugins. I made my job a lot easier then what you tackled by keeping it at the 50,000 foot level where the SOlrRequestHandler was the smallest unit of work i described. From that fiew there are nice parallels that can be drawn with more traditional MVC architectures which make it a little easier for people to understand... http://people.apache.org/~hossman/apachecon2008us/btb/ Slides #9 & 10 -Hoss