Servicios Web y Arquitectura 4+1 Vistas M.C. Juan Carlos Olivares Rojas

Arquitectura 4+1 Vistas En esta arquitectura de desarrollo de software un producto a ser desarrollado tiene 4 puntos de vistas dependiendo del tipo de personal involucrado en el proyecto. Las 4 vistas se concentran en el desarrollo de escenarios que describen el análisis y los requerimientos del sistema.

Arquitectura 4+1 Vistas Arquitectos Desarrolladores Vista Lógica Vista de Desarrollo Escenarios Analistas Del Negocio Vista del Proceso Vista Física Integradores Ingenieros de Infraestructura

Vista Lógica Se maneja el estilo arquitectónico de la aplicación: Orientado a objeto Basado en Componentes Basado en servicios La implementación de esta vista utiliza generalmente patrones arquitectónicos como el MVC (Modelo-Vista-Controlador)

Modelo MVC

Vista de Desarrollo Define los módulos de software ha ser construidos. Se deben definir con claridad las interfaces de E/S de los módulos. La modularización de componentes depende del estilo arquitectónico seleccionado en la vista lógica

Vista Física Mapea los componentes de software con el hardware (fase de despliegue) Un buen diseño promueve la flexibilidad de mapear componentes de software con diferentes confiuraciones físicas dentro de las diferentes fases del ciclo de vida del software. La vista de proceso está relacionada en la forma de darle seguimiento, control y dirección a las etapas del desarrollo del producto.

Escenarios Son abstracciones de los requerimientos más importantes. Están estrechamente relacionados con el uso de casos de uso La vista del escenario es redundante entre las otras vistas.

La nueva arquitectura 4+1 SOA Estructural Empaquetado/Implementación Clases y Componentes que representan el servicio Interfaz del Servicio Requerimientos, Pruebas/ Criterios de Validación Contratos de Servicios Comportamiento Infraestructura/ Entorno Flujos de trabajo que muestran la forma de trabajo de una unidad organizativa guiada por procesos de negocios Despliegue en .NET o J2EE considerando aspectos como la seguridad y el rendimiento

Modelo de servicios Web Clientes ricos Browsers estándar Dispositivos móviles Otros servicios XML Servicios Web Entre los otros servicios destacan: sistemas corporativos OLTP, ERP, CRM, Base de datos, etc. Formularios Web Lógica aplicación Servicios SO

Servicios Web Los servicios Web van de la mano de las tecnologías XML. XML nos sirve para estandarizar el marshalling de los datos. Utilizar la Web nos permite tener un puerto no bloqueando por Firewall

Servicios Web Son la invocación de código remoto utilizando protocolos estandarizados. En conclusión, realizan la misma función que los sockets, RPC, RMI, Corba y demás tecnologías distribuidas. Se puede ver a los servicios Web como una analogía de un procedimiento almacenado en una base de datos.

¿Qué son los Servicios Web? "A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards."

Definición de SW La aplicación que actúa como cliente debe conocer: La URL del servidor remoto que ofrece el servicio, El nombre del servicio que se solicita, y Los parámetros que se deben enviar junto con la llamada al servicio. Estos datos se enviarán mediante HTTP

Definición de SW El servidor que ofrece el servicio web leerá los parámetros que se le han enviado, llamará a un componente o programa encargado de implementar el servicio, y los resultados que se obtengan de su ejecución serán devueltos al servidor que solicitó la ejecución del servicio.

Servicios Web Un servicio Web no es un XML RPC como tal, se diferencia en la forma en que trabajan. Los servicios Web forman la base de la arquitectura orientada a servicios (SOA) Los servicio Web utilizan generalmente el método POST de HTTP para enviar los datos de la invocación del servicio.

SOA (Arquitectura Orientada a Servicios) Proveedor de Servicios Servicio Conectar Publicar Solicitante de Servicio Registro de Servicios Encontrar Descripción Cliente

