La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Clase 11 Introducción a los Servicios Web

Presentaciones similares


Presentación del tema: "Clase 11 Introducción a los Servicios Web"— Transcripción de la presentación:

1 Clase 11 Introducción a los Servicios Web
ACI – 843 JAVA II Clase 11 Introducción a los Servicios Web

2 Comunicación entre sistemas heterogéneos
El sistema del departamento de Compras está en Windows/Visual Basic y requiere información del departamento de Contabilidad que utiliza HP-UX/Oracle. El nuevo departamento de Web requiere acceso tanto al de Contabilidad y Compras para desplegar información de clientes pero éste ya se encuentra en el flexible y portable lenguaje Java. Las incongruencias se hacen evidentes: desde privilegios de acceso (seguridad), representación de datos, transacciones y otra gran gama de posibilidades. Esta comunicación entre sistemas heterogéneos presenta el siguiente problema: ¿Cómo interactuamos?

3 La solución por excelencia: CORBA, complicado y costoso
La manera en que muchas empresas aíslan sus sistemas de este tipo de problemas es mediante la arquitectura común para solicitud de objetos ("Common Object Request Broker Architecture" CORBA), donde se logra una interoperabilidad de sistemas, sin embargo, esta interoperabilidad tiene su costo. Entrar en los detalles específicos de un diseño CORBA sería excesivo. Basta decir que antes de programar en "x" lenguaje, debe ser llevado a un diseño en un lenguaje para definición de interfaces ("Interface Definition Language“ - IDL), lo que es de por si solo una ardua labor. Posteriormente debe realizarse el diseño (vía el IDL) en el lenguaje especifico, instalar un software llamado ORB ("Object Request Broker") que aísla a los diversos sistemas y finalmente coordinar toda esta instalación. Obviamente lo anterior requiere no solo trabajo extenso, sino un conocimiento exhausto acerca de las implicaciones que trae a un sistema CORBA: Seguridad, Transacciones, y otras consideraciones. En el mundo de XMLRPC/SOAP todo esto se simplifica.

4 ¿Qué es un Servicio Web? Un servicio Web (Web service) es una colección 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.

5 What Are Web Services? Web services are a result of the natural evolution of the Web. There are numerous definitions given for Web services, ranging from the highly technical ones to simplistic. For example, the World Wide Web Consortium (W3C) organization, which establishes the standards for Web services, defines them as follows: “A Web service is a software system identified by a URI whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML-based messages conveyed by Internet protocols.” A simpler definition, and perhaps more useful, might be: “a Web service is a software application, accessible on the Web (or an enterprise’s intranet) through a URL, that is accessed by clients using XML-based protocols, such as Simple Object Access Protocol (SOAP) sent over accepted Internet protocols, such as HTTP. Clients access a Web service application through its interfaces and bindings, which are defined using XML artifacts, such as a Web Services Definition Language (WSDL) file.”

6 Typical Web Service Scenarios
Interoperability requirements for the enterprise application in a heterogeneous enterprise environment. Integration requirements for those whose environments contain various Enterprise Information Systems (EISs). Types of clients expected to be supported, such as J2EE applications, wireless devices, PDAs, and so forth. Availability of tools to implement the solution. Level of sacrifice, in terms of complexity and performance, that can be tolerated to achieve the advantages (interoperability, diverse client reach, and so forth) of Web services.

7 Ejemplo de escenario

8 Estándares empleados Web Services Protocol Stack: Así se denomina al conjunto de servicios y protocolos de los servicios Web. XML: Es el formato estándar para los datos que se vayan a intercambiar. SOAP o XML-RPC: 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, FTP, o SMTP. WSDL: 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: Protocolo para publicar la información de los servicios Web. Permite a las aplicaciones comprobar qué servicios Web están disponibles. WS-Security: Protocolo de seguridad aceptado como estándar por OASIS. Garantiza la autenticación de los actores y la confidencialidad de los mensajes enviados.

9 Ventajas 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.

10 Desventajas Para realizar transacciones no pueden compararse en su grado de desarrollo con los estándares abiertos de computación distribuida como CORBA. Su rendimiento es bajo si se compara con otros modelos de computación distribuida, tales como RMI, CORBA, o DCOM. Es uno de los inconvenientes derivados de adoptar un formato basado en texto. Y es que entre los objetivos de XML no se encuentran ni 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 en ambos lados de la barrera. Existe poca información de servicios Web para algunos lenguajes de programación.

11 Motivaciones para crear Servicios Web
La principal razón para usar servicios Web es que se basan en HTTP sobre TCP 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 se vehiculan por 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 existents eran ad hoc y poco conocidas, tales como EDI, RPC, 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 acusada.

12 Service-oriented Architecture
In a service-oriented architecture, you have the following: A service that implements the business logic and exposes this business logic through well-defined interfaces. A registry where the service publishes its interfaces to enable clients to discover the service. Clients (including clients that may be services themselves) who discover the service using the registries and access the service directly through the exposed interfaces. Vista por capas de un Servicio Web

13 To enable this architecture
A mechanism that enables clients to access a service and registry. A mechanism to enable different services to register their existence with a registry and a way for clients to look up the registry of available services. Web services are based on an architecture in which the service can be located over the network and its location is transparent, which means that clients may dynamically discover a particular service they wish to use. A mechanism for services to expose well-defined interfaces and a way for clients to access those interfaces.

14 Diseño de un Servicio Web
En general, un servicio Web: Expone una interfaz que sus clientes usan para realizar peticiones al servicio. Publica los detalles del servicio disponible a los asociados y a clientes interesados. Recibe solicitudes de los clientes Delega las peticiones recibidas a la lógica de negocios apropiada y procesa dichas solicitudes. Formula y envía una respuesta a la petición.

15 Flujo de un Web Service en JAVA

16 Plataformas Servidores de aplicaciones para servicios Web:
Axis y el servidor Jakarta Tomcat (de Apache) ColdFusion MX de Macromedia Java Web Services Development Pack (JWSDP) de Sun Microsystems (basado en Jakarta Tomcat) JOnAS (parte de ObjectWeb una iniciativa de código abierto) Microsoft .NET Novell exteNd (basado en la plataforma J2EE) WebLogic WebSphere Zope es un servidor de aplicaciones Web orientado a objetos desarrollado en el lenguaje de programación Python VERASTREAM de AttachmateWRQ para modernizar o integrar aplicaciones host IBM y VT Mono

17 Surgimiento de XMLRPC y SOAP
El surgimiento de XMLRPC/SOAP tiene sus raíces en la manera que son invocados procedimientos remotos en diversos sistemas de computo, por ende, es conveniente describir este proceso. Diversos Sistemas Operativos y Lenguajes Conocemos que la gran mayoría de las corporaciones van conformando su sistema de información a través de las necesidades que surgen en distintas áreas de operación, lo que trae aparejada una disparidad en áreas que varían desde lenguajes, protocolos de comunicación, sistemas operativos, bases de datos y otros elementos. Esta discrepancia no seria tan crítica si los diversos sistemas pudieran permanecer aislados. Sin embargo, la realidad es otra.

18 XML-RPC Protocolo de llamada a procedimiento remoto que usa XML para codificar las llamadas y HTTP como mecanismo de transporte. Es un protocolo muy simple ya que sólo define unos cuantos tipos de datos y comandos útiles, además de una descripción completa de corta extensión. La simplicidad del XML-RPC está en contraste con la mayoría de protocolos RPC que tienen una documentación extensa y requieren considerable soporte de software para su uso. Fue creado por la empresa UserLand Software en asociación con Microsoft en el año Al considerar Microsoft que era muy simple y adicionar funcionalidades y después de varias etapas de desarrollo el estándar dejó de ser sencillo y se convirtió en lo que es actualmente se conoce como SOAP.

19 Arquitectura de XMLRPC
En XMLRPC siempre se habla en términos de cliente/servidor, existe un sistema que realiza la solicitud ("el cliente") y otro que la atiende ("el servidor"), y como es de imaginarse un elemento clave en ambos puntos es el parser XML.

20 Implementaciones de XMLRPC
Aunque es posible diseñar desde cero cualquier tipo de cliente y/o servidor para emplear XML, hoy en día ya existen diversas implementaciones para diversos ambientes y lenguajes. Es a través de estas implementaciones que se logran ahorrar diversas labores como configuraciones de parser, cuestiones de seguridad, integración a servidores de paginas y otros detalles secundarios. Utilizando estas estructuras ("Frameworks"), el desarrollo se concentra en los procedimientos específicos y no en detalles comunes o secundarios que siempre son utilizados en XMLRPC. Algunas implementaciones: XMLRPC Apache para Java XMLRPC-PHP para PHP XMLRPC-ASP para COM/Vbasic XMLRPC-C para C y C++

21 SOAP El protocolo de acceso simple a objetos (Simple Object Access Protocol - SOAP) es un protocolo estándar creado por Microsoft, IBM y otros, está actualmente bajo el auspicio de la W3C que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. SOAP es uno de los protocolos utilizados en los servicios Web. SOAP usa el código fuente en XML. Esto es una ventaja ya que facilita su lectura por parte de humanos, pero también es un inconveniente dado que los mensajes resultantes son más largos. El intercambio de mensajes se realiza mediante tecnología de componentes (ver ingeniería de software). El término Object en el nombre significa que se adhiere al paradigma de la Programación Orientada a Objetos.

22 Arquitectura de SOAP SOAP esta diseñado para realizar intercambios de información en XML en sistemas altamente distribuidos, específicamente Internet. Uno de los conceptos integrados a SOAP que no existe en XMLRPC es el uso de un lenguaje neutro, descendiente de XML, para describir las funciones/métodos residentes en "el servidor ". Esto tiene una ventaja muy evidente: Al utilizar el lenguaje neutro WSDL para describir las funcionalidades de "el servidor", éste funciona como un contrato al que se deben apegar los distintos "clientes ". Lo anterior facilita que puedan ser escritos "clientes" en diversos lenguajes a partir de este contrato.

23 Tecnología de SOAP SOAP es un marco extensible y descentralizado que permite trabajar sobre múltiples pilas de protocolos de redes informáticas. Los procedimientos de llamadas remotas pueden ser modelados en la forma de varios mensajes SOAP interactuando entre sí. SOAP funciona sobre cualquier protocolo de Internet, generalmente HTTP, que es el único homologado por el W3C. SOAP tiene como base XML, con un diseño que cumple el patrón Cabecera-Desarrollo de diseño de software, como otros muchos diseños, verbigracia HTML. La cabecera (Header) es opcional y contiene metadatos sobre enrutamiento (routing), seguridad o transacciones. El desarrollo (Body) contiene la información principal, que se conoce como carga útil (payload). La carga útil se acoge a un XML Schema propio. Estructura del mensaje

24 Implementaciones de SOAP
Al igual que XMLRPC, hoy en día ya existen diversas herramientas para desarrollar aplicaciones SOAP que incluyen generadores de WSDL para distintos lenguajes, servidores UDDI y otros paquetes más. Algunas de estas herramientas son: Web services Pack de Sun para Java Toolkit IBM web services para Java WASP para C++ y Java Toolkit Microsoft SOAP para COM/VBasic/.Net

25 Modo de trabajo A partir de WSDL se describen las funcionalidades del Web service. En XMLRPC es necesario conocer de antemano que funciones/métodos residen en "el servidor" y no solo esto, sino que además se requiere conocer el lenguaje en el que esta escrito "el servidor“ A través de WSDL se logra aislar el lenguaje especifico del Web service. Además del uso de WSDL, a SOAP se le ha incorporado UDDI, cuyo principio radica en el intercambio comercial entre empresas denominado "E-Business". A través de UDDI se logra concentrar y publicar Web services en un directorio centralizado. Además de UDDI existen otros mecanismos para concentrar y publicar Web services tales como ebXML y WSIL.

26 Web Services Description Language - WSDL
El Lenguaje para Descripción de Servicios Web es un formato XML que se utiliza para describir servicios Web, cuya versión 1.1 está en estado de "propuesta de recomendación" por parte del W3C. WSDL describe la interfaz pública a los servicios Web. Está basado en XML y describe la forma de comunicación, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios para interactuar con los servicios listados en su catálogo. Las operaciones y mensajes que soporta se describen en abstracto y se ligan después al protocolo concreto de red y al formato del mensaje.

27 Uso y Generación de WSDL
El diseño de Clientes en SOAP generalmente es llevado acabo a partir de un archivo escrito en WSDL. Mediante una definición de este tipo es posible distribuir los detalles del Web service en un lenguaje neutro, lo cual permite que la definición (Cliente) sea implementada en distintos lenguajes y ambientes tales como: C++, Perl o VBasic/.NET. WSDL también se encuentra basado en el lenguaje XML y es generado a partir de diversas herramientas proporcionadas en distintos ambientes SOAP. El siguiente enlace describe como generar un archivo WSDL a través de herramientas proporcionadas con Axis: Generación de WSDL ("Web Services Description Language")

28 UDDI y ebXML Generado un archivo WSDL para nuestro Web service, podrá ser accedido desde diversas plataformas y lenguajes. Existe otro eslabón crítico para desarrollos SOAP: "Universal Description, Discovery and Integration Directory" (UDDI) o "Electronic Business XML Working Group " (ebXML).

29 Universal Description, Discovery, and Integration - UDDi
UDDI son las siglas del catálogo de negocios de Internet denominado Universal Description, Discovery, and Integration. El registro en el catálogo se hace en XML. UDDI es una iniciativa industrial abierta (sufragada por la OASIS) entroncada en el contexto de los servicios Web. El registro de un negocio en UDDI tiene tres partes: Páginas blancas - dirección, contacto y otros identificadores conocidos; Páginas amarillas - categorización industrial basada en taxonomías; y Páginas verdes - información técnica sobre los servicios que aportan las propias empresas. UDDI es uno de los estándares básicos de los servicios Web cuyo objetivo es ser accedido por los mensajes SOAP y dar paso a documentos WSDL, en los que se describen los requisitos del protocolo y los formatos del mensaje solicitado para interactuar con los servicios Web del catálogo de registros.

30 UDDI Surgió con la intención de centralizar servicios Web comunes, así como ofrecer un deposito central donde se puede acudir a realizar búsquedas de servicios Web específicos, las metodologías que han sido descritas anteriormente solamente permiten que el servicio Web sea descubierto siempre y cuando nos sea proporcionado el archivo WSDL. Ha sido desarrollado por un grupo de empresas entre las que figuran principalmente Microsoft, IBM y SAP, estas compañías así como algunos otros consorcios se encargan de mantener y ofrecer este tipo de servicios en Internet, algunos directorios de prueba que puede utilizar son los siguientes: UDDI IBM UDDI Microsoft UDDI SAP UDDI habilita descripción dinámica, descubrimiento e integración de Web services.

31 UDDI (2) De esta manera si usted posee varios Web services tales como:
ofrecer estado de tiempo, cotizaciones sobre sus productos comerciales, procesamiento de transacciones financieras, etc., es posible publicarlos a un directorio UDDI, permitiendo que sean descubiertos en un directorio conocido y centralizado. Este mecanismo facilita el intercambio comercial por un medio electrónico, algo que resulta difícil utilizando XMLRPC, ya que no existe una metodología para descubrir servicios en una red como Internet. Desde luego un desarrollo con SOAP es sumamente más complejo que con XMLRPC, debido principalmente a que se debe interactuar con tecnologías adicionales como WSDL y UDDI, pero a su vez ofrece mayor flexibilidad y potencial a escala futura.

32 Puede consultar mayores detalles: http://www.ebxml.org
ebXML ebXML es otro tipo de registro para servicios Web que surgió previo a UDDI y que es desarrollado por la organización para el progreso de estándares sobre información estructurada ("Organization for the Advancement of Structured Information Standards“ – OASIS) así como por la división de las Naciones Unidas para simplificar procedimientos y prácticas en Admnistración, Comercio y Transporte CEFACT ("United Nations Centre for the Facilitation of Procedures and Practices in Administration, Commerce and Transport"). Puede consultar mayores detalles: Para accesar un directorio UDDI o ebXML generalmente se utiliza un Navegador ("Netscape" o "Explorer") para dar de alta los respectivos Web services por lo que su uso es relativamente sencillo. Sin embargo, aunque la forma clásica de acceder Directorios para Web services sea un Navegador, existen otros mecanismos como JAXM ("Java API for XML Registries") que permiten acceder este tipo de directorios de una manera programática.

33 Web Service Inspection Language - WSIL
WSIL es una especificación muy reciente iniciada por IBM y Microsoft que ofrece un mecanismo complementario a UDDI y ebXML para encontrar Web services en una red como Internet. A diferencia de UDDI donde se realizan búsquedas en un directorio centralizado, mediante WSIL se inspecciona un "Web-Server" conocido, realizando una búsqueda por Web services. Es mediante archivos escritos en WSIL que se logra su descubrimiento. Es una especificación muy reciente. Sus implementaciones son mínimas, puede consultar mayores detalles de WSIL en: Especificación WSIL 1.0

34 Razones para WSIL Existen dos razones principales por las que surgió WSIL: Falta de Moderación: Debido a la misma escalabilidad con la que fue diseñado UDDI, existe una clara falta por moderar los Web services que son publicados en este tipo de Directorios. Lo anterior trae consigo la publicación de "Web Services Description Language" inválidos, la duplicidad de WSDL e inclusive la publicación de Web services no disponibles. Falta de Calidad de Servicio (QoS): Este punto aunque relacionado con el anterior se refiere a la garantía del servicio ofrecido por el proveedor del Web service, esto es: debido a que UDDI es un directorio público en Internet, ¿quién garantiza que el Web service utilizado o comprado cumpla con determinados requerimientos? Esto nos lleva al antiguo concepto de negocios: Comprar o adquirir a quien ya conocemos, y es precisamente en este principio en el que esta basado WSIL.

35 Conclusiones Mediante XMLRPC/SOAP se logra que el intercambio de información sea realizado en XML. Aquí se esta tomando el primer paso en sencillez: la representación de datos no posee ningún formato específico ya que XML es texto-simple. XMLRPC/SOAP ha sido diseñado alrededor de HTTP (el protocolo utilizado en Internet), lo que no sólo facilita el problema de acceso("Firewalls") que siempre es un problema en sistemas CORBA, sino que abre la puerta a la posibilidad de acceder métodos remotos en maquinas de cualquier empresa, en el proceso automatizando intercambios de información de una manera transparente.

36 XMLRPC o SOAP: ¿Cuál es la diferencia ?
XMLRPC fue el primer mecanismo que surgió para invocar procedimientos remotos vía XML, ofrece una manera muy sencilla de invocar operaciones en sistemas heterogéneos a través de una estructura simple. SOAP ("Simple Object Access Protocol") es una implementación más robusta para llevar acabo una intercomunicación en XML. A diferencia de XMLRPC, a SOAP se le han integrado diversos mecanismos que le permiten operar en ambientes distribuidos mas complejos tales como: un lenguaje neutro para su descripción: WSDL y directorios distribuidos para su ubicación: UDDI o ebXML.

37 Referencias Curso XML, XSL, XMLRPC/SOAP
SOAP: XML-RPC: “The J2EE 1.4 Tutorial for NetBeans IDE 4.1” The Java BluePrints Web site. En particular: Designing Web Services (archivos PDF en dws-book) Designing Enterprise Applications with the J2EE Platform, Second Edition. I. Singh, B. Stearns, M. Johnson, Enterprise Team. Copyright 2002, Addison-Wesley. (archivo: designing_enterprise_apps-2_0-book.PDF)

38 J2EE y Servidores de Aplicación
Notas complementarias (mainly in english)

39 Especificaciones de las tecnologías J2EE
Java™ 2 Platform, Enterprise Edition Specification, Version 1.4 (J2EE specification). Java™ API for XML-Based RPC Specification, Version 1.1 (JAXP specification). Java™ API for XML Processing Specification, Version 1.2 (JAXP specification). SOAP with Attachments API for Java Specification, Version 1.2 (SAAJ specification). Java API for XML Registries Specification, Version 1.0 (JAXR specification). Web Services for J2EE Specification, Version 1.1. Java API for XML Binding Specification (JAXB specification). Java™ Servlet Specification, Version 2.4 (Servlet specification). JavaServer Pages™ Specification, Version 2.0 (JSP specification). Enterprise JavaBeans™ Specification, Version 2.1 (EJB specification). J2EE™ Connector Architecture Specification, Version 1.5 (Connector specification). Java™ Message Service Specification, Version (JMS specification).

40 J2EE 1.4 Platform Architecture

41 Component Technologies
Client component—The platform provides support for different types of clients to interact with components on the server side. Applet clients are Java based clients that usually run from within a Web browser and have full access to the features of the J2SE platform. Application clients (often referred to as stand-alone clients) execute in their own containers and have full access to J2EE platform services such as JNDI lookups, asynchronous messaging, and so forth. These clients can directly interact with the Web and EJB components on the server-side of the application. Web component—Web components provide a response to a request received via HTTP. The J2EE platform defines two distinct Web component types. Servlet components extend the functionality of a Web server in a portable and efficient manner. With servlets, developers can map a set of URLs to a set of servlets. As a result of such mapping, an HTTP request to one of the URLs invokes the mapped servlet, which in turn processes the request and returns a response. Servlet components can also be exposed as Web services. JSP components, as well as servlet components, enable the generation of dynamic content. Enterprise JavaBeans component—Enterprise JavaBeans (EJB) components are designed specifically with business logic in mind. EJB components are scalable, transactional, and secure. Session bean components usually provide services to a single client, and their state cannot be recovered after a server crash. Furthermore, stateless session bean components can be exposed as Web services. Entity bean components are the object representation of data maintained in a data store. These components manage persistent data, either managing the persistence on their own or depending on the container to manage their persistence. Message-driven bean components enable clients to access business logic contained within enterprise bean components in an asynchronous manner. A timer service enables the implementation of timed operations.

42 Platform and Container Services
Naming service—A naming service allows symbolic access to EIS resources and components within a naming environment. These components can be customized when assembled or deployed without requiring changes to the look-up source code. Deployment service—A deployment service allows changes to component behavior (such as transaction requirements and security requirements) at deployment without the need to change a component’s source code. Transaction service—A transaction service frees the component developer from having to include code to handle such transactional issues as multi-user access and failure/recovery. A transaction service allows the transaction requirements for components to be specified when they are assembled. Security service—A security service ensures that components and resources are accessed by only those authorized for access. In addition, a security service provides authentication and confidentiality, among other services, for users.

43 Communication Internet protocols—The J2EE platform supports such standard, common Internet protocols as TCP/IP, HTTP, SSL, and so forth. These Internet protocols enable communication between components and between components and their clients. Remote Method Invocation (RMI) protocols—The J2EE platform supports the Java RMI. Java RMI relies on the Remote Method Invocation APIs, which use Java language interfaces to define remote interface objects. The platform uses IIOP to turn local method invocations into remote method invocations. Messaging technologies—In addition to its support for these Internet and RMI synchronous protocols, the J2EE platform supports technologies that enable asynchronous communication. Examples of these technologies are the Java Message Service API and the JavaMail API. Web service technologies—The J2EE platform also supports Web servicespecific technologies and protocols that, along with the already mentioned technologies and protocols, standardize communication between J2EE components and J2EE clients. With the advent of Web services, which improve interoperability with non-Java clients, the J2EE platform supports Web service standards such as SOAP and UDDI using technologies such as Java API for XML-based RPC, Java API for XML Registries, and so forth.

44 Java Application Servers
Un Java Application Server (ya denominado Application Server) proporciona el ambiente necesario para ejecutar EJB's y su estructura es la siguiente: Los dos componentes principales de un Application Server son el "Servlet Engine" (Web-Container) y "Enterprise Bean Engine" (Bean-Container) aunque no sean comercializados como tal. Dentro del "Servlet Container" residen y se ejecutan JSP's y Servlet's, mientras que en el "Enterprise Bean Container" se ejecutan los EJB's.

45 Application servers fully J2EE Compliant
Existen varios en el mercado. Entre los mas usados: Sun Application Server (gratuito para desarrolladores) Apache Tomcat (Open Source - gratuito) JBoss (Open Source – gratuito) Oracle 10g Application Server (descarga gratuita) IBM Websphere (bajo licencia comercial) BEA WebLogic (bajo licencia comercial) En estos "Application Servers" no existe una clara distinción (al menos para el programador final) entre el "Servlet Engine" y el "EJB Engine" por lo que la ejecución de componentes se lleva acabo de una manera relativamente transparente. En este curso se utiliza Sun Application Server, aunque debe destacarse que también NetBeans posee la opción de utilizar Apache Tomcat, el cual trae como servidor asumido. Puede consultar detalles adicioanles sobre Servidores de Páginas y de aplicaciones en: "Web Servers" y "Java Application Servers"

46 Herramientas J2EE SUN Microsystems Developer Network
XML Sun Developer Network Java API for XML Processing (JAXP) Java API for XML Registries (JAXR) Java API for XML-based RPC (JAX-RPC) Java Architecture for XML Binding (JAXB) Introducción a JAXB con NetBeans SOAP with Attachments API for Java (SAAJ) The J2EE 1.4 Tutorial for NetBeans IDE 4.1

47 J2EE Platform Web Service Support

48 JAXP - análisis sintáctico abstracto
Permite procesar documentos XML de manera neutral respecto a los diferentes vendedores. Soporta los modelos SAX y DOM. Empleo de JAXP para implementar análisis sintáctico abstracto (Abstract Parser Implementations) desde una aplicación de usuario. Java API for XML Processing (JAXP)

49 SAX-Based XML Parser API
La figura muestra como funciona el analizador sintáctico en SAX: SAX procesa documentos serialmente, convirtiendo los elementos de un documento XML en una serie de eventos. Cada elemento particular genera un evento con eventos únicos representando varias partes del documento. El usuario suministra manipuladores de eventos para atender a los que ocurran y realizar las acciones apropiadas. El procesamiento en SAX es rápido, debido a su acceso en serie y a sus bajos requerimientos de almacenamiento en memoria.

50 DOM-Based XML Parser API
La figura muestra como funciona el analizador sintáctico en DOM: El procesamiento en DOM crea un árbol de elementos en el documento XML. Aunque este enfoque requiere mas memoria para almacenar el árbol, esta característica permite acceso aleatorio al contenido del documento y habilita la división del mismo en fragmentos, lo que facilita codificar el procesamiento DOM. DOM también facilita crear nuevos documentos, cambiarles, o adicionarles a otros documentos XML que se reciban.

51 Arquitectura de JAXR Permite acceder a registros de negocios con una API que soporta cualquier tipo de especificación de registros. Java API for XML Registries (JAXR)

52 Interoperabilidad en JAXR
Con cualquier cliente y para todo servicio registrado. Discover and publish Web Services with JAXR

53 Arquitectura JAX - RPC Java API for XML-based RPC (JAX-RPC)
Permite intercambiar solicitudes y respuestas SOAP a través de un API que esconde los detalles complejos de SOAP a los desarrolladores. Java API for XML-based RPC (JAX-RPC)

54 Binding Parameters and Return Values with JAX-RPC

55 Arquitectura JAXB Suministra una herramienta de enlace de datos XML.
Java Architecture for XML Binding (JAXB)

56 Ejemplos Building Web Services with JAX-RPC: SAAJ client applications:
Building the Service: helloservice J2EE Container-Generated Static Stub Client: webclient IDE-Generated Static Stub Client: staticstub Dynamic Proxy Client: dynamicproxy Dynamic Invocation Interface Client: diiclient SAAJ client applications: MyUddiPing HeaderExample DOMExample Attachments SOAPFaultTest Todos estos ejemplos han sido tomados de “The J2EE 1.4 Tutorial for NetBeans IDE 4.1” NB-J2EETutorial

57 … los ancestros de los Servicios Web.
RMI, RPC, CORBA y DCOM … los ancestros de los Servicios Web.

58 Java Remote Method Invocation - RMI
Mecanismo ofrecido en Java para invocar un método remotamente. Al ser parte estándar del entorno de ejecución Java, usarlo provee un mecanismo simple en una aplicación distribuida que solamente necesita comunicar servidores codificados para Java. Si se requiere comunicarse con otras tecnologías debe usarse CORBA o SOAP en lugar de RMI. Al estar específicamente diseñado para Java, RMI puede darse el lujo de ser muy amigable para los programadores, proveyendo paso por referencia de objetos, cosa que no hace SOAP, "recolección de basura" distribuida y pasaje de tipos arbitrarios, funcionalidad no provista por CORBA.

59 RMI (2) Por medio de RMI, un programa Java puede exportar un objeto.
A partir de esa operación este objeto está disponible en la red, esperando conexiones en un puerto TCP. Un cliente puede entonces conectarse e invocar métodos. La invocación consiste en el "marshaling" de los parámetros utilizando la funcionalidad de "serialización" que provee Java, para seguir con la invocación del método en el servidor. Mientras esto sucede, el cliente que llamó queda esperando por una respuesta. Una vez que termina la ejecución, el valor de retorno es serializado y enviado al cliente. El programa cliente recibe este valor como si la invocación hubiera sido local.

60 RMI (3) Para implementar un servidor RMI se debe crear una interfaz que enumere las funciones provistas por el objeto a ser exportado por la red. Esta interfaz es compartida entre cliente y servidor. Del lado servidor es necesario implementar esta interfaz con una clase que provea la funcionalidad. Del lado cliente el llamador accede a la misma interfaz, pero debajo hay un "stub" que da comienzo a la llamada vía la red. Hasta versiones recientes de Java era necesario generar manualmente el "stub" por medio de un compilador especial llamado rmic. El lado cliente y el lado servidor deberán tener ambos acceso a la definición de las clases utilizadas para el intercambio de parámetros y de valores de retorno. Para esto Java tiene la capacidad de dinámicamente obtener las clases que se necesiten desde un servidor.

61 Desventajas de RMI Algunas desventajas que pueden comentarse son:
Solo interconecta programas Java. Esto puede subsanarse utilizando una versión "híbrida" de RMI que utiliza CORBA como transporte. Los objetos a ser exportados tienen que heredar (¡sí o sí!) de un objeto base dado por la API. En general la implementación de RMI tiende a ser bastante invasiva, condicionando varios aspectos de la solución. RMI envía bastante información propia a través de la conexión además de los datos del objeto en sí mismo, por lo que no es apto para cuando la conexión hardware es "lenta", por ejemplo a través de un puerto serie si se requiere un refresco rápido de la información.

62 Remote Procedure Call - RPC
El protocolo de Llamada a Procedimiento Remoto permite a un programa ejecutar código en un computador remoto sin tener que preocuparse por las comunicaciones entre ambos. Fue propuesto inicialmente por Sun Microsystems como un gran avance sobre los sockets usados hasta el momento. De esta manera el programador no tenía que estar pendiente de las comunicaciones, que quedaban encapsuladas dentro de las RPC. Las RPC son muy utilizadas dentro del paradigma cliente-servidor, siendo el cliente quien inicia el proceso solicitando al servidor que ejecute cierto procedimiento o función y enviando éste de vuelta el resultado de dicha operación al cliente. Hay distintos tipos de RPC, muchos de ellos estandarizados como pueden ser el RPC de Sun (RFC 1057), Distributed Computing Environment (DCE), DCOM de Microsoft, no siendo compatibles entre sí. La mayoría de ellos utilizan un lenguaje de descripción de interfaz (IDL) que define los métodos exportados por el servidor. Hoy en día se está utilizando el XML como lenguaje para definir el IDL y el HTTP como protocolo de red, dando lugar a los servicios Web.

63 Common Object Request Broker Architecture (CORBA)
Estándar que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocación de métodos remotos bajo un paradigma orientado a objetos. Fue definido y está controlado por el Object Management Group (OMG) que define las APIs, el protocolo de comunicaciones y los mecanismos necesarios para permitir la interoperabilidad entre diferentes aplicaciones escritas en diferentes lenguajes y ejecutadas en diferentes plataformas, lo que es fundamental en computación distribuida. En un sentido general, CORBA "envuelve" el código escrito en otro lenguaje en un paquete que contiene información adicional sobre las capacidades del código que contiene, y sobre cómo llamar a sus métodos. Los objetos que resultan pueden entonces ser invocados desde otro programa u objeto CORBA desde la red. En este sentido CORBA se puede considerar como un formato de documentación legible por la máquina, similar a un archivo de cabeceras pero con más información.

64 CORBA (2) CORBA utiliza un lenguaje de definición de interfaces (IDL) para especificar los interfaces con los servicios que los objetos ofrecerán. Puede especificar a partir de este IDL la interfaz a un lenguaje determinado, describiendo cómo los tipos de dato CORBA deben ser utilizados en las implementaciones del cliente y del servidor. Existen implementaciones estándar para Ada, C, C++, Smalltalk, Java y Python. Hay también implementaciones para Perl y TCL. Al compilar una interfaz en IDL se genera código para el cliente y el servidor (el implementador del objeto). El código del cliente sirve para poder realizar las llamadas a métodos remotos. Es el conocido como stub, el cual incluye un proxy (representante) del objeto remoto en el lado del cliente. El código generado para el servidor consiste en unos skeletons (esqueletos) que el desarrollador tiene que rellenar para implementar los métodos del objeto. CORBA es más que una especificación multiplataforma, también define servicios habitualmente necesarios como seguridad y transacciones.

65 Distributed Component Object Model - DCOM
El Modelo de Objetos de Componentes Distribuidos, es una tecnología propietaria de Microsoft para desarrollar componentes software distribuidos sobre varios ordenadores y que se comunican entre sí. Extiende el modelo COM de Microsoft y proporciona el sustrato de comunicación entre la infraestrcutura del servidor de aplicaciones COM+ de Microsoft. Ha sido abandonada en favor del framework .NET DCOM fue uno de los mayores competidores de CORBA. Los defensores de ambas tecnologías sostenían que algún día serían el modelo de código y servicios sobre Internet. Sin embargo, las dificultades que suponía conseguir que estas tecnologías funcionasen a través de cortafuegos y sobre máquinas inseguras o desconocidas, significó que las peticiones HTTP normales, combinadas con los navegadores Web les ganasen la partida. Microsoft, en su momento intentó y fracasó anticiparse a esto añadiendo un transporte extra HTTP a DCE/RPC denominado "ncacn_http" (Connection-based, over HTTP).


Descargar ppt "Clase 11 Introducción a los Servicios Web"

Presentaciones similares


Anuncios Google