\section{Otros}
\subsection{Servicios Web y Mono}
\subsubsection{Introducción}
\begin{itemize}
\item Mono, al implementar .NET, provee también muchas de las herramientas de .NET para desarrollo y consumo de Servicios Web, que son una parte importante de .NET
\item No desarrolla algunos de los componentes de Microsoft (Web Services Enhancements, por ejemplo)
\item La mayoría de lo aquí tratado es 100\% compatible con .NET: la documentación de .NET nos sirve
\begin{itemize}
\item La documentación de la web del \href{http://www.msc.deusto.es}{DotNetGroup} y los libros de su \href{http://bibliodng.ordunya.com/}{biblioteca} son extraordinariamente útiles para esto
\item Es un ejemplo claro de reutilización de inversiones en documentación de Microsoft desde Mono
\end{itemize}
\end{itemize}
\newpage
\subsubsection{¿Qué son Servicios Web?}
\begin{itemize}
\item Según la \href{http://es.wikipedia.org/wiki/Servicios\_Web}{Wikipedia}:
~\\
~\\
\textit{Un servicio Web es una colección de protocolos y estándares que sirve para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes y ejecutadas sobre cualquier plataforma pueden utilizar los servicios web para intercambiar datos en redes de ordenadores como Internet. La interoperabilidad se consigue mediante la adopción de estándares abiertos.}
\item La idea es que yo (mi aplicación) ofrezco un servicio a través de Internet, y otros (otras aplicaciones en máquinas remotas) pueden consumirlo, de manera completamente independiente de la plataforma usada
\begin{itemize}
\item Puedo estar yo utilizando Java sobre Windows y alguien lo consume bajo GNU/Linux desde Python
\end{itemize}
\item Para ello, se utilizan tecnologías web estándares:
\begin{itemize}
\item La comunicación va a través de XML de una u otra manera (estándar)
\item Para el transporte, se utiliza HTTP, FTP, Jabber o algún otro protocolo estándar
\end{itemize}
\item Hay diferentes protocolos de Servicios Web:
\begin{itemize}
\item \href{http://www.w3.org/TR/soap/}{SOAP}
\item \href{http://www.xml-rpc.com}{XML-RPC}
\item \ldots
\end{itemize}
\item XML-RPC con Mono no se cubrirá, para más información \href{http://www.xml-rpc.net/}{una implementación Open Source XML-RPC para .NET/Mono}
\end{itemize}
\newpage
\subsubsection{REST con Mono}
\begin{itemize}
\item Yahoo! \href{http://developer.yahoo.net}{ofrece una API atractiva} para poder usar el buscador desde tus aplicaciones
\item Utiliza \href{http://en.wikipedia.org/wiki/REST}{REST}
\begin{itemize}
\item Utilizado también por:
\begin{itemize}
\item \href{http://www.amazon.com/gp/aws/landing.html}{Amazon}
\item \href{http://bloglines.com/services/}{Bloglines}
\item \href{http://developer.ebay.com/rest/}{eBay}
\item \ldots
\end{itemize}
\end{itemize}
\item Aunque REST no es exáctamente una forma de Servicios Web, podemos encontrar interfaces para desarrollo como las anteriores hechas en REST que utilizaremos de manera muy similar a Servicios Web
\item Para poder hacer llamadas desde Mono, es necesario implementar el código que haga la llamada y traduzca la respuesta.
\begin{itemize}
\item O utilizar el código que alguien ya ha implementado para C\#, como la implementación libre de \href{http://www.mgbrown.com/Downloads.aspx\#Yahoo}{Martin G Brown}
\end{itemize}
\item Yahoo nos permite hacer búsquedas
\begin{itemize}
\item de \href{http://developer.yahoo.net/search/web/V1/webSearch.html}{páginas web}
\item de \href{http://developer.yahoo.net/search/image/V1/imageSearch.html}{imágenes}
\item de \href{http://developer.yahoo.net/search/video/V1/videoSearch.html}{vídeos}
\item de \href{http://developer.yahoo.net/search/news/V1/newsSearch.html}{noticias}
\item de \href{http://developer.yahoo.net/search/}{mucho más}
\end{itemize}
\item Ejemplo de llamada (madonna imágenes, sólo un resultado, empezando por el segundo):
\begin{verbatim}
http://api.search.yahoo.com/ImageSearchService/V1/imageSearch?
appid=YahooDemo&query=e-ghost&results=1&start=2
\end{verbatim}
\item Ejemplo de resultado a la llamada anterior:
\begin{verbatim}
e ghost
Foto en Jaidefinision aqui
httpantilleshomelinuxnetfotofamilia01jpg Fila de
atras cyrus NcTrun Fermat Zefe Guillermo
Juanval STenyaK FMonkey BloOwITt txusinho
Zurt MaY Juro que soy yo aunque tengo la cara a
oscuras 8D
http://www.mundurat.net/nun/webmaster/img/e-ghost.jpg
http://www.mundurat.net/nun/webmaster/img/e-ghost.jpg
http://www.e-ghost.deusto.es/phpwiki/index.php/HuMor
415844
jpeg
413
764
http://re2.mm-b1.yimg.com/image/602490785
70
130
\end{verbatim}
\item Más información en la \href{http://developer.yahoo.net/search/}{documentación}
\item \emph{Ejemplo: otros/ws/rest/ejemplo/yahoo.cs}
\end{itemize}
\newpage
\subsubsection{Introducción a SOAP}
\begin{itemize}
\item SOAP (Simple Object Access Protocol) es el protocolo de Servicios Web más popular
\begin{itemize}
\item En principio, SOAP es sólo el protocolo para la serialización de objetos
\begin{itemize}
\item Con SOAP se puede serializar un objeto serializable en un fichero
\end{itemize}
\item Cuando se utiliza para hacer peticiones y procesar las respuestas, se está hablando de SOAP-RPC
\begin{itemize}
\item Para ello, utiliza un protocolo de transporte, a través del cual lanza la petición, y a través del cual recibe la respuesta
\end{itemize}
\end{itemize}
\item Soporta múltiples protocolos para la transporte, pero el más utilizado es HTTP
\begin{itemize}
\item Ejemplo de petición SOAP sobre HTTP tabulada:
\begin{verbatim}
POST /Ejemplo.asmx HTTP/1.1
User-Agent: Mono Web Services Client Protocol
1.1.4322.573
SOAPAction: "espacio/GetClasses"
Content-Type: text/xml; charset=utf-8
Content-Length: 276
Expect: 100-continue
Connection: keep-alive
Host: localhost:8080
\end{verbatim}
\item Ejemplo de respuesta SOAP sobre HTTP tabulada:
\begin{verbatim}
HTTP/1.0 200 OK
Server: Mono-XSP Server/1.0.9.0 Unix
X-Powered-By: Mono
Date: Mon, 8 Aug 2005 00:16:05 GMT
Content-Type: text/xml; charset=utf-8
Content-Length: 519
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Jon Ander
JonAn
Jon
Antilles
113
\end{verbatim}
\item De la misma forma, puede utilizarse sobre FTP, Jabber, SMTP, POP3, u otros protocolos de transporte
\end{itemize}
\item Para que el cliente del servicio pueda lanzar estas peticiones, debe saber qué métodos puede llamar, qué parámetros le puede pasar, y demás información. Para ello, necesita una Descripción del Servicio Web:
\begin{itemize}
\item Para ello, puede documentarlo de diferentes maneras
\item La más popular es utilizando \href{http://www.w3.org/TR/wsdl}{WSDL} (Web Service Description Language)
\begin{itemize}
\item Ejemplo de descripción: \href{http://api.google.com/GoogleSearch.wsdl}{la interfaz de desarrollo de Google}
\item WSDL no está atado a SOAP
\end{itemize}
\end{itemize}
\item La popular combinación SOAP (sobre HTTP) para el uso del Servicio Web, descrito mediante WSDL (y descubierto mediante UDDI, que no vamos a ver) hace posible la automatización de todo el proceso
\begin{itemize}
\item Por tanto pueden crearse herramientas para ello
\item Mono, cuenta por defecto con herramientas de muy alto compatibles con .NET nivel para trabajar con SOAP
\end{itemize}
\end{itemize}
\newpage
\subsubsection{Configurando el Servidor Web SOAP con Mono}
\begin{itemize}
\item Para ofrecer un Servicio Web, lo primero que necesitaremos será un Servidor que esté a la escucha
\begin{itemize}
\item Podemos hacer que nuestra aplicación esté a la escucha
\item Podemos utilizar el servidor propio de Mono, el \texttt{xsp}
\item Podemos utilizar el módulo para Apache de Mono (\href{http://www.mono-project.com/Mod\_mono}{mod\_mono})
\end{itemize}
\item Nosotros utilizaremos el Servidor propio de Mono, el xsp
\begin{itemize}
\item Más fácil de configurar e instalar
\item Por otra parte, necesitamos tener otro puerto a la escucha
\begin{itemize}
\item Sin embargo, al transportar toda la comunicación por HTTP, podemos utilizar el módulo proxy de Apache:
\item Poniendo las siguientes líneas en el fichero de configuración de Apache (httpd.conf):
\begin{verbatim}
ProxyRequests Off
ProxyPass /src http://localhost:puerto/dst/
ProxyPassReverse /src http://localhost:puerto/dst/
\end{verbatim}
\item Y descomentando el módulo Proxy en el fichero de configuración de módulos de Apache(modules.conf):
\begin{verbatim}
LoadModule proxy_module
/usr/lib/apache/1.3/libproxy.so
\end{verbatim}
\item Y con ello al acceder a localhost/src, Apache hará de proxy, transmitiendo la información a localhost:puerto/dst, y devolviendo la respuesta
\end{itemize}
\end{itemize}
\item Lo ideal es que \texttt{xsp} sea ejecutado por el usuario \texttt{www-data} (u otro nuevo, por ejemplo \texttt{xsp})
\begin{itemize}
\item Dado que en el cursillo hemos utilizado la instalación genérica y que sólo estamos haciendo pruebas, por comodidad lo ejecutaremos con el usuario con el que hemos iniciado la sesión
\item Al instalar Mono a través de repositorios, lo normal es que venga por defecto ejecutándose como \texttt{www-data}
\end{itemize}
\item Para indicarle una carpeta desde la que cuelgue todo, haciendo que todas las aplicaciones compartan su mismo directorio \texttt{bin}, lo haremos con:
\begin{verbatim}
xsp --root carpeta
\end{verbatim}
\item Es más común indicarle un directorio de configuración que indique todo:
\begin{verbatim}
xsp --appconfigdir /etc/xsp
\end{verbatim}
\item Esto permite poder diferenciar entre varias aplicaciones, en diferentes directorios
\begin{itemize}
\item \emph{Ejemplo: otros/ws/soap/xsp}. Contiene un ejemplo de \texttt{appconfigdir}
\end{itemize}
\item Para poder utilizar los ejemplos del cursillo:
\begin{verbatim}
xsp --root otros/ws/soap/sirviendo
\end{verbatim}
\item Para poder utilizar los ejemplos que vienen con el instalador genérico (vienen también en el paquete \texttt{asp.net-examples})
\begin{verbatim}
nctrun@ord3p:~/mono-1.1.8.2/share/doc/xsp$ xsp --root test
\end{verbatim}
\item Para poder utilizar ASP.NET 2:
\begin{verbatim}
nctrun@ord3p:~/mono-1.1.8.2/share/doc/xsp$ xsp2 --root test
\end{verbatim}
\item Para terminar, pulsar intro. Si está instalado mediante repositorios:
\begin{verbatim}
nctrun@ord3p:~# /etc/init.d/mono-xsp stop
\end{verbatim}
\begin{center}
\includegraphics{figuras/xsp2.png}
\end{center}
\end{itemize}
\newpage
\subsubsection{Sirviendo un Servicio Web SOAP con Mono}
\begin{itemize}
\item Para hacer un ejemplo sencillo de Servicio Web SOAP con Mono:
\begin{itemize}
\item Crearemos un fichero \texttt{.asmx}
\item En él aparecerá la cabecera:
\begin{verbatim}
<%@ WebService Language="c#" Class="espacios.nombres.clase" %>
\end{verbatim}
\begin{itemize}
\item El \texttt{Language} será C\# o VB.NET
\item La \texttt{Class} será la clase que tiene los métodos a los que se podrá llamar
\item Existen otras muchas posibles cabeceras para añadir
\end{itemize}
\item Después de la cabecera, pondremos el código. Estará:
\begin{itemize}
\item la clase especificada en la cabecera
\begin{itemize}
\item Opcionalmente, será hija de \texttt{System.Web.Services.Service} y así podrá acceder a métodos y atributos útiles de la clase padre
\item Opcionalmente, tendrá el atributo (con más o menos parámetros):
\begin{verbatim}
[WebService(Description="este servicio mola",
Namespace="espacio")]
\end{verbatim}
\item Los métodos que podrán ser accesibles tendrán que tener el atributo (con más o menos parámetros):
\begin{verbatim}
[WebMethod(Description="esta es la descripcion")]
\end{verbatim}
\end{itemize}
\item Más clases o tipos de dato que se usen en el código
\begin{itemize}
\item Si se van a usar en la comunicación (pueden ser pasados por parámetro o devueltos), deberán tener el atributo:
\verb+[Serializable]+
\end{itemize}
\end{itemize}
\end{itemize}
\item \emph{Ejemplo: otros/ws/soap/sirviendo/Ejemplo.asmx}
\begin{itemize}
\item Para poder ver el servicio, accederemos a:
\subitem \href{http://localhost:8080/Ejemplo.asmx}{http://localhost:8080/Ejemplo.asmx}
\item La primera vez que accedemos, el código es compilado.
\item Veremos una página web
\begin{itemize}
\item Desde la cual podremos ver la documentación del servicio web
\item Ver los métodos que podemos invocar, e incluso invocarlos
\begin{itemize}
\item Con una petición GET, por lo que no podremos pasar datos complejos
\item Llamamos a:
\subitem \href{http://localhost:8080/Ejemplo.asmx?page=op&tab=test&op=GetClasses&bnd=PetitionsServerSoap&ext=testform}{http://localhost:8080/Ejemplo.asmx?page=op\&tab=test\\\&op=GetClasses\&bnd=PetitionsServerSoap\&ext=testform}
\item Que realmente se limita a poner bonito el resultado de:
\begin{verbatim}
http://localhost:8080/Ejemplo.asmx/GetClasses
\end{verbatim}
\end{itemize}
\item Ver la descripción del Servicio Web (que nos generará automáticamente) en WSDL:
\subitem \href{http://localhost:8080/Ejemplo.asmx?page=wsdl}{http://localhost:8080/Ejemplo.asmx?page=wsdl}
\begin{itemize}
\item Que realmente se limita a poner bonito el resultado de:
\subitem \href{http://localhost:8080/Ejemplo.asmx?wsdl}{http://localhost:8080/Ejemplo.asmx?wsdl}
\end{itemize}
\item E incluso nos genera código para consumir el servicio web en C\# y en VB.NET:
\subitem \href{http://localhost:8080/Ejemplo.asmx?page=proxy}{http://localhost:8080/Ejemplo.asmx?page=proxy}
\end{itemize}
\end{itemize}
\item También podemos no poner todo el código en el \texttt{.asmx}, utilizando \texttt{.dll}s externos
\item O incluso utilizar \texttt{Code Behind}, de manera que incluimos todo el código en un \texttt{.cs}, lo compilamos, ponemos el \texttt{.dll} en el directorio \texttt{bin} de la aplicación, y en el \texttt{.asmx} no necesitamos poner por tanto el código
\begin{itemize}
\item \emph{Ejemplo: otros/ws/soap/sirviendo/Ejemplo.code.behind.asmx}
\end{itemize}
\end{itemize}
\newpage
\subsubsection{Consumiendo un Servicio Web SOAP con Mono}
\begin{itemize}
\item Lo primero que haremos es encontrar la descripción del Servicio Web
\item Tomaremos como servidor nuestra máquina alojando el servicio de ejemplo anterior
\item Por tanto, encontraremos la descripción generada por \texttt{xsp} en:
\subitem \href{http://localhost:8080/Ejemplo.asmx?WSDL}{http://localhost:8080/Ejemplo.asmx?WSDL}
\begin{itemize}
\item Si echamos un ojo a esta descripción, veremos que están definidos los datos de las clases que habíamos escrito en C\# (Classroom, Student\ldots), así como las operaciones que hemos permitido acceder
\item Con ello, ya podríamos hacer código que realizase esas peticiones
\end{itemize}
\item Utilizaremos la herramienta \texttt{wsdl} para generar un esqueleto en C\# ya hecho a través de la descripción dada:
\begin{verbatim}
nctrun@ord3p:~$ wsdl http://localhost:8080/Ejemplo.asmx?wsdl
Mono Web Services Description Language Utility
Writing file 'PetitionsServer.cs'
nctrun@ord3p:~$
\end{verbatim}
\begin{itemize}
\item \texttt{wsdl} tiene más opciones, para generar VB.NET, poner usuario y password, para generar un esqueleto de servidor en lugar de uno de cliente\ldots
\begin{verbatim}
man wsdl
\end{verbatim}
\end{itemize}
\item Una vez hecho esto, podemos compilar este código como librería:
\begin{verbatim}
nctrun@ord3p:~$ mcs PetitionsServer.cs -t:library
-r:System.Web.Services
nctrun@ord3p:~$
\end{verbatim}
\item Y luego desde otro \texttt{.cs} podemos hacer llamadas de manera transparente:
\begin{verbatim}
PetitionsServer ps = new PetitionsServer();
Classroom [] crs = ps.GetClasses();
foreach(Classroom cr in crs)
System.Console.WriteLine(cr.Number);
\end{verbatim}
\begin{itemize}
\item Cuando llamamos a \texttt{GetClasses} por ejemplo, internamente hará la llamada al servidor y se quedará esperando a la respuesta
\begin{itemize}
\item Para verlo:
\begin{verbatim}
nctrun@ord3p:~# tcpflow -i lo -C port 8080
\end{verbatim}
\end{itemize}
\item Además de generarnos los métodos a los que podemos llamar (como \texttt{GetClasses}), nos genera otros para utilizarlos de manera asíncrona:
\begin{verbatim}
public IAsyncResult BeginGetClasses (AsyncCallback
callback, object asyncState);
public void EndAddClass (IAsyncResult asyncResult);
\end{verbatim}
\item Además, podemos ver los métodos etc. a alto nivel con \texttt{monop} como comentábamos a principio del cursillo:
\begin{verbatim}
nctrun@ord3p:~$ monop -r:PetitionsServer.dll
Assembly Information:
PetitionsServer
Version=0.0.0.0
Culture=neutral
Classroom
PetitionsServer
Student
Total: 3 types.
nctrun@ord3p:~$ monop -r:PetitionsServer.dll Classroom
public class Classroom {
public Classroom ();
(...)
public Student[] Students;
public int Number;
}
nctrun@ord3p:~$
\end{verbatim}
\end{itemize}
\item \emph{Ejemplo: otros/ws/soap/consumiendo/}
\item Sin embargo, si estamos utilizando Mono para escuchar a Mono\ldots \textit{¿dónde está la interoperabilidad?}
\item Vamos a hacer el mismo ejemplo, con el mismo servidor, de manera breve con la librería \href{http://ws.apache.org/axis/}{Axis} de \href{http://www.apache.org}{Apache} para Java
\subitem Damos por hecho que \texttt{\$AXISCLASSPATH} son los \texttt{.jar} que vienen con Axis
\item Dada la descripción, generamos el código, pero esta vez en Java:
\begin{verbatim}
nctrun@ord3p:~$ java -cp $AXISCLASSPATH
org.apache.axis.wsdl.WSDL2Java
http://localhost:8080/Ejemplo.asmx?wsdl
nctrun@ord3p:~$ javac -cp $AXISCLASSPATH espacio/*java
nctrun@ord3p:~$
\end{verbatim}
\item Una vez hecho esto, hacemos un código de prueba como:
\begin{verbatim}
PetitionsServerLocator psl = new PetitionsServerLocator();
PetitionsServerSoap pss = psl.getPetitionsServerSoap();
ArrayOfClassroom aoc = pss.getClasses();
Classroom [] crs = aoc.getClassroom();
for(Classroom cr : crs)
System.out.println(cr.getNumber());
\end{verbatim}
\item Y lo compilamos:
\begin{verbatim}
nctrun@ord3p:~$ javac Llamada.java -cp $AXISCLASSPATH:.
\end{verbatim}
\item Y lo ejecutamos:
\begin{verbatim}
nctrun@ord3p:~$ java -cp $AXISCLASSPATH:. Llamada
113
nctrun@ord3p:~$
\end{verbatim}
\item Si miramos otra vez lo que va por debajo con \texttt{tcpflow} veremos que no hay grandes cambios (aparte del User-Agent\ldots)
\item De la misma forma podríamos utilizar muchísimos otros lenguajes (\href{http://ws.apache.org/axis/}{C++}, \href{http://pywebsvcs.sourceforge.net/}{Python}, \href{http://soaplite.com/}{Perl}, \ldots) bajo diferentes Sistemas Operativos
\end{itemize}
\subsection{Remoting}
\begin{itemize}
\item Los Servicios Web anteponen la interoperabilidad entre diferentes plataformas a largo alcance a la eficiencia
\begin{itemize}
\item Interesante para
\begin{itemize}
\item ofrecer o consumir un servicio a través de Internet
\item interactuar entre diferentes plataformas
\end{itemize}
\item Pero si nuestra aplicación no cumple ninguna de las dos condiciones, puede interesarnos otro sistema que
\begin{itemize}
\item nos permita trabajar al mismo nivel de abstracción (o superior)
\item cuide más la eficiencia
\end{itemize}
\end{itemize}
\item Con Remoting tenemos precisamente esto:
\begin{itemize}
\item Mismo nivel de abstracción
\begin{itemize}
\item incluso superior ofreciendo
\begin{itemize}
\item eventos
\item paso de parámetros por referencia
\item \ldots
\end{itemize}
\end{itemize}
\item Comunicación por canales
\begin{itemize}
\item Encargados de transmitir la información
\item \texttt{HttpChannel}
\begin{itemize}
\item Utilizará HTTP para la transmisión de información
\end{itemize}
\item \texttt{TcpChannel}
\begin{itemize}
\item Utilizará un formato binario para la transmisión de información
\item Mayor eficiencia
\end{itemize}
\item \href{http://www.monohispano.org/tutoriales/remoting-canal/}{más (incluso implementando los propios)}
\end{itemize}
\item Formateadores
\begin{itemize}
\item Encargados de serializar la información a transmitir
\item \texttt{SoapClientFormatterSinkProvider} / \\ \texttt{SoapServerFormatterSinkProvider}
\begin{itemize}
\item Serializa la información a SOAP
\item El utilizado por defecto con HttpChannel
\end{itemize}
\item \texttt{BinaryClientFormatterSinkProvider} / \\ \texttt{BinaryServerFormatterSinkProvider}
\begin{itemize}
\item Serializa la información a un formato binario
\item El utilizado por defecto con TcpChannel
\end{itemize}
\item Más, incluso implementando los propios
\end{itemize}
\item Puede resultar mejor para comunicar aplicaciones en una red en la que sólo vayamos a tener equipos con Mono/.NET funcionando
\end{itemize}
\item \emph{Ejemplos en otros/remoting/}
\end{itemize}
\newpage
\subsection{Bases de Datos}
\begin{itemize}
\item Para utilizar Bases de Datos en Mono, utilizaremos la implementación de Mono de ADO.NET
\item Mono tiene soporte para \href{http://www.mono-project.com/Database_Access}{muchos proveedores}
\item Utilizaremos como ejemplo dos diferentes:
\begin{itemize}
\item \texttt{Sqlite}, minimalista
\begin{itemize}
\item Multiplataforma y Open Source
\item No tiene ningún demonio por detrás: se almacena todo en un fichero
\item Realmente pequeña, no tiene dependencias
\item Viene por defecto con Mono
\item Utilizada en aplicaciones de escritorio, como f-spot
\end{itemize}
\item \texttt{MySQL}, potente
\begin{itemize}
\item Multiplataforma y Open Source
\item La M de \texttt{LAMP} (Linux Apache MySQL (PHP | Python | Perl)
\item Hay que utilizar el \href{http://dev.mysql.com/doc/refman/5.0/en/connector-net.html}{conector de MySQL para .NET} (viene con binarios para Mono)
\item Soporte para transacciones, replicación, diferentes opciones de almacenamiento\ldots
\end{itemize}
\end{itemize}
\item \emph{Ejemplo en otros/bd/}
\end{itemize}