Query Windows Search de Java

Question

Me gustaría hacer una consulta directamente al servicio de búsqueda de Windows Vista (o indirectamente) desde Java.

Sé que es posible consultar utilizando el protocolo search-ms: pero me gustaría consumir el resultado dentro de la aplicación.

He encontrado buena información en el Windows Search API pero ninguna relacionada con Java.

Marcaré como aceptada la respuesta que proporciona información útil y definitiva sobre cómo lograr esto.

Gracias de antemano.

EDITAR

¿Alguien tiene una muestra JACOB, antes de que pueda marcar esto como aceptado? :)

Answer 1

Es posible que desee ver una de las tecnologías de integración Java-COM. He trabajado personalmente con Jacob (Java Puente COM):

• http://danadler.com/jacob/

que era bastante engorroso (piensa trabajar exclusivamente con la reflexión), pero consiguió el trabajo hecho por mí (la prueba rápida del concepto, accediendo a MapPoint desde dentro de Java).

El único otro tipo de tecnología yo sepa es Jawin, pero no tengo ninguna experiencia personal con:

• http://jawinproject.sourceforge.net/

Actualización 26/04/2009: Simplemente por pura casualidad investigué más en Microsoft Windows Search y encontré una manera fácil de integrarlo utilizando OLE DB. Aquí hay algo de código que he escrito como una prueba de concepto:

public static void main(String[] args) { 
    DispatchPtr connection = null; 
    DispatchPtr results = null; 
    try { 
     Ole32.CoInitialize(); 
     connection = new DispatchPtr("ADODB.Connection"); 
     connection.invoke("Open", 
      "Provider=Search.CollatorDSO;" + 
      "Extended Properties='Application=Windows';"); 
     results = (DispatchPtr)connection.invoke("Execute", 
      "select System.Title, System.Comment, System.ItemName, System.ItemUrl, System.FileExtension, System.ItemDate, System.MimeType " + 
      "from SystemIndex " + 
      "where contains('Foo')"); 
     int count = 0; 
     while(!((Boolean)results.get("EOF")).booleanValue()) { 
      ++ count; 
      DispatchPtr fields = (DispatchPtr)results.get("Fields"); 
      int numFields = ((Integer)fields.get("Count")).intValue(); 

      for (int i = 0; i < numFields; ++ i) { 
       DispatchPtr item = 
        (DispatchPtr)fields.get("Item", new Integer(i)); 
       System.out.println(
        item.get("Name") + ": " + item.get("Value")); 
      } 
      System.out.println(); 
      results.invoke("MoveNext"); 
     } 
     System.out.println("\nCount:" + count); 
    } catch (COMException e) { 
     e.printStackTrace(); 
    } finally { 
     try { 
      results.invoke("Close"); 
     } catch (COMException e) { 
      e.printStackTrace(); 
     } 
     try { 
      connection.invoke("Close"); 
     } catch (COMException e) { 
      e.printStackTrace(); 
     } 
     try { 
      Ole32.CoUninitialize(); 
     } catch (COMException e) { 
      e.printStackTrace(); 
     } 
    } 
} 

Para compilar este, que necesita para asegurarse de que el JAR Jawin está en la ruta de clases, y que jawin.dll está en su camino (o java propiedad del sistema .library.path). Este código simplemente abre una conexión ADO al índice local de Windows Desktop Search, consulta documentos con la palabra clave "Foo" e imprime algunas propiedades clave en los documentos resultantes.

Avíseme si tiene alguna pregunta o si necesita que le aclare algo.

Actualización 04/27/2009: Probé la ejecución del mismo en JACOB, así, y voy a hacer algunos puntos de referencia para comparar las diferencias de rendimiento entre los dos. Puede que esté haciendo algo mal en JACOB, pero parece que consistentemente está usando 10 veces más memoria. Trabajaré en una implementación de jcom y com4j también, si tengo algo de tiempo, y trataré de descubrir algunas peculiaridades que creo que se deben a la falta de seguridad en el hilo en alguna parte. Incluso puedo probar una solución basada en JNI.Espero terminar con todo en 6-8 semanas.

Actualización 04/28/2009: Esto es solo una actualización para aquellos que han estado siguiendo y curiosos. Resulta que no hay problemas de enhebrado, solo necesitaba cerrar explícitamente los recursos de mi base de datos, ya que las conexiones OLE DB están supuestamente agrupadas en el nivel del sistema operativo (probablemente debería haber cerrado las conexiones de todos modos ...). No creo que haya más actualizaciones de esto. Avíseme si alguien tiene algún problema con esto.

Actualización 05/01/2009: Ejemplo de JACOB agregado por solicitud del Oscar. Esto pasa por la misma secuencia de llamadas desde una perspectiva COM, simplemente usando JACOB. Si bien es cierto JACOB se ha trabajado mucho más activa en los últimos tiempos, también me doy cuenta de que es todo un cerdo de la memoria (utiliza 10 veces más memoria que la versión Jawin)

