Eser2 A

E-Services Posgrado en E-Business Management Universidad del Salvador - Argentina Geogetown University - U.S.A. Período 2007 2. Arquitectura técnica general y estándares (primera parte)

” La próxima generación de la Web no será sobre cómo construir punto com’s, sino sobre cómo conectar los puntos." Tod Nielsen Microsoft’s Platform Group Opiniones

Ampliación de la definición técnica de Web Services
Concepto de SOA (Arquitectura Orientada a Servicios)
Estándares básicos de los Web Services
Agenda de temas

Conceptualmente, con visión de negocios:
Los servicios web representan un modelo en el cual funcionalidades de procesos e-business son desplegadas y ofrecidas a terceros a través de Internet.
Conceptualmente, con visión técnica :
Los servicios web son un conjunto de estándares, que describen una arquitectura de aplicación orientada a servicios y basada en componentes.
Lo recordamos nuevamente

No todos los servicios basados en Internet son “servicios web”.
No todas las aplicaciones web son aplicaciones de “servicios web”.
Lo recordamos nuevamente

¿Qué es una Arquitectura Orientada a Servicios?
SOA (Service-Oriented Architecture) es el “gran cuadro” de lo que se puede hacer con web services.
Es un enfoque conceptual para construir aplicaciones distribuidas, que suministren funcionalidades como “ servicios ”, a ser utilizados en aplicaciones de usuarios finales o en la construcción de otros servicios.
En SOA , un servicio es una funcionalidad “empaquetada” como un componente y reutilizable en procesos de negocios.

¿Qué es una Arquitectura Orientada a Servicios? Service Broker Service Requester Service Provider mensajes Búsqueda Publicación Roles básicos en SOA Crea el servicio y ofrece su uso a terceros Detecta, invoca y utiliza el servicio . Registra y categoriza los servicios y provee mecanismos de búsqueda

Factores clave que impulsan la adopción de SOA (Fuente: “SOA in the Enterprise”, The SOA Magazine, www.soamag.com, Agosto 2006) Impulsa a adoptar nuevas prácticas de negocios Impulsa a inyectar nuevos controles en los procesos de negocios Impulsa a adoptar mecanismos estándares de integración Impulsa el camino hacia una empresa abierta y orientada a servicios Una gran parte del potencial de SOA radica en su capacidad de incrementar la “agilidad” de la operación de una compañía, ya que posibilita que sus departamentos de IT puedan responder más rápidamente a las necesidades del mercado y de los negocios en particular.

“ Servicios Web” son:
Componentes de software reutilizables , libremente acoplables , que:
encapsulan semánticamente funcionalidades discretas,
se distribuyen a través de protocolos estándar de Internet,
y pueden ser accedidos programáticamente.
(Fuente: The Stencil Group)
Una definición técnica de Web Services

“ Componentes de software reutilizables ” significa que los desarrolladores de aplicaciones e-business pueden reutilizar partes de código escritas por otros, y ensamblarlas en nuevas maneras.
“ libremente acoplables ” significa que la conexión,
reconfiguración y reemplazo de esas partes es simple y
flexible.
“ Encapsulan semánticamente funcionalidades discretas ” significa que son módulos de software que ejecutan una tarea y que describen sus propios inputs y outputs, de manera tal que otros módulos los puedan invocar y utilizar.
Aclaración de términos

“ Se distribuyen a través de protocolos estándar de Internet ” significa que aprovechan los protocolos de transporte existentes en la Web, por ej. HTTP.
“ Pueden ser accedidos programáticamente ” significa que no son diseñados a priori para la interacción humana directa , sino para ser llamados por otros módulos de software e intercambiar datos con ellos. Sin embargo, se incorporan en aplicaciones construídas para interactuar con personas (por ej., un web site).
Aclaración de términos

Sin estándares de interoperabilidad Cia. A Cia. C Cía. B Funcionalidad... Funcionalidad... Funcionalidad... Funcionalidad... Funcionalidad... integración B - C integración A - C Integración A -B Ambiente A Ambiente B Ambiente C Funcionalidad...

