ESOFT 3 Nice Screen Scraper: Web service, Console client and Web client Héctor López Sacanell hlopez1@alumnes.udl.cat 15 de enero de 2010 1. Introducción El objetivo de esta tercera entrega es la de crear un servicio web y publicarlo en el entorno GAE (Google Application Engine), así como la creación de un cliente sencillo de consola que se pueda comuncar con él y finalmente un cliente web que facilite y realice las tareas más intuitivamente. 2. Aplicación final La aplicación final se encuentra desplegada y funcionando en el entorno GAE en la siguiente URL: http://nicescreenscraper.appspot. com. Existen dos versiones desplegas, la primera (versión 1) 1 corresponde a la simple funcional de servicio web (sin cliente web), con lo que se tenía que utilizar un cliente externo. Mientras que la versión 2 incluye un cliente web integrado 2, así como algunas modificaciones en su arquitectura, para así tener implementados los patrones que se comentaron en la primera entrega. Ésta última es la que está marcada como principal. Ambas versiones se encuentran tanto desplegadas como etiquetadas en el repositorio de código fuente 3. En la siguiente figura (Figura 1) se puede ver el aspecto final del cliente web. 1 Versión 1: http://1.latest.nicescreenscraper.appspot.com/ 2 Versión 2: http://2.latest.nicescreenscraper.appspot.com/ 3 Google code: http://code.google.com/p/nicescreenscraper/ 1
Figura 1: Aspecto del cliente web 3. Patrones utilizados Si realizamos un análisis en modo descendendet, primero nos encontramos con los clientes (web y consola) y el diseño de las interfaces para cada una de ellas. Para el caso del cliente web tenemos claro que el patrón utilizado es el de Modelo - Vista - Controlador. Mientras que para el cliente de consola, simplemente está utilizando una interfaz, la cual se comunica directamente con un controlador (como en el caso web) siendo el patrón para este controlador el Front Controller, ya que nos proporciona una centralización de todas las acciones procedan de donde procedan. Para el caso de la vista, en el documento de la primera entrega, se comentó que lo mas adecuado sería utilizar el patrón Transform View el cual permite trabajar con plantillas, pero en nuestra implementación final no hemos implementado ningún tipo de sistema de plantillas, aunque hubiera sido deseado, ya que existe información que se repite en una y otra ventana. Si seguimos bajando, nos encontramos con el dominio de la aplicación. En este punto hemos realizado una implementación siguiendo el patrón Table Module, que junto con el uso del patrón Table Data Gateway, en la capa de persistencia, hacen el equipo perfecto para tener los datos accessibles. Para el problema de la concurrencia, tenemos que en nuestra aplicación no nos encontramos con graves problemas, y los que puedan surgir, son gestionados directamente por la implementación de la capa de persistencia, 2
en nuestro caso el JDO (más concretamente, la implementación particular del JDO en el GAE). 4. Diagramas de secuencia Resgistro Para el caso de uso del Registro, hemos añadido una acción en el servicio web con el nombre de LogIn. Esta proporciona el canal básico para poder identificarse en el sistema como un usuario, y en el caso de ser nuevo, se procede al registro de dicho usuario. Esta acción devolverá un mensaje de error en el caso que un usuario ya registrado en el sistema se identifique con una contraseña incorrecta (Figura 2). Figura 2: Diagrama de secuéncia para el caso de uso del registro Se puede observar como la información de respuesta que obtiene el Cliente corresponde al valor de la SessionID, que no es nada más que un valor generado por la función hash MD5, que pretende identificar la sesión de un usuario activo. Lo idela hubiera sido añadir un parámetro más en todas las acciones que requiriesen de un usurio ya identificado, para añadir este valor, de tal manera que los usuarios pudiesen tener una sesión activa (tal y como tenemos en las webs), pero dicha implementación no ha sido realizada y se deja para una futura ampliación. Esta solución añade un nivel más de seguridad en la comunicación servicio web-cliente. El resto de diagramas son muy parecidos, y en los que se puede apreciar la misma estructura de Cliente-Controlador-Dominio-Persistencia. 5. Cliente web Principal En la pantalla principal nos encontraremos con lo que se muestra en la Figura 3, que corresponde a la lista de Screen Scrapers públicos. 3
Desde esta misma pantalla se podrá realizar la llamada a la ejecución del screen scraper. La navegación a través de la web es posible gracias al menú que se encuentra en la parte superior derecha, y que variará dependiendo de si el usuario está o no registrado/identificado. Figura 3: Listado de screen scrapers públicos Registro Si el usuario se quiere identificar/registrar, prodrá hacerlo si accede a la sección de Login a través del menú. Como el caso de uso indicaba que si el usuario no esta registrado se le registra, el cliente web realiza la misma acción. Aunque hubiera sido mejor, añadir una pantalla más de registro de usuarios, ya que de esta manera el proceso es más intuitivo para el usuario final (Figura 4) 4. 4 Se ha creado un usuario de pruebas cuyo username/password son: hector/111 4
Figura 4: Resgistro/identificacion Como curiosidad, las contraseñas se guardan encriptadas en la base de datos para mayor seguridad. Una vez el usuario se haya identificado correctamente, el menú de Login se cambiará por el de Logout. Listado Screen scrapers privados Una vez el usuairo se ha identificado, se le reenvia directamente a la siguiente pantalla (Figura 5), donde se le muestran todos los screen scrapers dados de alta de su usuario. En dicha lista se pueden identificar con un color azulado aquellos screen scrapers que son privados y no son accesibles para otros usuarios. 5
Figura 5: Listado de screen scrapers privados Desde esta pantalla el usuairo tiene acceso a todas las acciones que hacen referencia a un screen scraper, tales como: ejecutarlo, hacerlo públic, modificarlo y borrarlo. Modificar En esta pantalla (Figura 6), podemos ver los datos de un screen scraper para modificarlos (el nombre no se puede modificar ya que es el identificador único). 6
Figura 6: Modificación de los datos de un screen scraper Ejecución La ejecución de un screen scraper se compone de dos pantallas, ya que en la primera (Figura 7) se le pide al usuario que introduzca la URL indicada a raspar. Mientras que en la segunda fase (Figura 8), se muestra el resultado del raspado. 7
Figura 7: Ejecucion de un screen scraper 1 (petición) Figura 8: Ejecucion de un screen scraper 2 (respuesta) 8
6. Screen Scraper adicional Hemos desarrollado un Screen scraper adicional que raspa todas las noticias de la web http://www.elpais.com. En él se puede ver como las noticias se pueden dividir en tres tipos (dependiendo de si son muy importantes, normales o con gráfico). Figura 9: Noticias de la web elpais.com En la captura de pantalla se puede ver como el contenido principal de una noticia se encuentra en la etiqueta h2 (título), mientras que el resumen d ésta se encuentra en una etiqueta p, y ambas englobadas en un div con un class del tipo 1, tipo 3, bq3, bq5, etc... La DTD Para tal efecto, hemos creado el fichero noticias.dtd con la siguiente definición: <?xml version="1.0" encoding="utf-8"?> <!ELEMENT noticias (noticia)*> <!ATTLIST noticias canal CDATA #REQUIRED> <!ELEMENT noticia (titulo, resumen, enlace)> <!ELEMENT titulo (#PCDATA)> 9
<!ELEMENT resumen (#PCDATA)> <!ELEMENT enlace (#PCDATA)> Y esta definición nos obligará a crear un fichero XML resultante que tenga un contenido parecido al que mostramos a continuación: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE cartelera SYSTEM "noticias.dtd"> <noticias canal="internacional"> <noticia> <titulo></titulo> <resumen></resumen> <enlace></enlace> </noticia> </noticias> 10