ESOFT 3
Nice Screen Scraper: Web service, Console client
and Web client
H´ector L´opez Sacanell
15 de enero de 2010
1.
Introducci´
on
El objetivo de esta tercera entrega es la de crear un servicio web y publi-carlo en el entorno GAE (Google Application Engine), as´ı como la creaci´on de un cliente sencillo de consola que se pueda comuncar con ´el y finalmente un cliente web que facilite y realice las tareas m´as intuitivamente.
2.
Aplicaci´
on final
La aplicaci´on final se encuentra desplegada y funcionando en el en-torno GAE en la siguiente URL: http://nicescreenscraper.appspot. com. Existen dos versiones desplegas, la primera (versi´on 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´on 2 incluye un cliente web integrado2, as´ı como algunas modificaciones en su arquitectura, para as´ı tener implementados los patrones que se comentaron en la primera en-trega. ´Esta ´ultima es la que est´a marcada como principal.
Ambas versiones se encuentran tanto desplegadas como etiquetadas en el repositorio de c´odigo fuente3.
En la siguiente figura (Figura 1) se puede ver el aspecto final del cliente web. 1 Versi´on 1:http://1.latest.nicescreenscraper.appspot.com/ 2 Versi´on 2:http://2.latest.nicescreenscraper.appspot.com/ 3Google code: http://code.google.com/p/nicescreenscraper/
Figura 1: Aspecto del cliente web
3.
Patrones utilizados
Si realizamos un an´alisis en modo descendendet, primero nos encontra-mos con los clientes (web y consola) y el dise˜no de las interfaces para cada una de ellas. Para el caso del cliente web tenemos claro que el patr´on utili-zado es el de Modelo - Vista - Controlador. Mientras que para el cliente de consola, simplemente est´a utilizando una interfaz, la cual se comunica direc-tamente con un controlador (como en el caso web) siendo el patr´on para este controlador el Front Controller, ya que nos proporciona una centralizaci´on de todas las acciones procedan de donde procedan.
Para el caso de la vista, en el documento de la primera entrega, se co-ment´o que lo mas adecuado ser´ıa utilizar el patr´onTransform View el cual permite trabajar con plantillas, pero en nuestra implementaci´on final no he-mos implementado ning´un tipo de sistema de plantillas, aunque hubiera sido deseado, ya que existe informaci´on que se repite en una y otra ventana.
Si seguimos bajando, nos encontramos con el dominio de la aplicaci´on. En este punto hemos realizado una implementaci´on siguiendo el patr´onTable Module, que junto con el uso del patr´on 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´on no nos encontramos con graves problemas, y los que puedan surgir, son gestionados directamente por la implementaci´on de la capa de persistencia,
en nuestro caso el JDO (m´as concretamente, la implementaci´on particular del JDO en el GAE).
4.
Diagramas de secuencia
Resgistro Para el caso de uso del Registro, hemos a˜nadido una acci´on en el servicio web con el nombre deLogIn. Esta proporciona el canal b´asico 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´on devolver´a un mensaje de error en el caso que un usuario ya registrado en el sistema se identifique con una contrase˜na incorrecta (Figura 2).
Figura 2: Diagrama de secu´encia para el caso de uso del registro
Se puede observar como la informaci´on de respuesta que obtiene el Clien-te corresponde al valor de laSessionID, que no es nada m´as que un valor generado por la funci´on hashMD5, que pretende identificar la sesi´on de un usuario activo. Lo idela hubiera sido a˜nadir un par´ametro m´as en todas las acciones que requiriesen de un usurio ya identificado, para a˜nadir este va-lor, de tal manera que los usuarios pudiesen tener una sesi´on activa (tal y como tenemos en las webs), pero dicha implementaci´on no ha sido realizada y se deja para una futura ampliaci´on. Esta soluci´on a˜nade un nivel m´as de seguridad en la comunicaci´on 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 mues-tra en la Figura 3, que corresponde a la lista de Screen Scrapers p´ublicos.
Desde esta misma pantalla se podr´a realizar la llamada a la ejecuci´on del screen scraper.
La navegaci´on a trav´es de la web es posible gracias al men´u que se encuentra en la parte superior derecha, y que variar´a dependiendo de si el usuario est´a o no registrado/identificado.
Figura 3: Listado de screen scrapers p´ublicos
Registro Si el usuario se quiere identificar/registrar, prodr´a hacerlo si accede a la secci´on deLogina trav´es del men´u. Como el caso de uso indicaba que si el usuario no esta registrado se le registra, el cliente web realiza la misma acci´on. Aunque hubiera sido mejor, a˜nadir una pantalla m´as de registro de usuarios, ya que de esta manera el proceso es m´as intuitivo para el usuario final (Figura 4)4.
4
Figura 4: Resgistro/identificacion
Como curiosidad, las contrase˜nas se guardan encriptadas en la base de datos para mayor seguridad.
Una vez el usuario se haya identificado correctamente, el men´u de Login se cambiar´a por el deLogout.
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.
Figura 5: Listado de screen scrapers privados
Desde esta pantalla el usuairo tiene acceso a todas las acciones que ha-cen referencia a un screen scraper, tales como: ejecutarlo, hacerlo p´ublic, 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 ´unico).
Figura 6: Modificaci´on de los datos de un screen scraper
Ejecuci´on La ejecuci´on 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.
Figura 7: Ejecucion de un screen scraper 1 (petici´on)
6.
Screen Scraper adicional
Hemos desarrollado un Screen scraper adicional que raspa todas las noti-cias de la webhttp://www.elpais.com. En ´el se puede ver como las noticias se pueden dividir en tres tipos (dependiendo de si son muy importantes, nor-males o con gr´afico).
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 etiquetah2(t´ıtulo), mientras que el resumen d ´esta se encuentra en una etiquetap, y ambas englobadas en un div con un class del tipo1, tipo3, bq3, bq5, etc . . .
La DTD Para tal efecto, hemos creado el fichero noticias.dtd con la siguiente definici´on:
<?xml version="1.0" encoding="UTF-8"?> <!ELEMENT noticias (noticia)*>
<!ATTLIST noticias canal CDATA #REQUIRED> <!ELEMENT noticia (titulo, resumen, enlace)> <!ELEMENT titulo (#PCDATA)>
<!ELEMENT resumen (#PCDATA)> <!ELEMENT enlace (#PCDATA)>
Y esta definici´on nos obligar´a a crear un fichero XML resultante que tenga un contenido parecido al que mostramos a continuaci´on:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE cartelera SYSTEM "noticias.dtd"> <noticias canal="Internacional"> <noticia> <titulo></titulo> <resumen></resumen> <enlace></enlace> </noticia> </noticias>