Con estándares de interoperabilidad Cia. A Cia. C Cía. B Funcionalidad... Funcionalidad... Funcionalidad... Funcionalidad... Funcionalidad... Funcionalidad... UDDI WSDL SOAP XML Marco de estándares Ambiente A Ambiente B Ambiente C

Las Organizaciones de Estándares
OASIS
W3C
WS-I

Las Organizaciones de Estándares
OASIS (Organization for the Advancement of Structured Information Standards) : es un consorcio internacional sin fines de lucro, cuyo objetivo es impulsar el desarrollo, convergencia y adopción de estándares e-business. Fue fundado en 1993 bajo el nombre “SGML Open” y toma su denominación actual en 1998.
W3C (World Wide Consortium): fundado en 1994 por Tim Berners-Lee, su finalidad es llevar a la Web a su completo potencial, a través del desarrollo de protocolos comunes que promuevan su evolución y aseguren su interoperabilidad.
WS-I (Web Services Interoperability Organization): fundada en el 2002, tiene entre sus miembros a importantes compañias (como IBM, Microsoft, HP y Sun, entre otras), y su objetivo principal es promover la interoperabilidad de los servicios web a través de las diversas plataformas y sistemas.

Esta organismo tiene como misión principal promover la interoperabilidad de los servicios web, en base a los siguientes objetivos:
Articular y promover una visión común de la industria para la interoperabilidad de web services
Promover la consistencia e interoperabilidad de web services entre distintas plataformas, aplicaciones y lenguajes de programación
Proporcionar soporte y capacitación para la implementacion de web services
En esa dirección, en marzo de 2004, liberó dos herramientas de software (Monitor y Analyzer) destinadas a evaluar si un Web Service cumple o nó las pautas de interoperabilidad dadas en su documento “ WS-I Basic Profile ”.
En abril de 2007 dió otro paso importante, al anunciar la publicación del documento “ Basic Security Profile 1.0 ” (BSP 1.0).
La misión de la “Web Services Interoperability Organization”

Estándares básicos de Web Services

El “stack” de estándares de Web Services Protocolos de Internet (TCP/IP, HTTP) Extensible Markup Languaje (XML) BPEL, WSCI, etc. Web Services Description Languaje (WSDL) Universal Description, Discovery and Integration (UDDI) Simple Object Access Protocol (SOAP) Formato Mensajería Descripción Registración y búsqueda Niveles básicos T ransporte Monitoreo, Performance, Seguridad, etc. Composición de Procesos Management Niveles avanzados

A la manera de Web Services Compañía A Compañía B UDDI publicación publicación Obtiene el WSDL de B Registro de Servicios Web WSDL WSDL Obtiene el WSDL de A Describe el Servicio Web de la Cia. A Describe el Servicio Web de la Cia. B Invoca y utiliza el Servicio Web de B Invoca y utiliza el Servicio Web de A Protocolos de transporte de Internet (HTTP, etc.) Mensajería SOAP 1 2 3 4 (Fuente: www.webservicesarchitect.com)

A la manera de Web Services

Dos tipos básicos de Servicios Web Servicios web Sincrónicos o estilo “RPC” Asincrónicos o estilo “documento” Reciben parámetros como input, realizan su proceso y siempre generan un output inmediato. Son servicios web “básicos”. Reciben documentos XML como input y no tienen asociado un output inmediato. Posibilitan componer procesos.

XML (Lenguaje de Marcado Extensible) es un formato para la descripción e intercambio de datos sobre la web. XML adjunta “etiquetas” (tags) a los datos, de modo que cualquier aplicación pueda interpretarlos y procesarlos.
XML describe objetos llamados “documentos XML”, compuestos de datos y marcado, ambos conocidos como “texto XML”.
XML fue desarrollado en el W3C como subconjunto de un lenguaje anterior denominado SGML (Lenguaje Estandarizado y Generalizado de Marcado), que estaba normalizado desde el año 1986.
XML es el “bloque básico de construcción” sobre el que se apoyan los niveles siguientes de estándares de los servicios web.
E X tensible M arkup L anguaje

