Arquitectura Orientada a Servicios (primera aproximación)

Transcripción

1 Escola Universitària Politècnica de Mataró Laboratori d Informàtica 3 Arquitectura Orientada a Servicios (primera aproximación)

2 Ante todo comentar que este manual, como otros que os he escrito, no trata de explicar en profundidad todos los aspectos de cada uno de los apartados, si no solo aquello que considero necesarios y mínimos para entender y desarrollar la práctica. Contenido Arquitectura Orientada a Servicios... 3 Diseño y desarrollo de SOA... 3 Beneficios... 4 WebServices... 5 Estándares empleados... 5 Ventajas de los servicios web... 6 Inconvenientes de los servicios Web... 6 Razones para crear servicios Web... 7 Mashup (aplicación web híbrida)... 8 El Concepto... 9 Tipos de Mashups... 9 Light-Webservices Qué beneficios obtenemos del uso de WebServices en nuestra aplicación? Qué queremos hacer? Cómo lo vamos a hacer? Serialización de Objetos en XML XStream... 14

3 Arquitectura Orientada a Servicios La Arquitectura Orientada a Servicios (en inglés Service Oriented Architecture), es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio. Permite la creación de sistemas altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma bien definida de exposición e invocación de servicios (comúnmente pero no exclusivamente servicios web), lo cual facilita la interacción entre diferentes sistemas propios o de terceros. SOA define las siguientes capas de software: Aplicaciones básicas - Sistemas desarrollados bajo cualquier arquitectura o tecnología, geográficamente dispersos y bajo cualquier figura de propiedad; De exposición de funcionalidades - Donde las funcionalidades de la capa aplicativas son expuestas en forma de servicios (servicios web); De integración de servicios - Facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos empresariales internos o en colaboración; De composición de procesos - Que define el proceso en términos del negocio y sus necesidades, y que varía en función del negocio; De entrega - donde los servicios son desplegados a los usuarios finales. SOA proporciona una metodología y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de integración y consolidación. Diseño y desarrollo de SOA La metodología de modelado y diseño para aplicaciones SOA se conoce como análisis y diseño orientado a servicios. La arquitectura orientada a servicios es tanto un marco de trabajo para el desarrollo de software como un marco de trabajo de implementación. Para que un proyecto SOA tenga éxito los desarrolladores de software deben orientarse ellos mismos a esta mentalidad de crear servicios comunes que son orquestados por clientes o middleware para implementar los procesos de negocio. El desarrollo de sistemas usando SOA requiere un compromiso con este modelo en términos de planificación, herramientas e infraestructura.

4 Cuando la mayoría de la gente habla de una arquitectura orientada a servicios están hablando de un juego de servicios residentes en Internet o en una intranet, usando servicios web. Existen diversos estándares relacionados a los servicios web. Incluyen los siguientes: XML HTTP SOAP WSDL UDDI Hay que considerar, sin embargo, que un sistema SOA no necesariamente necesita utilizar estos estándares para ser "orientado a servicios" pero es altamente recomendable su uso. En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a otros participantes en la red como servicios independientes a los que tienen acceso de un modo estandarizado. La mayoría de las definiciones de SOA identifican la utilización de Servicios Web (empleando SOAP y WSDL) en su implementación, no obstante se puede implementar SOA utilizando cualquier tecnología basada en servicios. Beneficios Los beneficios que puede obtener una organización que adopte SOA son: Mejora en los tiempos de realización de cambios en procesos. Facilidad para evolucionar a modelos de negocios basados en tercerización. Facilidad para abordar modelos de negocios basados en colaboración con otros entes (socios, proveedores). Poder para reemplazar elementos de la capa aplicativa SOA sin disrupción en el proceso de negocio Facilidad para la integración de tecnologías disímiles Más referencias en:

5 WebServices Un servicio web (en inglés, Web service) es un conjunto de protocolos y estándares que sirven 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. Las organizaciones OASIS y W3C son los comités responsables de la arquitectura y reglamentación de los servicios Web. Para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se ha creado el organismo WS-I, encargado de desarrollar diversos perfiles para definir de manera más exhaustiva estos estándares. Estándares empleados Web Services Protocol Stack: Así se denomina al conjunto de servicios y protocolos de los servicios Web. XML (Extensible Markup Language): Es el formato estándar para los datos que se vayan a intercambiar. SOAP (Simple Object Access Protocol) o XML-RPC (XML Remote Procedure Call): Protocolos sobre los que se establece el intercambio. Otros protocolos: los datos en XML también pueden enviarse de una aplicación a otra mediante protocolos normales como HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol), o SMTP (Simple Mail Transfer Protocol). WSDL (Web Services Description Language): Es el lenguaje de la interfaz pública para los servicios Web. Es una descripción basada en XML de los requisitos funcionales necesarios para establecer una comunicación con los servicios Web. UDDI (Universal Description, Discovery and Integration): Protocolo para publicar la información de los servicios Web. Permite comprobar qué servicios web están disponibles.

6 WS-Security (Web Service Security): Protocolo de seguridad aceptado como estándar por OASIS (Organization for the Advancement of Structured Information Standards). Garantiza la autenticación de los actores y la confidencialidad de los mensajes enviados. Web services architecture. Ventajas de los servicios web Aportan interoperabilidad entre aplicaciones de software independientemente de sus propiedades o de las plataformas sobre las que se instalen. Los servicios Web fomentan los estándares y protocolos basados en texto, que hacen más fácil acceder a su contenido y entender su funcionamiento. Al apoyarse en HTTP, los servicios Web pueden aprovecharse de los sistemas de seguridad firewall sin necesidad de cambiar las reglas de filtrado. Permiten que servicios y software de diferentes compañías ubicadas en diferentes lugares geográficos puedan ser combinados fácilmente para proveer servicios integrados. Permiten la interoperabilidad entre plataformas de distintos fabricantes por medio de protocolos estándar y abiertos. Las especificaciones son gestionadas por una organización abierta, la W3C, por tanto no hay secretismos por intereses particulares de fabricantes concretos y se garantiza la plena interoperabilidad entre aplicaciones. Inconvenientes de los servicios Web

7 Para realizar transacciones no pueden compararse en su grado de desarrollo con los estándares abiertos de computación distribuida como CORBA (Common Object Request Broker Architecture). Su rendimiento es bajo si se compara con otros modelos de computación distribuida, tales como RMI (Remote Method Invocation), CORBA o DCOM (Distributed Component Object Model). Es uno de los inconvenientes derivados de adoptar un formato basado en texto. Y es que entre los objetivos de XML no se encuentra la concisión ni la eficacia de procesamiento. Al apoyarse en HTTP, pueden esquivar medidas de seguridad basadas en firewall cuyas reglas tratan de bloquear o auditar la comunicación entre programas a ambos lados de la barrera. Razones para crear servicios Web La principal razón para usar servicios Web es que se basan en HTTP sobre TCP (Transmission Control Protocol) en el puerto 80. Dado que las organizaciones protegen sus redes mediante firewalls -que filtran y bloquean gran parte del tráfico de Internet-, cierran casi todos los puertos TCP salvo el 80, que es, precisamente, el que usan los navegadores. Los servicios Web utilizan este puerto, por la simple razón de que no resultan bloqueados. Otra razón es que, antes de que existiera SOAP, no había buenas interfaces para acceder a las funcionalidades de otros ordenadores en red. Las que había eran ad hoc y poco conocidas, tales como EDI (Electronic Data Interchange), RPC (Remote Procedure Call), u otras APIs. Una tercera razón por la que los servicios Web son muy prácticos es que pueden aportar gran independencia entre la aplicación que usa el servicio Web y el propio servicio. De esta forma, los cambios a lo largo del tiempo en uno no deben afectar al otro. Esta flexibilidad será cada vez más importante, dado que la tendencia a construir grandes aplicaciones a partir de componentes distribuidos más pequeños es cada día más utilizada. Se espera que para los próximos años mejoren la calidad y cantidad de servicios ofrecidos basados en los nuevos estándares. Más referencias en:

