capitulo5/capitulo5.tex

   1 \chapter{Diseño de las aplicaciones Web y Android}
   2
   3
   4 \section{Capa de persistencia, modelado bases de datos}
   5
   6 El modelo entidad relación, fue propuesto por Peter Chen para el modelado de bases de datos usando técnicas gráficas con las que los humanos pueden interactuar de forma sencilla. Los humanos pueden percibir fácilmente las entidades (ver definición más abajo) y sus características en el mundo real y representar cualquier relación entre ellas. El objetivo del modelado gráfico es incluso más profundo que simplemente representar estas entidades y relaciones; el ingeniero de bases de datos puede usar herramientas para modelar estas entidades y sus relaciones y luego generar automáticamente esquemas de bases de datos, es decir: las tablas de la base de datos, las claves primarias, las claves extranjeras y cualquier limitación que exista entre datos y claves. Potencialmente estas herramientas pueden mejorar la productividad de los diseñadores mediante la automatización de tareas. Y lo que es más importante, estas herramientas pueden crear la documentación requerida para el mantenimiento futuro~\cite{C5:EntityRelationship}.
   7
   8 \subsection{Elementos en el modelo Entidad Relación}
   9
  10 \begin{itemize}
  11     \item \textbf{Entidad}: es una ``cosa'' o un ``objeto'' en el mundo real que se distingue de todos los otros objetos. Por ejemplo: un coche, un estudiante, un curso, etc. Una entidad tiene un conjunto de propiedades o atributos. Por ejemplo un estudiante tiene varios atributos como pueden ser: nombre, dirección, código postal, etc. Uno o más atributos pueden identificar de forma unívoca a la entidad. También, en el mundo real las entidades tienen alguna relación. Por ejemplo, un estudiante toma cursos. Por lo tanto, el mundo real puede ser modelado en términos de \textbf{Entidad-Relación}. Existen entidades fuertes y débiles. Una fuerte es totalmente independiente mientras que una débil depende de la existencia de otra.
  12     \item \textbf{Atributos}: describen propiedades que poseen cada entidad o relación. Cada atributo posee un conjunto de valores asociados llamado dominio. El dominio se define como los valores posibles que puede tomar el atributo.
  13     \item \textbf{Relación}: como se ha mencionado en el punto anterior, es una correspondencia o asociación entre dos o más entidades. El número de participantes en una relación es lo que se denomina grado de la relación. Por lo tanto, una relación en la que participan dos entidades es una relación binaria. Si son tres las entidades será una relación ternaria, etc. La cardinalidad por otro lado, es el número mínimo y máximo de correspondencias en las que puede tomar parte cada ocurrencia de cada entidad. La participación puede ser obligatoria (total) si la existencia de cada una de sus ocurrencias requiere la existencia de al menos una ocurrencia de la otra entidad participante. Si no, la participación es opcional (parcial)
  14     \item \textbf{Identificador}: es un atributo o conjunto de atributos que determina de modo único cada ocurrencia de esa entidad. Nunca pueden existir dos entidades con el mismo identificador.
  15 \end{itemize}
  16
  17 \subsection{Modelado UML}
  18
  19 El Lenguaje de Modelado Unificado (UML por sus siglas en Inglés) comenzó como una colección de notaciones para soportar el diseño orientado a objetos. Deriva de diferentes aproximaciones y por tanto no hay una única notación si no un conjunto de notaciones para el modelado de diversos elementos como son clases, eventos, comportamientos y otros componentes de los programas.
  20
  21 En la práctica UML también permite utilizar sus notaciones para el modelado de bases de datos relacionales\footnote{\url{http://www.tdan.com/view-special-features/8457}} (basadas en el modelo Entidad Relación)
  22
  23 En esta memoria de este proyecto se empleará el lenguaje UML para la representación gráfica de las bases de datos de la aplicación Web y Android. Las relaciones entre entidades se representan con flechas, las entidades con cajas y sus atributos son escritos dentro de las cajas que representan las entidades. También se puede observar el grado de participación y la cardinalidad entre entidades en una relación; siguiendo la notación UML:
  24 \begin{itemize}
  25     \item \textbf{0..1}: Participación no obligatoria y cardinalidad máxima 1.
  26     \item \textbf{1}: Participación obligatoria por parte de esa relación y cardinalidad 1.
  27     \item \textbf{*}: Participación no obligatoria y cardinalidad n (valor entre 0 e infinito)
  28     \item \textbf{1..*}: Participación obligatoria y cardinalidad n (entre 1 e infinito)
  29 \end{itemize}
  30
  31
  32 \subsection{Base de datos aplicación Web, modelado UML}
  33
  34 En la siguiente figura en la cual se representa la base de datos de la aplicación Web, cabe destacar la información que a continuación se describe:
  35
  36 \subsubsection{Tabla sfGuardUser}
  37
  38 Permite almacenar parámetros relacionados con la identificación del usuario (password, dirección de correo, nombre, apellidos, etc)
  39
  40 \begin{itemize}
  41     \item \textbf{algorithm}: el password se encuentra cifrado, con este campo se permite variar el algoritmo de cifrado si se desea.
  42     \item \textbf{fk\_LaguageId}: es una \emph{foreign key} que permite asignar a un usuario un determinado idioma.
  43 \end{itemize}
  44
  45 \subsubsection{Tabla Office}
  46
  47 Contiene información relacionada con una sucursal u oficina perteneciente a una empresa. En principio, una compañía no tendría por qué tener oficinas o sucursales de ahí que pueda haber entre 0 e infinitas sucursales u oficinas por compañía.
  48
  49 \begin{itemize}
  50     \item \textbf{office\_gps}: es un dato de tipo \emph{geography(POINT,4326)} Más adelante, en el capítulo de implementación se explicará más acerca de este tipo particular de dato PostGIS.
  51     \item \textbf{fk\_CityId}: una oficina puede encontrarse o no en una determinada ciudad. A través de este campo se permite relacionar oficinas o sucursales con ciudades, regiones y por último países.
  52     \item \textbf{fk\_CompanyId}: marca la relación entre la oficina o sucursal y la compañía. Puede haber compañías sin sucursales pero nunca una oficina o sucursal sin compañía asociada.
  53 \end{itemize}
  54
  55 \subsubsection{Tabla AdDescription}
  56
  57 Sirve para internacionalizar la información relacionada con los anuncios. De este modo cuando se crea un anuncio se puede crear en tantos idiomas como el sistema admita, así el usuario recibirá el anuncio en el idioma que él o ella previamente configuraron.
  58
  59 \begin{itemize}
  60     \item \textbf{fk\_LanguageId}: relación entre esta tabla y la de idiomas (tabla ``Language'')
  61     \item \textbf{fk\_AdId}: un anuncio puede tener n descripciones en n diferentes idiomas.
  62     \item \textbf{ad\_gps}: es un dato de tipo \emph{geography(POINT,4326)} utilizado por PostGIS, del cual se hablará en el capítulo donde se explica la implementación de la aplicación.
  63 \end{itemize}
  64
  65 \subsubsection{Tabla CompanyCategory}
  66
  67 Permite a los usuarios que administran compañías en el sistema crear nuevas categorías. Al mismo tiempo, los anuncios que estos usuarios administradores de compañías crean, pueden ser asociados con estas categorías de compañía que se encuentran en esta tabla. Se utiliza una estructura jerárquica del ORM Doctrine proporcionado por Symfony conocida como \emph{Nested Set}\footnote{\url{http://docs.doctrine-project.org/projects/doctrine1/en/latest/en/manual/hierarchical-data.html\#nested-set}}
  68
  69 \begin{itemize}
  70     \item \textbf{fk\_GeneralCategId}: los usuarios finales, aquellos que recibirán los anuncios en sus dispositivos móviles se asocian a categorías generales que existen previamente en el sistema. El usuario que administra su empresa en el sistema debe asociar su categorías propias a las categorías generales del sistema para que los usuarios móviles puedan recibir anuncios. A través de esta \emph{foreign key} se establece dicha asociación en la capa de persistencia de la aplicación web.
  71 \end{itemize}
  72
  73 \subsubsection{Tabla UserBasket}
  74
  75 Sirve para persistir las categorías seleccionadas por el usuario final de las cuales desea recibir anuncios relacionados.
  76
  77 \subsubsection{Tabla Language}
  78
  79 Almacena la relación entre el nombre de idioma y el código que lo representa. Este código se basa en el formato estándar \textbf{ISO 639-3}\footnote{\url{http://en.wikipedia.org/wiki/ISO\_639-3}} y la tabla puede ser poblada con datos provenientes de sitios públicos en Internet de forma realmente sencilla.
  80
  81 \begin{landscape}
  82     \centering
  83     \includegraphics[width=1.4\textwidth,height=1\textheight]{fig/MobiAdsWebDataBase}
  84 \end{landscape}
  85
  86 \subsection{Base de datos aplicación Android, modelado UML}
  87
  88 \begin{figure}[H]
  89     \centering
  90         \includegraphics[width=0.8\textwidth]{fig/MobiAdsAndroidDataBase}
  91     \caption{\emph{Diagrama de la base de datos, aplicación Android}}
  92     \label{fig:MobiAdsAndroidDataBase}
  93 \end{figure}
  94
  95 En la Figura~\ref{fig:MobiAdsAndroidDataBase}) donde se representa la única tabla de la que está compuesta la base de datos de la aplicación Android, los campos representan la siguiente información:
  96
  97 \begin{itemize}
  98     \item \textbf{id}: índice en la tabla. Autoincremental y único por cada fila.
  99     \item \textbf{idad}: identificador único del anuncio.
 100     \item \textbf{adName}: nombre descriptivo del anuncio que será mostrado en la pantalla del dispositivo móvil del usuario.
 101     \item \textbf{text}: texto con información acerca del anuncio que también será presentado en la pantalla del usuario.
 102     \item \textbf{url}: dirección web donde se encuentra el resto del anuncio, con más información que al usuario pueda interesar.
 103     \item \textbf{isRead}: Android hace uso de SQLite, esta base de datos no implementa \emph{booleans} por tanto, éstos deben ser creados haciendo uso de \emph{integers}. Este valor indica si el usuario ya ha leído el anuncio o si por el contrario todavía no.
 104     \item \textbf{path}: lugar en el sistema de archivos del dispositivo móvil donde la imagen que representa el anuncio es almacenada.
 105 \end{itemize}
 106
 107 \section{Diagrama de clases aplicación Android}
 108
 109 \begin{figure}[H]
 110     \centering
 111         \includegraphics[width=1\textwidth]{fig/MobiAdsObjects}
 112     \caption{\emph{Diagrama de clases Android, vision general: MobiAds.}}
 113     \label{fig:MobiAdsObjects}
 114 \end{figure}
 115
 116 En el diagrama de la Figura~\ref{fig:MobiAdsObjects}) se muestra la existencia de las cuatro \emph{Activities}\footnote{Android \emph{Activities}, ver: \url{http://developer.android.com/reference/android/app/Activity.html}} así como su relación con otras partes de la aplicación Android. Por ejemplo, se muestra claramente como \emph{Activities} relacionadas con la representación de los datos descargados deben acceder a la base de datos SQLite de la aplicación a través de una clase denominada \textbf{IndexerProvider}.
 117
 118 La clase denominada \textbf{MobiAdsBatch}, como su nombre hace presagiar se encargará de realizar acciones en segundo plano mediante un servicio de Android configurado para tal fin (la clase \textbf{MobiAdsService}). Y por último la clase \textbf{DefaultHttpClient} se encargará de las comunicaciones HTTP con el servidor Web.
 119
 120 Por otro lado en la Figura~\ref{fig:MobiAdsService}) se hace zoom para mostrar al lector de qué clases se compone internamente \textbf{MobiAdsService}. Este servicio en segundo plano, se ejecutará a voluntad del usuario y a través de la implementación de la clase \textbf{LocationListener} de Android permitirá realizar peticiones automáticas al servidor Web a medida que el usuario varía su posición física. Las coordenadas GPS serán recibidas por \textbf{MobiAdsBatch} que las procesará y llevará a cabo las acciones que correspondan como será explicado en las siguientes páginas.
 121
 122 \begin{figure}[H]
 123     \centering
 124         \includegraphics[width=1\textwidth]{fig/MobiAdsService}
 125     \caption{\emph{Diagrama de clases Android: MobiAdsService.}}
 126     \label{fig:MobiAdsService}
 127 \end{figure}
 128
 129 En la Figura~\ref{fig:MobiAdsBatch}) como se hizo anteriormente para \textbf{MobiAdsService}, se representa el esquema interno de las clases que componen \textbf{MobiAdsBatch}. Es muy importante que esta clase funcione correctamente, pues sus procesos se ejecutarán de forma desatendida. Se observa que hace uso de la clase \textbf{AndroidHttpClient} que permitirá enviar y recibir información desde el servidor Web vía HTTP.
 130
 131 Para poder procesar varias acciones (actualización de coordenadas GPS) en paralelo, se hace uso del \textbf{ExecutorService} de Java que permite ejecutar tareas en paralelo mediante hilos. Los datos procesados son almacenados (si es necesario) en la base de datos SQLite. Haciendo uso para ello de la clase \textbf{IndexerProvider} que permite separar el modelo de datos del resto de la aplicación evitando tener que implementar sentencias SQL. Si en un futuro Android usara otro tipo de base de datos, esta abstracción hará que el cambio sea completamente transparente para el resto de la aplicación.
 132
 133 Por último en la Figura~\ref{fig:MobiAdsList}) se muestra el diagrama de clases de la \emph{Activity} \textbf{MobiAdsList}. Es importante resaltar que esta clase usa \emph{Fragments}\footnote{Android \emph{Fragments}, ver: \url{http://developer.android.com/guide/components/fragments.html}}, lo cual facilitará la utilización de esta \emph{Activity} (y por tanto de esta aplicación) en dispositivos con diferentes tamaños y resoluciones de pantalla (no solo \emph{Smartphones} si no también tabletas y portátiles con Android)
 134
 135 También en la Figura~\ref{fig:MobiAdsList}) se observa que la clase \textbf{AdsListLoader} extiende de \textbf{AsynckTaskLoader} que es una clase proporcionada por la API Android y que permite actualizar y alimentar la vista con datos procedentes del modelo (en nuestro caso datos procedentes de la base de datos SQLite) sin bloquear la vista (de forma asíncrona)
 136
 137 \begin{figure}[H]
 138     \centering
 139         \includegraphics[width=1\textwidth]{fig/MobiAdsBatch}
 140     \caption{\emph{Diagrama de clases Android: MobiAdsBatch.}}
 141     \label{fig:MobiAdsBatch}
 142 \end{figure}
 143
 144 \begin{figure}[H]
 145     \centering
 146         \includegraphics[width=1\textwidth]{fig/MobiAdsList}
 147     \caption{\emph{Diagrama de clases Android: MobiAdsList.}}
 148     \label{fig:MobiAdsList}
 149 \end{figure}
 150
 151
 152 \section{Diagrama de clases aplicación Web}
 153
 154 \begin{figure}[H]
 155     \centering
 156         \includegraphics[width=1\textwidth]{fig/MobiAdsWebClassCompany}
 157     \caption{\emph{Diagrama de clases Web Symfony: Company user.}}
 158     \label{fig:MobiAdsWebClassCompany}
 159 \end{figure}
 160
 161 \begin{figure}[H]
 162     \centering
 163         \includegraphics[width=1\textwidth]{fig/MobiAdsWebClassUser}
 164     \caption{\emph{Diagrama de clases Web Symfony: User.}}
 165     \label{fig:MobiAdsWebClassUser}
 166 \end{figure}
 167
 168 \section{Servicios Web, WSDL 2.0}
 169
 170 Los servicios web definen un mecanismo para la interacción entre máquinas usando la red y XML\footnote{\emph{Extensible Markup Language} o Lenguaje de Marcado Extensible, ver: \url{http://www.w3.org/XML/}}. Un componente clave de un servicio Web es una descripción formal con \emph{Web Services Description Language}, es decir, el Lenguaje de Descripción de Servicios Web o WSDL por sus siglas en Inglés. Hasta no hace muchos años (en concreto, hasta el año 2007) no existía un lenguaje formal para la descripción de \emph{REpresentational State Transfer (REST) Web services}. Pero desde la aparición del WSDL 2.0\footnote{\emph{WSDL 2.0}, ver: \url{http://www.w3.org/TR/wsdl20/}} sí es posible~\cite{C5:IBMREST}.
 171
 172 El término \emph{Web services} está típicamente asociado con operaciones o acciones basadas en servicios usando SAOP\footnote{\emph{Simple Object Access Protocol} o Protocolo Simple de Acceso a Objetos, ver: \url{http://www.w3.org/TR/soap/}} y los estándares WS*, tales como \emph{WS-Addressing} y \emph{WS-Security}. El término \emph{REST WEB services} generalmente se refiere a una arquitectura de servicios Web basada en recursos que usa HTTP y XML. Los estilos de arquitecturas SAOP y REST son usados ampliamente, pero tuvieron que pasar muchos años hasta que el estándar WSDL soportó de igual forma ambos. El \emph{binding}\footnote{\emph{Binding WSDL 2.0}, ver: \url{http://www.w3.org/TR/wsdl20/\#Binding}} del WSDL 1.1 HTTP era inadecuado para describir comunicaciones con HTTP Y XML, por tanto no había modo para formalmente describir servicios Web REST con WSDL. La publicación del WSDL 2.0, el cual fue diseñado con los servicios Web REST en mente, como una recomendación del \emph{World Wide Web Consortium} o W3C, significa que a partir de ese momento existe un lenguaje para describir servicios Web REST.
 173
 174 \subsection{REST}
 175
 176 \emph{REST} es un estilo de arquitectura que trata la Web como una aplicación centrada en recursos~\cite{C5:IBMREST}. De forma práctica, esto significa que cada URL en una aplicación RESTful representa un recurso. Las URLs son también fáciles de entender y recordar. Por ejemplo, una tienda de venta de libros puede definir la URL \nolinkurl{http://www.bookstore.com/books/} para una lista de libros que esa tienda vende y la URL \nolinkurl{http://www.bookstore.com/books/0321396/} para obtener detalles acerca de un libro determinado en función de su número ISBN. Esto es un claro contraste a las aplicaciones centradas en acciones, las cuales típicamente tienen largas y crípticas URLs describiendo acciones para realizar, tales como, \nolinkurl{http://www.bookstore.com/action/query?t=b\&id=111114532\&qp=0321396}. Los parámetros de la query son usados para filtrar los resultados.
 177
 178 El doctor Roy Fielding acuñó el término REST en su doctorado, donde él se refirió a el lenguaje HTTP y sus \emph{hyperlinks}\footnote{Sobre hyperlinks, ver: \url{http://en.wikipedia.org/wiki/Hyperlink}} como el motor de las aplicaciones basadas en estado. Esto significa que se espera que un recurso contenga \emph{hyperlinks}. Estos \emph{hyperlinks} son el método por el cual puede tomar lugar una transición que transfiere o cambia el estado de un recurso. Servicios Web REST hacen uso de \emph{hyperlinks}.
 179
 180 Aplicaciones Web tradicionales acceden a recursos usando operaciones HTTP GET o POST. En contraste, aplicaciones RESTful acceden a recursos siguiendo el estilo \emph{create}, \emph{read}, \emph{update} y \emph{delete} o CRUD por sus siglas en Inglés; y usan el rango completo de verbos HTTP (POST, GET, PUT y DELETE).
 181
 182 Hay otro componente clave relacionado con las aplicaciones REST: las aplicaciones RESTful no deberían tener estado. Esto significa que en una aplicación REST no se almacena el estado de la sesión en el servidor. Toda la información necesaria para satisfacer la petición es transportada en el mismo mensaje de petición.
 183
 184 \subsubsection{Retornando otros tipos de contenidos~\cite{C5:IBMREST}}
 185
 186 Los servicios Web generalmente devuelven datos como XML pero hay otros tipos de contenidos que son muy prácticos para los consumidores de servicios. Por ejemplo, en aplicaciones Ajax\footnote{\emph{Asynchronous JavaScript + XML}} suele ser preferible recibir datos del tipo JSON (\emph{JavaScript Object Notation}), por otro lado si el consumidor no es una máquina si no una persona que debe interpretar directamente los datos, probablemente quiera recibir estos datos como HTML, el cual puede ser fácilmente renderizado en el navegador Web. En el mundo HTTP, la selección del formato de los datos es conocida como \emph{content type negotiation}. En un \emph{content type negotiation}, el cliente especifica el tipo de contenido que prefiere y el que es aceptable, luego el servicio responde con el tipo de contenido más apropiado. Esto significa que un cliente puede pedir los datos desde un servicio Web como XML, y otro cliente puede pedir a ese mismo servicio Web los datos como JSON o algún otro tipo como puede ser YAML\footnote{Sobre YAML, ver: \url{http://www.yaml.org/}}.
 187
 188 Para dar a los clientes la capacidad para pedir un determinado tipo de contenido, se deben construir los servicios para que hagan uso de la cabecera HTTP \emph{Content-Type: text/html}. Una alternativa para aplicaciones que no entienden la cabecera \emph{Content-Type} es especificar un parámetro en la propia URL que represente el tipo de dato: xml, json, yaml, etc.
 189
 190 \subsection{WSDL y REST}
 191
 192 Una descripción WSDL contiene todos los detalles de un servicio Web, incluyendo:
 193
 194 \begin{itemize}
 195     \item La URL del servicio.
 196     \item El mecanismo de comunicación que el servicio entiende.
 197     \item Las operaciones que puede realizar.
 198     \item La estructura de sus mensajes.
 199 \end{itemize}
 200
 201 Los clientes pueden usar estos detalles para interactuar con un servicio.
 202
 203 El \emph{binding} en WSDL 1.1 era inadecuado para describir servicios Web REST. WSDL 2.0 fue declarado como una recomendación del W3C (\emph{World Wide Consortium}) en Junio del 2007. La segunda versión de WSDL fue precisamente creada para direccionar los problemas con WSDL 1.0, muchos de los cuales habían ya sido identificados por la organización WS-I (\emph{Web Services Interoperability}). Además WSDL 2.0 tiene buen soporte para generar HTTP bindings que son los que los servicios Web REST necesitan.
 204
 205 WSDL es un lenguaje XML para formalmente describir un servicio Web. Se puede considerar la descripción mediante WSDL de un servicio Web como el contrato entre este servicio Web y los clientes que deben usarlo. La descripción WSDL especifica la dirección, los mecanismos de comunicación permitidos, el interfaz y los tipos de mensajes de un servicio Web. En resumen, una descripción WSDL proporciona toda la información que un cliente necesita para usar un servicio Web.
 206
 207 La usabilidad de WSDL se extiende más allá de su uso como un contrato entre el cliente y el servicio alojado en un servidor. Siendo una definición formal, WSDL puede ser consumido por herramientas de servicios Web para realizar acciones, tales como:
 208
 209 \begin{itemize}
 210     \item Generar código de cliente en varios lenguajes.
 211     \item Publicar un servicio Web.
 212     \item Dinámicamente probar un servicio Web.
 213 \end{itemize}
 214
 215 \subsection{Describir un servicio Web REST con WSDL 2.0}
 216
 217 WSDL 2.0 es un lenguaje XML. El elemento raíz de un documento WSDL 2.0 es el elemento \emph{description}. Hay cuatro elementos hijo de tipo \emph{description} que juntos encapsulan todos los detalles sobre un servicio Web:
 218
 219 \begin{itemize}
 220     \item {\Large\emph{types}}
 221     \item {\Large\emph{interface}}
 222     \item {\Large\emph{binding}}
 223     \item {\Large\emph{service}}
 224 \end{itemize}
 225
 226 Un esqueleto de un documento WSDL 2.0 es mostrado en el Listado~\ref{list:WSDL20skeleton}):
 227
 228 \lstset{language=XML, basicstyle=\small, breaklines=true, frame=single, captionpos=b, caption={Esqueleto de un documento WSDL 2.0}, label={list:WSDL20skeleton}}
 229 \lstinputlisting{source/wsdl20skeleton.xml}
 230
 231 La estructura de un documento WSDL 2.0 difiere de la WSDL 1.1. Las diferencias más importantes se detallan a continuación:
 232
 233 \begin{itemize}
 234     \item El elemento raíz ha cambiado desde \emph{definitions} a \emph{description}.
 235     \item El elemento \emph{portType} ha sido reemplazado con el elemento \emph{interface} para reflejar mejor su uso.
 236     \item El elmento \emph{message} no existe como un elemento global. Las descripciones de los mensajes son ahora encapsuladas en el elemento \emph{interface}.
 237     \item En WSDL 2.0 un \emph{binding} se puede reutilizar. No necesita ahora ser asociado con un interfaz específico. La asociación puede ser realizada en la declaración del servicio.
 238 \end{itemize}
 239
 240 El elemento \emph{types} contiene todas las definiciones de tipos que describen los mensajes del servicio Web. WSDL 2.0 puede ser usado con otros sistemas de tipado, pero prácticamente es únicamente utilizado con el esquema XML.
 241
 242 El elemento \emph{interface} define las operaciones del servicio Web, incluyendo los mensajes input, output y fault (de fallo) que son pasados, y también el orden en el cual son enviados.
 243
 244 El elemento \emph{binding} define cómo un cliente puede comunicar con el servicio Web. En el caso de servicios Web REST, un binding especifica que los clientes pueden comunicarse con el servidor usando HTTP.
 245
 246 El elemento \emph{service} asocia una dirección para el servicio Web con un interfaz y binding específicos.
 247
 248 \subsection{Modelo WSDL 2.0 utilizado}
 249
 250 \subsubsection{Definir el formato de mensajes para las operaciones}
 251
 252 Como primer paso para desarrollar un servicio Web, se debe definir el formato de los mensajes XML de cada operación. Se necesita describir las estructuras específicas de los mensajes para que los clientes puedan saber qué mensaje enviar al servicio y qué mensaje esperar desde el servicio. En nuestro caso, el servicio Web\footnote{Por simplicidad se decidió un diseño con un solo servicio Web, si bien hubiera sido más adecuado crear dos servicios Web REST. El primer servicio usando las coordenadas GPS retornaría una lista con URLs a anuncios concretos (por ejemplo en función de su ID) donde a su vez un segundo servicio Web REST que estuviera escuchando retornaría los datos de cada uno de esos anuncios.} tendrá un único mensaje de salida (\emph{output}).
 253
 254 WSDL 2.0 soporta múltiples tipos de sistemas para la descripción del contenido de los mensajes, pero el esquema XML es el único que se usa. Para el caso particular de este proyecto, se debe crear el siguiente mensaje de salida:
 255
 256 \begin{itemize}
 257     \item \emph{adsList} representa el mensaje de salida. Contiene una secuencia de elementos ad. Cada elemento ad contiene los atributos: \emph{id}, \emph{text}, \emph{adname}, \emph{link} e \emph{image}. El \emph{id} es un identificador único del anuncio en el sistema, \emph{text} es un texto descriptivo con información sobre un anuncio, \emph{adname} es el nombre del anuncio, \emph{link} es una URL donde se puede encontrar más información sobre un anuncio y \emph{image} es una URL de donde se puede descargar la imagen asociada con un determinado anuncio.
 258 \end{itemize}
 259
 260 El esquema XML para el servicio se muestra en el Listado~\ref{list:XSDadsList}).
 261
 262 \begin{figure}[H]
 263 \lstset{language=XML, basicstyle=\small, breaklines=true, float=[P], floatplacement={P}, frame=single, captionpos=b, caption={Esquema XML para la lista de anuncios}, label={list:XSDadsList}}
 264 \lstinputlisting{source/adslist.xsd}
 265 \end{figure}
 266
 267
 268 \subsubsection{Fichero WSDL servicio AdsList}
 269
 270 Tras la definición del esquema, se puede crear el fichero WSDL que nos permite definir el servicio Web. En el Listado~\ref{list:WSDL20mobiads}) se muestra el fichero WSDL del servicio AdsList.
 271
 272 \lstset{language=XML, basicstyle=\small, breaklines=true, float=[P], floatplacement={P}, frame=single, captionpos=b, caption={WSDL servicios AdsList}, label={list:WSDL20mobiads}}
 273 \lstinputlisting{source/mobiads.wsdl}
 274
 275 Los elementos más importantes del archivo WSDL mostrado en el Listado~\ref{list:WSDL20mobiads}) se explican a continuación.
 276
 277 \subsubsection{Definición del servicio}
 278
 279 La URL para obtener la lista de anuncios en función de las coordenadas GPS es \nolinkurl{http://users.mobiads.gumartinm.name/api/latitude/longitude/gpsads.json}. Para direccionar el servicio, se usa el elemento \emph{service} del WSDL, el cual requiere al menos un elemento hijo \emph{endpoint}. El atributo \emph{address} del elemento \emph{endpoint} es usado para la especificar la URL del servicio como se muestra en el Listado~\ref{list:WSDL20service}) El elemento \emph{endpoint} se usa también para asociar un binding con el servicio mediante el atributo \emph{binding}. El elemento \emph{servicio} también asocia un interfaz con el servicio mediante el atributo \emph{interface}.
 280
 281 El documento WSDL 2.0 también requiere un espacio de nombres, por tanto también se define el \emph{targetNamespace} \nolinkurl{http://users.mobiads.gumartinm.name/adslist/wsdl}.
 282
 283 \lstset{language=XML, basicstyle=\small, breaklines=true, float=[P], floatplacement={P}, frame=single, captionpos=b, caption={WSDL, servicio AdsList}, label={list:WSDL20service}}
 284 \lstinputlisting{source/service.xml}
 285
 286 \subsubsection{Definición del binding del servicio}
 287
 288 La definición binding del servicio necesita especificar que el servicio comunica usando HTTP. Para hacer esto, se especifica el valor \nolinkurl{http://www.w3.org/ns/wsdl/http} para el atributo \emph{type} del elemento \emph{binding} del archivo WSDL.
 289
 290 El binding puede de forma opcional referenciar un interfaz y en ese caso el binding puede también opcionalmente declarar un elemento \emph{operation} que es idéntico al elemento \emph{operation} definido en el interfaz. Hay cuatro verbos en la comunicación HTTP: GET, PUT, POST, DELETE. El servicio ads list es una petición de lectura, por tanto, comunica con HTTP GET. La declaración del binding HTTP del servicio puede ser vista en el Listado~\ref{list:WSDL20binding})
 291
 292 \lstset{language=XML, basicstyle=\small, breaklines=true, float=[P], floatplacement={P}, frame=single, captionpos=b, caption={WSDL, binding para servicio AdsList}, label={list:WSDL20binding}}
 293 \lstinputlisting{source/binding.xml}
 294
 295 \subsubsection{Definición de la operación del servicio}
 296
 297 El elemento \emph{interface} y su hijo \emph{operation} son usados para definir las operaciones del servicio. En el caso de nuestro servicio, se define una única operación, \emph{getAdsbyGPS}. Después se especifican tres atributos en el elemento \emph{operation}:
 298
 299 \begin{itemize}
 300     \item \textbf{pattern:} Se usa para especificar el patrón de mensajes de intercambio (MEP por sus siglas en Inglés) para la operación. El MEP define la secuencia de mensajes en la operación y su dirección. En nuestro caso, se especifica el valor \nolinkurl{http://www.w3.org/ns/wsdl/in-out} para indicar que el servicio recibe un mensaje de entrada (en nuestro caso vacío) y envía un mensaje de salida (la lista con los anuncios).
 301     \item \textbf{wsdlx:safe}: Proviene de las extensiones al espacio de nombres WSDL, en concreto este atributo declara que la operación es idempotente. Este tipo de operación no modifica el recurso y por tanto puede ser llamada tantas veces como se quiera proporcionando siempre los mismos resultados.
 302 \end{itemize}
 303
 304 El Listado~\ref{list:WSDL20interface}) muestra el código relacionado con el elemento \emph{interface} del archivo WSDL.
 305
 306 \lstset{language=XML, basicstyle=\small, breaklines=true, float=[P], floatplacement={P}, frame=single, captionpos=b, caption={WSDL, interfaz para servicio AdsList}, label={list:WSDL20interface}}
 307 \lstinputlisting{source/interface.xml}