SOAP es un protocolo, basado en XML, utilizable para mensajería entre aplicaciones distribuídas sobre la Web , que permite transportar todo tipo de datos. Posibilita a una aplicación “invocar” a otra localizada remotamente (por ej., en otra compañía).
Fue desarrollado originalmente por Microsoft, junto a otras dos compañias, en 1999. Para esa época ya existían otras soluciones alternativas (por ej., CORBA) pero no aseguraban la interoperabilidad técnica entre diferentes sistemas, como lo hace SOAP .
SOAP se apoya en el protocolo de transporte HTTP , aunque teóricamente los mensajes SOAP pueden enviarse sobre cualquier otro protocolo de la Web (por ej., FTP).
En junio de 2003, el W3C liberó la versión 1.2 de SOAP con estatus de “recomendación”. En abril de 2007 se liberó SOAP 1.2 segunda edición.
S imple O bject A ccess P rotocol

Estructura básica de un mensaje SOAP SOAP HEADER SOAP BODY Marca el inicio y el y el fin de un mensaje SOAP. Es obligatorio y contiene los datos propiamente dichos a intercambiar. Los mensajes (“payload”) pueden consistir en parámetros o en documentos completos. No es obligatorio. Permite agregar “ extensiones”. Mensaje SOAP SOAP ENVELOPE

WSDL es un lenguaje, basado en XML, que se utiliza para describir los mensajes, el tipo de datos a intercambiar y la localización de un servicio web.
Básicamente, es gramática XML que especifica qué hace el servicio, dónde reside y cómo invocarlo.
WSDL fue creado por IBM y Microsoft y su primera versión se liberó en septiembre del 2000. Actualmente la más conocida es la 1.1 , aunque la 2.0. está próxima a convertirse en “recomendación” del W3C.
Por otro parte, en julio de 2006 se conoció el primer borrador público de la version 1.0 de SAWSDL (Semantic Annotations for WSDL), que permitirá relacionar con distintos significados externos a las descripciones WSDL 2.0.
W eb S ervices D escription L anguaje

Estructura básica de un documento WSDL El “QUÉ” Documento WSDL EL “QUÉ” EL “CÓMO” EL “DÓNDE” Describe detalles de implementación técnica. Define los mensajes de input/output y los tipos de datos a intercambiar entre cliente y servidor. Los mensajes pueden ser estilo RPC o documentos. Indica dónde está localizado el web service (URL).

El proyecto UDDI fue anunciado por Microsoft, IBM y Ariba en septiembre de 2000, cuando se conoció el primer borrador de esta especificación. “UDDI.org” nucleó a más de 300 compañias que apoyaron su desarrollo.
La visión inicial que impulsó a UDDI fue la de ser una “base de datos mundial” de servicios ofrecidos via Web , como eslabón que permitiera a las partes proveedora y consumidora de servicios web “encontrarse” unas a otras, y acceder a la información especifica sobre los mismos.
En ese sentido, UDDI nació como un directorio online, global y público (denominado “UBR”: UDDI Business Registry). Pero en rigor, es un protocolo estándar, basado en XML, que permite registrar y localizar no sólo Web Services, sino también otros servicios, sean electrónicos o nó .
La especificación UDDI permite también la creación de registros privados , dentro del ámbito de una compañía u organización, y que pueden compartirse con terceros. Ya que éste es actualmente el uso predominante de UDDI , la operación del UBR fue discontinuada en enero de 2006, luego de 5 años de actividad.
U niversal D escription, D iscovery and I ntegration (UDDI)

Los distintos tipos de Registros UDDI (Fuente: “The evolution of UDDI”, paper del Stencil Group, julio 2002) El Registro Público (UBR), operó hasta enero de 2006 Registro UDDI Privado (intraempresa) Registro UDDI Compartido (interempresa)

A mediados del 2002 se anunció que las especificaciones UDDI pasaban a desarrollarse y emitirse bajo la órbita de la OASIS , de la cual UDDI.org se transformó en miembro. UDDI 3.0 es estándar de la OASIS desde febrero de 2005.
Tanto la registración como la búsqueda de web services en registros UDDI se puede realizar desde aplicaciones que utilicen interfases de programación (APIs) basadas en SOAP.
Conceptualmente, la información acerca de los servicios que cataloga UDDI se halla organizada en 3 tipos de “ páginas ”: compañias , servicios y descripciones técnicas de los mismos.
Más sobre UDDI