8 Existen plataformas que permiten la configuración, administración y visualización de los servicios web existentes, bus de servicios, etc. pero en nuestro caso, como NO vamos a implementar todos los estándares que requiere un webservice completo ( SOAP, WSDL,UDDI,etc..), utilizaremos directamente un servidor de aplicaciones normal como el que ya tenéis funcionando (Apache). La implementación básica de los webservices es conocida también como Light- WebServices. Mashup (aplicación web híbrida) Una aplicación web híbrida (mashup o remezcla) es un sitio web o aplicación web que usa contenido de otras aplicaciones Web para crear un nuevo contenido completo, consumiendo servicios directamente, siempre a través de protocolo http. El contenido de un mashup normalmente proviene de sitios web de terceros a través de una interfaz pública o usando un API. Otros métodos que constituyen el origen de sus datos incluyen sindicadores web (RSS o Atom), Screen scraping, etc. Los mashups están revolucionando el desarrollo web del mismo modo que los weblogs han revolucionado la publicación en línea. Los mashups permiten que cualquiera combine, de forma innovadora, datos que existen en diferentes páginas web. Requieren pocos conocimientos técnicos, las APIs existentes son sencillas y potentes y los mashups son relativamente fáciles de diseñar. Los creadores de mashups son generalmente gente innovadora que desea combinar de formas nuevas y creativas datos disponibles públicamente. Así como hay mashups muy útiles, existen otros que no pasan de ser sólo novedosos o publicitarios, con mínima utilidad práctica. Los defensores e impulsores de las aplicaciones Web 2.0 afirman que los mashups son un ejemplo de este nuevo movimiento en el que los usuarios crean, participan e interactúan activamente.

9 El Concepto El contenido usado en mashups es típicamente obtenido de otra fuente vía una interface pública o API (web services), aunque existe gente en la comunidad que considera que los casos en que las interfaces son privadas no deberían contar como mashups. Otros métodos de obtener contenido para mashups incluyen Web Feeds (i.e RSS o Atom) y screen scraping. Mucha gente experimenta con mashups usando las APIs de Amazon, ebay, Flickr, Google, Microsoft, Yahoo o YouTube lo que ha llevado a la creación de un editor mashup. La arquitectura de los mashups está siempre compuesta de tres partes: El proveedor de contenidos: fuente de los datos. Los datos están disponibles vía una API y diferentes protocolos web como RSS, REST y Web Service. El sitio mashup: es la nueva aplicación web que provee un nuevo servicio utilizando diferente información y de la que no es dueña. El web browser cliente: es la interface de usuario del mashup. En una aplicación web, el contenido puede ser mezclado por los web browser clientes usando lenguaje web del lado del cliente. Por ejemplo javascript. Los mashups deben ser diferenciados de simples embebidos de datos de otro sitio para formar un documento compuesto. Un sitio que permite al usuario embeber vídeos de youtube, por ejemplo, no es un sitio mashup. Como ya se dijo, el sitio mismo debe acceder información externa a él usando una API y procesar esos datos de modo de incrementar su valor para el usuario. Marsh-up tambien se llama en Música cuando un tema de una canción es cantada por otra persona o otro tiempo...una versión distinta. Tipos de Mashups Los mashups se presentan actualmente en tres formas: mashups de consumidores, mashups de datos y mashups empresariales. El tipo más conocido es el de mashup de consumidores, que está muy bien ejemplificado por muchas aplicaciones que utilizan Google Maps. Los mashups de este tipo combinan datos de fuentes varias, escondiendo ello tras una interface gráfica simple.