Arquitectura de Servicios Web Publicación del Servicio 1 Proveedor del Servicio WSDL Directorio de Servicios 4 3 Definición del Servicio Invocación y respuesta UDDI SOAP Consumidor el Servicio Descubrimiento del Servicio 2

Servicios Web Los datos viajan envueltos en un protocolo llamado SOAP (Simple Object Access Protcol) que hace el marshalling de los datos. Una de las principales características que tienen los servicios Web radica en su ubicuidad, ya que pueden ser accedidos desde cualquier sitio, utilizando inclusive cualquier otro protocolo de transporte SMTP, FTP, etc.

SOAP Indica cómo se deben codificar los mensajes que circularán entre las dos aplicaciones. SOAP define dos modelos de mensajes: Un mensaje de solicitud. Un mensaje de respuesta. Fue definido inicialmente por Microsoft, Userland Software y DevelopMentor, a día de hoy se trata de una especificación mantenida por el W3C que cuenta con el apoyo de otros fabricantes como IBM, HP, Oracle, etc. Un mensaje que se enviará desde la aplicación cliente a la aplicación servidor, solicitando la ejecución de un método al que se pasan una serie de parámetros. Un mensaje que se enviará desde la aplicación servidor a la cliente, y que contendrá datos XML con los resultados de la ejecución del método solicitado.

Mensaje de solicitud <?xml version="1.0" encoding="UTF-8" ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Header> </SOAP-ENV:Header> <SOAP-ENV:Body> <catalogo:buscaIsbn xmlns:catalogo="http://catalogo.org/cat"> <catalogo:isbn> 84-4553-3334-2X </catalogo:isbn> </catalogo:buscaIsbn> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Mensaje de respuesta <?xml version="1.0" encoding="UTF-8" ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Header> </SOAP-ENV:Header> <SOAP-ENV:Body> <catalogo:buscaIsbnResponse xmlns:catalogo="http://catalogo.org/cat"> <catalogo:titulo> Catalogar materiales especiales </catalogo:titulo> <catalogo:autor>Marta de Juanes</catalogo:autor> </catalogo:buscaIsbnResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Servicios Web Los servicios Web necesitan ser descritos (saber que parámetros reciben, devuelven) para poderlos utilizar en diversos clientes. Esta descripción se realiza a través de WSDL (Web Service Definition Language). Generalmente esas descripciones los clientes las conocen o bien, puede descubrirlas haciendo uso de UDDI (Universal Description, Discovery and Integration).

Servicios Web La UDDI no es otra cosa que un repositorio en donde se almacenan servicios Web que pueden ser invocados por diversos clientes. Muchas empresas ofrecen servicios Web como amazon, google, http://www.xmethods.com

¿Por qué utilizar Servicios Web? Múltiples tecnologías para hacer lo mismo: No interoperables entre sí. Ligados a una plataforma. Tecnologías anteriores distribuidas: Sockets (conectores) RPC (Remote Procedure Call): Llamada a procedimiento remoto DCOM CORBA Java RMI Protocolo RPC IIOP IIOP or JRMP Formato del mensaje NDR CDR Java Ser. Format Descripción IDL OMG IDL Java Descubrimiento Windows Registry Naming Service RMI Registry or JNDI

Pila de protocolos de SW Redefinición de toda la pila de comunicaciones Basado en tecnologías estándares Servicio web Protocolo HTTP Formato del mensaje SOAP Descripción WSDL Descubrimiento UDDI

Ventajas de los Servicios Web Basados en estándares. Fácil integración. Desarrollo de actividades modularizadas. Independencia de plataforma. Puede ser usado tanto en clientes ligeros como pesados (clientes heterogéneos). Los sistemas y las bases de datos contienen datos en formatos incompatibles. Una de las tareas que mas consumen tiempo a los desarrolladores ha sido intercambiar datos entre tales sistemas sobre el Internet. Convertir los datos a XML puede reducir esta complejidad y crear datos que pueden leerse por diversos tipos de aplicaciones.