La estructura de datos de un registro UDDI Páginas Blancas Páginas Amarillas Páginas Verdes ESTRUCTURA DEL DIRECTORIO UDDI
N ombre de la Cias.
Datos Identificatorios
Info de contacto
Descripción general
de los servicios
Indice de Servicios
Categorías de
Servicios
Descripción técnica
de los servicios
Acceso a los
servicios
Lista de Companías Lista de Servicios Inf. Técnica (Fuente: The Stencil Group)

Compañía A Servicio “X” Servicio “Z” “ Binding Template” “ Binding Template” Compañía B TModel (Fuente: www.uddi.org) Indica el “Access Point” para acceder físicamente al servicio (http, mailto, phone, etc.) Es un “pointer” al lugar donde está la descripción técnica del servicio Compañía C Por ej., puede ser una subsidiaria o una división de la Compañia A Documento WSDL Relación La estructura de datos de un registro UDDI

Ni obligatoria ni necesariamente un servicio web debe estar registrado en un directorio UDDI.
Podría también registrarse en cualquier otro directorio online operado por terceros.
Esto abre la posibilidad a un nuevo modelo de negocios: el “ brokerage ” de servicios web.
Un ejemplo de tales brokers es “ www.xmethods.com ”.
Alternativas a UDDI: los “brokers” de Web Services

Anunciada por IBM y Microsoft en noviembre de 2001, la especificación WSIL provee un mecanismo para la búsqueda de web services directamente en los sitios web de los Service Providers.
WSIL permite a los Service Providers publicar en su propio site un documento llamado “Inspection.WSIL” que lista los servicios ofrecidos y referencia sus correspondientes WSDL. Luego, ese documento puede ser localizado en la web por los buscadores.
De esta manera, WSIL es un mecanismo de búsqueda descentralizada de web services, complementario de UDDI .
Los documentos “Inspection.WSIL” pueden contener referencias a otro documento “Inspection.WSIL” y también a entradas en registros UDDI.
Alternativas a UDDI: W eb S ervices I nspection L anguaje

W eb S ervices I nspection L anguaje Service Requestor Registro UDDI Service Provider Web Site Web Service Service Description Documento Inspection.wsil Documento Inspection.wsil Service Description Service Description Búsqueda Búsqueda http://webserviceejem.com/inspection.wsil (Fuente: IBM developerWorks)

Macrovisión UDDI SOAP WSDL Web Services es accedido utilizando el protocolo apunta a crear la mensajería describe posibilita obtener el documento permite la invocación de

Siendo los portales sitios web que sirven como front-ends a aplicaciones y datos corporativos u organizacionales , los web services son ideales para acceder a esas aplicaciones y datos, y posibilitan construir portales que sean más dinámicos y fáciles de mantener.
Sin embargo, por ciertas limitaciones de seguridad, los primeros portales basados en web services apuntarán a reunir y visualizar información , más que a intervenir en verdaderos procesos de negocios.
Esto trae la posibilidad de construir portales destinados a un target de usuarios específicos dentro de una misma compañía u organización (por ejemplo, sus principales ejecutivos).
Un factor clave para el éxito de los portales basados en web services, es que los estándares que le dan soporte sean ampliamente aceptados y utilizados (por vendors y usuarios).
Portales y Web Services: un interesante “mix”

Web Services for Remote Portlets (WSRP) 1.0 , es un estándar aprobado por la OASIS en septiembre de 2003, que permite integrar dinámicamente en los portales (al modo “plug-and-play”) web services con interfase visual de usuario . El borrador de la versión 2.0 de WSRP se aprobó en junio de 2006.
A través de WSRP los portales pueden integrar fácilmente contenidos y aplicaciones de distintos Web Services Providers. Es el Service Provider quien determina cómo será la presentación visual del servicio al usuario final.
Los servicios WSRP podrán ser publicados en UDDI a fin de ser “localizados” por quienes deseen integrarlos en sus aplicaciones.
Los web services con interfase visual de usuario son un paradigma que complementa a los web services “tradicionales” , orientados solamente a datos de entrada y salida (sin interfase humana).
Portales y Web Services: ¿qué estándares hay?