10 Un mashup de datos mezcla datos de tipo similar proveniente de diferentes fuentes (ver Yahoo Pipes, Por ejemplo, combinando los datos de múltiples feeds RSS en un solo feed con nuevo un front-end gráfico. Un mashup empresarial (ejemplo, JackBe, integra usualmente datos de fuentes externas e internas. Por ejemplo, podría crear un reporte sobre la cuota de mercado de un negocio combinando la lista externa de todas las casas vendidas la semana anterior con datos internos de las casas vendidas por una sola agencia. Un mashup de negocio es una combinación de todo lo anterior, enfocando en agregación de datos y presentación y agregando adicionalmente una funcionalidad colaborativa, haciendo que el resultado final sea una aplicación de negocio apropiada. Mashups dentro de mashups son conocidos como mashups monstruos. Es importante reconocer que los mashups ayudan o facilitan la integración de aplicaciones orientadas a arquitecturas SOA. Podréis encontrar todos los Mashups del mundo mundial en: Light-Webservices Los Light-WebServices, no son más que una representación básica de los servicios web basados en la idea de uso solo del estándar de XML para intercambiar datos entre capas de aplicativo o aplicaciones. Idea para el más freekie (no evaluable): implementar una clase que permita mediante Java Invoke-Reflection la generación de objetos e instancias de clases javas NO conocidas por la aplicación receptora de la respuesta del webservice. El concepto de uso de los light-webservices para trabajar con RCP s es la misma de los mainframes o aplicaciones cliente-servidor (con cliente ligero), solo que ahora la parte de

11 comunicaciones pasa a ser un canal estandarizado de XML, en vez de un socket con un protocolo propietario de conexión. Qué beneficios obtenemos del uso de WebServices en nuestra aplicación? Por un lado tendremos realmente desligado nuestro sistema de los requisitos funcionales ligados estrictamente a la GUI, lo que asegurará que no sufriremos ante las nuevas peticiones de implementación o cambios en el front-end por las peticiones del cliente (cosa que pasa siempre). Por otro lado tendremos una aplicación que podrá convivir con otras aplicaciones, pudiendo incluso conectar e intercambiar datos con otras aplicaciones desarrolladas en otros lenguajes (aunque depende de cómo, debería de existir una correspondencia de clases entre una aplicación y otra). Qué queremos hacer? En nuestro caso queremos desacoplar la parte de front-end de nuestra aplicación, permitiendo que cualquier tipo de aplicativo trabaje con nuestro sistema. Esto lo lograremos generando nuestra API de acceso al sistema mediante webservices(light), que permitirá que cualquier aplicativo se conecte a nuestro sistema e interaccione con el de forma completamente desacoplada. Cómo lo vamos a hacer? Incorporando un método de acceso, en nuestro caso mediante HTTP. Para ello usaremos Struts 1.2 por tal de no introducir nueva materia de estudio, aunque quien quiera puede utilizar Spring, WebWork u otro sistema que permita desarrollar acceso web.

12 Doy por hecho que en el caso de Struts, todos ya sabéis como funciona y como se configura, por tanto solo os comentaré que necesitáis implementar al menos un controlador de acceso con los comandos y parámetros que necesitéis para las consultas. Un ejemplo de una consulta respecto a un cliente concreto por DNI ( comando=clientbyid & parameter=<id> ) nos debería de retornar el objeto Client correspondiente en formato XML ( Más adelante explico cómo generar este XML de forma fácil para cada objeto de datos ). Para hacer este trabajo de retorno del objeto deberemos de modificar la cabecera (HEADER) del JSP correspondiente al resultado, indicando que la respuesta es de tipo XML, aunque esto, realmente podría llegarse a obviar dependiendo de cómo implementemos la lectura del que se encargue de recibir el resultado. Una vez modificada esa cabezera, simplemente tendremos que escribir en el ServletOutputStream correspondiente de la salida del JSP. ServletOutputStream out = response.getoutputstream(); out.write(<variable_serializada_xml>); out.close(); Una vez tengamos los primeros resultados, que podemos hacerlos mediante peticiones de una página JSP ; En el mismo Servlet o en otro (eso nos da igual ahora), mediante GET o POST, eso también me trae sin cuidado simplemente controladlo bien. Posteriormente deberéis de implementar una aplicación de consulta básica en donde aparezcan algunos botones y un JTextArea en donde aparezca el resultado de la respuesta de la petición efectuada por los botones. Ej: getallclients Para acometer las peticiones desde nuestra aplicación cliente al servidor, deberéis de usar el package java.net para proceder a realizar una consulta a la URL correspondiente con los parámetros correctos.

13 Ejemplo de cómo leer una respuesta: URL url = new URL(" // Read all the text returned by the server BufferedReader in = new BufferedReader(new InputStreamReader(url.openStream())); String str; while ((str = in.readline())!= null) { // str is one line of text; readline() strips the newline character(s) } in.close(); Si queremos enviar datos en nuestra consulta desde el RCP, necesitaremos generar un post correspondiente, a continuación os enmarco un ejemplo de envío de POST y recepción de resultado. // Construct data String data = URLEncoder.encode("key1", "UTF-8") + "=" + URLEncoder.encode("value1", "UTF-8"); data += "&" + URLEncoder.encode("key2", "UTF-8") + "=" + URLEncoder.encode("value2", "UTF-8"); // Send data URL url = new URL(" URLConnection conn = url.openconnection(); conn.setdooutput(true); OutputStreamWriter wr = new OutputStreamWriter(conn.getOutputStream()); wr.write(data); wr.flush(); // Get the response BufferedReader rd = new BufferedReader(new InputStreamReader(conn.getInputStream())); String line; while ((line = rd.readline())!= null) { // Process line... } wr.close(); rd.close();

14 Realmente un SOA establece que el protocolo tanto de petición como de recepción se enmarquen en un modelo pre-definido de mensajería (tal como define por ejemplo SOAP), en nuestro caso nos hemos saltado este requisito, pero para los más intrépidos, se podría establecer estos canales de comunicación entre el RCP y la Aplicación de Servicios mediante el uso estricto de XMLs y no mediante peticiones de GET/POST del tipo formulario. En este caso no os voy a dar más pistas y el grupo(s) que lo logre(n) se merecerá(n) mi admiración y en el caso de ser una solución limpia, la nota más alta en la evaluación de su práctica el día 21 de Enero. Serialización de Objetos en XML Para la serialización de los objetos java podéis utilizar o bien el XMLBeans, XML(Encoder/Decoder), JAXB (Java API for XML Binding) o con XStream. Existen otros sistemas de serialización, pero los más (re)conocidos hasta ahora son estos cuatro. Finalmente para simplificaros la vida he seleccionado el XStream, ya que el que tiene una curva de aprendizaje más corta y no tiene las limitaciones del XML(Encoder/Decoder) (solo serializa en XML, las clases y atributos serializables especificados por los beans de java). XStream XStream is designed to be fast, places no constraints on the objects being serialized, is easy to use, produces very concise XML and requires no mapping configuration. Specific features: Ease of use. A high level facade is supplied that simplifies common use cases. No mappings required. Custom objects can be serialized without need for specifying mappings. Performance. Speed and low memory footprint are a crucial part of the design, making it

15 suitable for large object graphs or systems with high message throughput. Clean XML. No information is duplicated that can be obtained via reflection. This results in XML that is easier to read for humans and more compact than native Java serialization. Requires no modifications to objects. Serializes internal fields, including private and final. Supports non-public and inner classes. Classes are not required to have default constructor. Full object graph support. Duplicate references encountered in the object-model will be maintained. Supports circular references. Integrates with other XML APIs. By implementing an interface, XStream can serialize directly to/from any tree structure (not just XML). Customizable conversion stategies. Strategies can be registered allowing customization of how particular types are represented as XML. Error messages. When an exception occurs due to malformed XML, detailed diagnostics are provided to help isolate and fix the problem. Descargaros la libraría de : Incorporar todas las dependencias necesarias (xpp3_min-1.1.4c.jar) A continuación veréis lo fácil que es operar con esta librería para serializar los objetos que tengáis. Inicializar el objeto de serialización: XStream xstream = new XStream(); Para Serializar: String xml = xstream.toxml(new Client()); Para deserializar: Client theclient = (Client)xstream.fromXML(xml); En donde xml es la variable que contiene el contenido recibido.

16 Ya veis lo fácil que resulta utilizar este método de transmisión de objetos por la red, claro está que esto tiene un coste de bandwith que debemos tener en cuenta. Si, hay trabajo que hacer, pero.. No diréis que no os lo he dejado mascadito? ;-)