Sorry, but I don't think you have a clear understanding of web services. In order to design a really useful WebService it is almost always best to create a web service API that is drastically different (usually much simpler) than the underlying systems API.
Think of the web service interface to most financial systems. The "records" they return are usually a small subset of the information maintained by the system - if they tried to expose the underlying system directly it would takes years for a single client to be developed. Most webservices must be consumed by systems that have no concept of objects, inheritance, etc. so attempting to expose a complex system interface using automated tools and have it work with all clients is futile - it may be possible, but it certainly wouldn't be very useful. For an example, take a look at the google web api. There are no methods to perform inserts, not that they couldn't allow it, they just decided not to. In the same vain, there is no reason you cannot develop simpler, flat objects and interfaces for Lucene (a web doc, a web search request, a web insert request). Lucene is a library api. Most web service APIs use a far simpler "consumer" interface. Robert Engels -----Original Message----- From: Maros Ivanco [mailto:[EMAIL PROTECTED] Sent: Thursday, August 18, 2005 11:40 AM To: java-dev@lucene.apache.org Subject: RE: lucene API -----"Robert Engels" <[EMAIL PROTECTED]> wrote: ----- >To: <java-dev@lucene.apache.org> >From: "Robert Engels" <[EMAIL PROTECTED]> >Date: 17.08.2005 16:20 >Subject: RE: lucene API > >I think you should leave the API as is, and write a custom XML writer >for >lucene search results. The request is trivial since you can simple >pass the >single string. Well, actually that is not true. You assume that all I need to do is the search. But I also need to expose index reading and index writing API. I need reading API to remove expired documents, index management, end so forth. I need writing API to write documents by robot which resides on different machine. Anyway, even exposing only the search API is not trivial in the case you want to search in multiple languages (you have to use custom analyzers), specify order, or filter. Even if you would not, there is always Hits object, which is (by its nature) nonserializable. >I would not write wrapper beans just to use the >built-in >serialization support. > >The custom XML writer will be MUCH, MUCH faster, as you do not need >to create an XML document first. Perhaps faster to run (I must admit you have a point here), but defenetly not faster to develop. Usage of the custom de/serializers is also discouraged by jax-rpc spec (which is not an issue), and is not well documented. Anyway, it is imposible to write de/serializers for certain Lucene classes. For instance, you cannot write de/serializers for org.apache.lucene.search.Filter and its subclasses, because the inner state of their instances is not accessible. Other examples of nonserializable classes include Hits, Sort, SortField, ScoreDoc, TopDocs, ... So, to summarize, I do not see Lucene API ready for integration with other systems, even though it may be very effective when used standalone. Maros. >The XML needed to support a Lucene >search >result is quite trivial. > >R > >-----Original Message----- >From: Maros Ivanco [mailto:[EMAIL PROTECTED] >Sent: Wednesday, August 17, 2005 8:27 AM >To: java-dev@lucene.apache.org >Cc: Marek Baumerth >Subject: lucene API > > > > >Hi there, > > I am creating a search solution based on Lucene. A part of the >solution > is Lucene web service. Even though the Lucene API is very >straitforward > to use on a local machine, I found creation of Lucene WS to be >extremely > difficult. The problem causes the API, which very often does not >obey > even trivial coding conventions (getter and setter names, for >instance). > As a result, the jax-rpc subsystem is unable to produce correct > serializers and deserializers. From my point of view, there are >serveral > possibilities to solve the problem: > > 1., write envelopes for nonserializable objects (Document, Field, >Term, > ...) > 2., write custom serializers and deserializers > 3., change lucene API > >1. requires creation of many envelopes, since most of the Lucene >classes do >not obey JavaBean semantics thus, they are not serializable by >jax-rpc. >Wrapping and uwrapping of Lucene objects takes extra processing. >Moreover, >the un/wrapping is sometimes not possible, because some objects >(Filters, >for instance) do not exhibit their full state. I am doing this right >now >(and doing, and doing,... I cannot see the end :-)). > >2. requires creation of de/serializer for every nonserializable >class. Also >requires extra configuration + generation of factories. Twice as >difficult >as solution 1. Moreover, this solution renders resulting WS as >nonportable. > >3. requires change of lucene API in the way that will allow either >direct >de/serialization or, at least, the solution 1. As far as Lucene is >open >sourced, everybody can make changes, but the real question is, >whether the >changes will become part of the official distribution. If not, the >overall >search solution will remain stucked with current release. > >I would personally prefer the third one, but only if the changes will >make >it to the official release. Our company plans to deploy several >instances >of the solution. There is certain probability, that my employer will >contribute some resources (my time) to the project. The question is, >whether the contemporary development comunity is willing to accept >this >kind of changes and if I can participate. So, is it? > >Maros. > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