public static void main(String[] args) { 
    Dispatch connection = null; 
    Dispatch results = null; 

    try { 
     connection = new Dispatch("ADODB.Connection"); 
     Dispatch.call(connection, "Open", 
      "Provider=Search.CollatorDSO;Extended Properties='Application=Windows';"); 
     results = Dispatch.call(connection, "Execute", 
      "select System.Title, System.Comment, System.ItemName, System.ItemUrl, System.FileExtension, System.ItemDate, System.MimeType " + 
      "from SystemIndex " + 
      "where contains('Foo')").toDispatch(); 
     int count = 0; 
     while(!Dispatch.get(results, "EOF").getBoolean()) { 
      ++ count; 
      Dispatch fields = Dispatch.get(results, "Fields").toDispatch(); 
      int numFields = Dispatch.get(fields, "Count").getInt(); 

      for (int i = 0; i < numFields; ++ i) { 
       Dispatch item = 
        Dispatch.call(fields, "Item", new Integer(i)). 
        toDispatch(); 
       System.out.println(
        Dispatch.get(item, "Name") + ": " + 
        Dispatch.get(item, "Value")); 
      } 
      System.out.println(); 
      Dispatch.call(results, "MoveNext"); 
     } 
    } finally { 
     try { 
      Dispatch.call(results, "Close"); 
     } catch (JacobException e) { 
      e.printStackTrace(); 
     } 
     try { 
      Dispatch.call(connection, "Close"); 
     } catch (JacobException e) { 
      e.printStackTrace(); 
     } 
    } 
} 

Answer 2

Cualquier razón por la cual no se podía utilizar sólo Runtime.exec() para consultar a través de search-ms y leer el BufferedReader con el resultado del comando? Por ejemplo:

public class ExecTest { 
    public static void main(String[] args) throws IOException { 
     Process result = Runtime.getRuntime().exec("search-ms:query=microsoft&"); 

     BufferedReader output = new BufferedReader(new InputStreamReader(result.getInputStream())); 
     StringBuffer outputSB = new StringBuffer(40000); 
     String s = null; 

     while ((s = output.readLine()) != null) { 
      outputSB.append(s + "\n"); 
      System.out.println(s); 
     } 

     String result = output.toString(); 
    } 
} 

Answer 3

Hay varias bibliotecas por ahí para llamar Los objetos COM de Java, algunos son de código abierto (pero su curva de aprendizaje es más alta) algunos son de código cerrado y tienen una curva de aprendizaje más rápida. Un ejemplo de fuente cerrada es EZCom. Los comerciales tienden a centrarse en llamar a Java desde Windows también, algo que nunca he visto en opensource.

En su caso, lo que le sugiero que haga es atender la llamada en su propia clase .NET (supongo que use C# como el más cercano a Java sin entrar en el controvertido J #), y centrarse en hacer la interoperabilidad con el .NET dll. De esa forma, la programación de Windows se vuelve más fácil, y la interfaz entre Windows y Java es más simple.

Si está buscando cómo usar una biblioteca de java com, MSDN es el lugar equivocado. Pero MSDN te ayudará a escribir lo que necesites desde .NET y luego verás los tutoriales de la biblioteca de com sobre cómo invocar uno o dos métodos que necesitas de tus objetos .NET.

EDIT:

Teniendo en cuenta lo expuesto en las respuestas sobre el uso de un servicio Web, usted podría (y probablemente tendrá mejor suerte) construir una pequeña aplicación .NET que llama a un servidor web Java embebido en lugar de tratar de hacer .NET tiene el servicio web incorporado, y java es el consumidor de la llamada. Para un servidor web incorporado, mi investigación mostró que Winstone es bueno. No es el más pequeño, pero es mucho más flexible.

La forma de hacerlo funcionar es iniciar la aplicación .NET desde Java, y hacer que la aplicación .NET llame al servicio web en un temporizador o un ciclo para ver si hay una solicitud, y si es así, procesarlo y enviar la respuesta.

Answer 4

Como pocas publicaciones aquí sugieren que puede tender un puente entre Java y .NET o COM utilizando marcos comerciales o gratuitos como JACOB, JNBridge, J-Integra, etc. En realidad tuve una experiencia con uno de estos terceros (un uno caro :-)) y debo decir que haré todo lo posible para evitar repetir este error en el futuro. La razón es que involucra muchas cosas "vudú" que realmente no se pueden depurar, es muy complicado entender cuál es el problema cuando las cosas van mal.

La solución que sugiero que implemente es crear una aplicación .NET simple que realice las llamadas reales a la API de búsqueda de Windows. Después de hacerlo, debe establecer un canal de comunicación entre este componente y su código Java. Esto se puede hacer de varias maneras, por ejemplo, enviando mensajes a un pequeño DB que su aplicación extraerá periódicamente. O registrar este componente en la máquina IIS (si existe) y exponer la simple API WS para comunicarse con ella.

Sé que puede sonar engorroso, pero las claras ventajas son: a) se comunica con Windows Search API utilizando el lenguaje que entiende (.NET o COM), b) controla todas las rutas de las aplicaciones.