Desventajas de los Servicios Web Es que no son seguros... Es que no tienen estado... Es que no son transaccionales... “Los servicios Web no hacen más que reinventar la rueda, pero esta vez usando XML”. “No aportan nada nuevo que no tuvieramos ya en CORBA” Es que son ineficientes en cuanto a prestaciones (no puedo hacer computación científica distribuida!) Es que no puedo aplicarles fácilmente “aspectos” (login, ...)

Protocolos Servicios Web Publicar, buscar servicios: UDDI Descripción de servicios: WSDL Interacción de servicios: SOAP Formato de datos universal: XML Comunicaciones ubicuas: Internet

Creando Servicios Web Los servicios Web XML se exponen en el Framework .NET como archivos con una extensión .asmx. Los servicios se pueden consumir a través de páginas Web, clientes ligeros en una PC o clientes inteligentes en dispositivos móviles.

Hola mundo!!! <%@ WebService Language="C#“ class="Helloweb" %> using System.Web.Services; [WebService (Namespace="http://sybex.com/webservices")] public class Helloweb: WebService{ [WebMethod] public string HelloWebService() { return "Holla Mundo!"; }

Otro servicio Web <%@ WebService Language="C#" class="Fibonacci" %> using System.Web.Services; public class Fibonacci : WebService{ [WebMethod] public int GetSeqNumber(int fibIndex){ if (fibIndex < 2) return fibIndex; int[] FibArray = {0,1}; for (int i = 1; i< fibIndex; i++){ FibArray[1] = FibArray[0] + FibArray[1]; FibArray[0] = FibArray[1] - FibArray[0]; } return FibArray[1];

Cliente del servicio using System; class ClienteFecha { public static void Main() ServicioFecha s = new ServicioFecha(); Console.WriteLine(“Fecha actual: {0}”, s.Fecha(false)); Console.WriteLine(“Fecha actual detallada: {0}”, s.Fecha(true)); }

Cliente de servicio Web Windows C# .NET

Agregar referencia Web

Cliente de servicio Web en una Pocket PC

Página Web del Servicio HelloWorld

Respuesta del servicio Web par

Página Web del Servicio 1

WSDL del servicio Web 1

Ejecución del servicio Web suma

Ejecución del servicio Web par

Crear proxy del servicio Web

Servicios Web Ejemplo de archivo WSDL de amazon <operation name=“AuthorSearchRequest”/> <input message=“typens:AuthorSearchRequest”/> <output message=“typens:AuthorSearchResponse”> </operation> ….

Servicios Web Los tipos de datos se definen en otra parte <xsd:complexType name=“AuthorRequest”> <xsd:all> <xsd:element name=“autor” type=“xsd:string”/> <xsd:element name=“sort” type=“xsd:string” minOccurs=“0”/> </xsd:all> </xsd:complexType>

Servicios Web Cuando se traduce a Java queda: public class AuthorRequest { public AuthorRequest(String author, String page, String mode, String tag, String sort, String locale, String word, String price) {…} public String getAuthor() {…} public String getPage() {…} …. }

Servicios Web Para ejecutar el servicio se utiliza: AmazonSearchPort puerto = (AmazonSearchPort) (new AmazonSearchService_Impl().getAmazonSearchPort()); AuthorRequest solicitud = new AuthorRequest(name, “1”, books, “”, “lite”, “”, token, “”, “”, “”); ProductInfo res= puerto.autorSearchRequest(solicitud);

Servicios Web Se ocupa en las versiones viejas el JWSDP (Java Web Service Developer Pack) Se necesita un archivo config.xml <?xml version=“1.0” encoding=“UTF-8”?> <configuration xmlns=http://java.sun.com/xml/ns/jax-rpc/ri/config>

Servicios Web <wsdl location=“http://soap.amazon.com/schemas3/AmazonWebServices.wsdl” packageName=“com.amazon” /> </configuration> wscompile –import config.xml wscompile –gen –keep config.xml

Tarea Próximo Jueves: Presentación sobre diferencias entre arquitecturas WOA, Clound Computing y Software as a Service. Repaso de metodologías ágiles.

¿Preguntas?