Otro estándar es el denominado JSR 168, versión 1.0, desarrollado por la Java Community Process (jcp.org) y aprobado en octubre de 2003.
Dicha especificación no posibilita construir directamente portales, sino “ portlets ”.
Básicamente, un portlet es un componente Java que toma un requerimiento de usuario y genera contenido dinámico basado en ese requerimiento. Es una interfase de usuario “enchufable” a aplicaciones o datos específicos.
Un portal puede entonces construirse con una interfase y un determinado “set” de portlets individuales, que pueden ser fácilmente cambiados para apuntar a diferentes grupos de usuarios.
Portales y Web Services: ¿qué estándares hay?

Es posible acceder a web services desde dispositivos de acceso inalámbrico, como celulares y PDAs, pero existen limitaciones dadas por la capacidad de procesamiento de esos dispositivos.
Uno de los impulsores del uso de web services en dispositivos móviles es la compañía Nokia, que dá soporte a tal tecnología en algunos modelos de sus celulares.
Por otro lado, la Open Mobile Alliance (un consorcio global creado en el 2002 e integrado por más de 350 compañias, que impulsa el desarrollo de estándares para servicios móviles interoperables), ha publicado en junio de 2004 su especificación OMA Web Services 1.0 .
Dicha especificación de la OMA define los medios y prácticas por los cuales las aplicaciones pueden ser expuestas, descubiertas y consumidas utilizando tecnologías de web services.
Web Services en dispositivos móviles

REST (Representational State Transfer) no es una especificación ni puede ser considerado un estándar, sino que es un conjunto de principios o “estilo” de arquitectura técnica.
REST es un término acuñado en el año 2000 por Roy Fielding, en su tesis doctoral. Fielding es uno de los desarrolladores del protocolo HTTP, piedra fundacional de la World Wide Web (WWW).
Con REST, los servicios web son desplegados sin utilizar el stack de estándares básicos (SOAP, WSDL, UDDI), a través del envío de mensajes XML sobre HTTP, utilizando los “verbos” de este protocolo (ej.: GET/POST).
Con el enfoque REST , “servicio” es entendido como “recurso”.
La alternativa REST ante para desplegar servicios web

La principal ventaja de REST es la simplicidad para el desarrollador, y esto hizo que haya ganado muchos adeptos en la comunidad técnica.
No obstante, dicha simplicidad conlleva el costo de carencias en mecanismos de seguridad y confiabilidad en la mensajería y de coordinaciòn de workflows complejos, como los que proveen la suite de estándares de los servicios web (“ WS-* ”).
Por dicha razón, REST tiene algunas limitaciones para su uso general corporativo o con servicios asíncronos, pero es una alternativa válida para construir servicios web “livianos”.
Entre los adoptantes de REST están eBay, Google y Yahoo .
Valoración de REST

REST vs. “WS-*”
REST es un estilo de arquitectura técnica, con la simplicidad como fortaleza, mientras que los estándares “ WS-* ” conforman un elaborado conjunto de especificaciones, aunque complejo.
Con una comunidad de desarrolladores REST muy activa, ha surgido cierto debate acerca de si los estándares “ WS-* ” son demasiado complejos y si REST es una opción más simple y preferible. Entonces... ¿puede REST ser la alternativa de facto a “ WS-* ” ?.
En realidad, es mejor percibirlos como complementarios , con los estándares “ WS-* ” aptos (por ejemplo) para casos de publicación de servicios y mensajería confiable, y con REST utilizable (por ejemplo) para hacer accesibles datos a terceros con interfases simples.
En ese sentido, la nueva especificación WSDL 2.0 incorpora la posibilidad de utilizar el estilo REST como alternativa a SOAP.

Eser2 A

by My own sweet home

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 7

Statistics

Eser2 A Presentation Transcript

Eser2 A

by My own sweet home

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 7

Statistics

Eser2 A Presentation Transcript

Let LinkedIn power your SlideShare experience

Let LinkedIn power your SlideShare experience

Customize SlideShare content based on your interests

Keep up to date when your LinkedIn contacts post on SlideShare