Web Services. Estado Del Arte

UNIVERSIDADPONTIFICADESALAMANCACAMPUSDEMADRID
EstadodelArtede losServiciosWeb
PRIMERAVANCEDELTRABAJODEINVESTIGACIONDEA
EdwinAlbertoValenciaCastillo 11/04/2008
EstadodelArtedelosServiciosWeb 2008
INDICE
INDICE_________________________________________________________________________________ 2 INTRODUCCION _________________________________________________________________________ 3 I. SERVICIOSWEB_____________________________________________________________________ 4 1.1. 1.2. 1.3. 1.4. II. DEFINICION____________________________________________________________________ 4 CARACTERISTICAS_______________________________________________________________ 5 BENEFICIOS____________________________________________________________________ 6 ELEMENTOS____________________________________________________________________ 7
ARQUITECTURADESERVICIOSWEB ____________________________________________________ 10 2.1. COMPONENTESDELAARQUITECTURA _____________________________________________ 11 2.1.1. Servicio__________________________________________________________________ 11 2.1.2. ProveedordeServicio_______________________________________________________ 11 2.1.3. RegistrodeServicios ________________________________________________________ 11 2.1.4. SolicitantedeServicios______________________________________________________ 11 2.2. OPERACIONESDELAARQUITECTURA_______________________________________________ 12 2.2.1. Publicar/Cancelar__________________________________________________________ 12 2.2.2. Buscar___________________________________________________________________ 12 2.2.3. Enlazar(Bind)_____________________________________________________________ 12 2.3. MODELOSARQUITECTONICOS____________________________________________________ 13 2.3.1. ElModeloorientadoamensajes ______________________________________________ 13 2.3.2. ElModeloorientadoaservicios_______________________________________________ 14 2.3.3. Modeloorientadoarecursos_________________________________________________ 14 2.3.4. ModelodePolticas ________________________________________________________ 15
III. ESTANDARESYESPECIFICACIONESRELACIONADOSCONLOSSERVICIOSWEB__________________ 16 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. IV. 4.1. 4.2. SOAP(SIMPLEOBJECTACCESSPROTOCOL)_______________________________________________ 21 WSDL(WEBSERVICEDESCRIPTIONLANGUAGE)____________________________________________ 23 UDDI(UNIVERSALDESCRIPTIONDISCOVERYANDINTEGRATION)_________________________________ 25 WSSECURITY _________________________________________________________________ 26 WSPOLICY____________________________________________________________________ 28 WSI_________________________________________________________________________ 29 WSBPEL _____________________________________________________________________ 29 RESTUNAPROPUESTAALTERNATIVAASOAP _________________________________________ 31 DEFINICION___________________________________________________________________ 31 PRINCIPIOS ___________________________________________________________________ 32
REFERENCIASBIBLIOGRAFICAS____________________________________________________________ 33
EdwinValenciaCastillo
INTRODUCCION

En la actualidad, la web, es la puerta de entrada a todo un conjunto de servicios ofrecidos por empresas o personas independientes, generando gran cantidad de interacciones persona servicio en la internet, sin embargo, un gran nmero de interacciones que se genera en la web, se da entre aplicaciones, es decir las empresas tienen que comunicarse con otras empresas para realizar transacciones ms complejas. Para establecer dichas comunicaciones, se han creado estndares quesehanagrupadobajoladenominacindeserviciosweb. Estos estndares permiten que las empresas categoricen los tipos de servicios que ofrecen,describircmodebeinteractuarconotrasaplicacionesydefinircomoser codificada la informacin intercambiada entre un cliente y un proveedor de un serviciodeterminado. Enlaactualidad,lasempresasestnusandolosservicioswebcomoconstrucciones bsicas para el desarrollo de aplicaciones, creando nuevas arquitecturas de software orientadas a servicios (ServiceOriented Architecture, SOA), donde las funcionalidades se definen como servicios independientes, con interfaces invocables bien definidas, que pueden ser llamadas en secuencias especificas formando procesos de negocios. El objetivo es ser ms flexible, donde las empresas compartan informacin, procesos y sus mejores prcticas a travs de toda la empresa, con capacidades modulares que puedan ser rpidamente configuradasparacrearoportunidadesyresolverproblemas. El presente trabajo busca detallar el estado del arte de los servicios web y sus arquitecturas,tratandodedescribirsusestndaresynuevastendencias.
I.
SERVICIOSWEB
DEFINICION
El W3C 1 Web Services Architecture Working Group, define un servicio web como un sistema software diseado para soportar la interaccin interoperable de maquina a mquina sobre una red. Tiene una interfaz descrita en un formato procesable por un computador (especficamente WSDL). Otros sistemas interactan con los servicios web en una manera preestablecida por su descripcin usando mensajes SOAP, tpicamente usando el protocolo HTTP con una serializacin XML en conjunto con otros estndares webrelacionados.[1] Adems, especifica que un servicio web proporciona un medio estndar para interoperar entre diferentes aplicaciones software, ejecutndose en una variedad de plataformas y/o frameworks[1] El W3C tambin define a un servicio web como: Una aplicacin software identificada por un URI, cuyas interfaces se pueden definir, describir y descubrir mediante documentos XML. Un servicio Web soporta interacciones directas con otros agentes software utilizando mensajes XML intercambiados mediante protocolos basados en Internet. En [2] define que existen mltiples definiciones sobre lo que son los Servicios Web, lo que muestrasucomplejidadalahoradedarunaadecuadadefinicinqueenglobetodoloque son e implican. Una posible sera hablar de ellos como un conjunto de aplicaciones o de tecnologas con capacidad para interoperar en la Web. Estas aplicaciones o tecnologas intercambian datos entre s con el objetivo de ofrecer unos servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamandoaestosprocedimientosatravsdelaWeb. IBM, al respecto considera, que los servicios web son un conjunto de estndares emergentes que habilitan la integracin interoperable entre sistemas y procesos de TI heterogneos. Se puede pensar en aplicaciones web que son auto contenidas y auto descritas y que pueden proporcionar funcionalidad e inter operar alcanzando desde los procesos cientficos y de negocios ms bsicos hasta los ms complejos En resumen los servicios web mantienen y proporcionan un mecanismo estndar comn para la integracin interoperable entre sistemas dispares y la clave de su utilidad es la estandarizacin. Este mecanismo comn para entregar un servicio lo hace ideal para implementarunarquitecturaorientadaaservicios(SOA).[3] Podemos concluir que los servicios web son aplicaciones autocontenidas, autodescritas que pueden ser publicadas, localizadas e invocadas a travs de la web. Una vez
1.1.
W3C World Wide Web Consortium (http://www.w3.org/) es una iniciativa creada en 1994, en la que participan 400 organizaciones, y que pretende que el World Wide Web alcance su mximo potencial desarrollando protocolos comunes que permitan su evolucin y aseguren su interoperabilidad.
desarrolladas, otras aplicaciones (y otros servicios web) pueden descubrirlas e invocarlas respectivamente. Un ejemplo de funcionamiento de los servicios web extrado de [2] se muestran en la Fig. 1., donde un usuario (que juega el papel de cliente dentro de los Servicios Web), a travs de una aplicacin, solicita informacin sobre un viaje que desea realizar haciendo una peticinaunaagenciadeviajesqueofrecesusserviciosatravsdeInternet.Laagenciade viajesofrecerasucliente(usuario)lainformacinrequerida.Paraproporcionaralcliente la informacin que necesita, esta agencia de viajes solicita a su vez informacin a otros recursos (otros Servicios Web) en relacin con el hotel y la compaa area. La agencia de viajes obtendr informacin de estos recursos, lo que la convierte a su vez en cliente de esosotrosServiciosWebquelevanaproporcionarlainformacinsolicitadasobreelhotel y la lnea area. Por ltimo, el usuario realizar el pago del viaje a travs de la agencia de viajes que servir de intermediario entre el usuario y el servicio Web que gestionar el pago.
Figura1.Losservicioswebenfuncionamiento[2]
1.2.
CARACTERISTICAS
EnM.Endreiet.al.[4]identificamoslascaractersticasprincipalesdelosserviciosweb,los cualessedescribenacontinuacin: Los servicios web son autocontenidos: En el lado del cliente, no se requiere ningn software adicional. Un lenguaje de programacin con soporte para clientes XML y HTTP, por ejemplo, son suficientes para comenzar. En el lado del servidor, simplemente se requiere un servidor web y un motor de servlets. Es posible para los serviciosweb,habilitarunaaplicacinexistentesinescribirunalneadecdigo. Los servicios web son autodescritos: Ni el cliente ni el servidor conoce o pretende conocer acerca de cualquier cosa adems del formato y contenido de los mensajes de peticiones y respuestas (Integracin de aplicaciones dbilmente acopladas). La definicin del formato del mensaje viaja con el mensaje. No se requiere repositorios demetadatosexternosoherramientasgeneradorasdecdigo.
Los serviciosweb son modulares: Los servicios web son una tecnologa para desplegar y proporcionar acceso a funciones del negocio sobre la web; J2EE, CORBA, y otros estndaressontecnologasquepermitenimplementarestosserviciosweb. Los servicios web pueden ser publicados, localizados e invocados a travs de la web: Losestndaresrequeridosparahacerestoson: o SimpleObjectAccessProtocol(SOAP),tambinconocidocomoprotocolodela arquitecturaorientadaaservicios,esunRPCbasadoenXMLyunprotocolode mensajera. o Web Service Description Language (WSDL), es una interfaz descriptiva y un protocolodelenguajeobligatorio. o Universal Description, Discovery, and Integration (UDDI), un mecanismo de registroquesepuedeusarparabuscardescripcionesdeserviciosweb. Los servicios web son interoperables e independientes del lenguaje: La interaccin entre un proveedor de servicio y un solicitante del servicio est diseado para ser completamente independiente del lenguaje y la plataforma. Esta interaccin requiere un documento WSDL para definir la interface y describir el servicio, junto con el protocolo de red (generalmente HTTP). La inter operatibilidad se da, porque el proveedor del servicio y solicitante del servicio no tiene idea de que plataforma o lenguajeestusandoelotro. Los servicios web son intrinsecamente abiertos y basados en estndares: XML y HTTP son los fundamentos tcnicos para los servicios web. Una gran parte de la tecnologa de los servicios web se ha construido usando proyectos open source. Por lo tanto la independenciadelvendedorylainteroperatibilidadsonmetasrealistas. Los servicios web son dinmicos: Los ebusiness dinmicos pueden convertirse en una realidad usando servicios web, porque con UDDI y WSDL, la descripcin y descubrimientodelosservicioswebpuedenserautomatizados. Los servicios web son componibles: Servicios web simples pueden ser agregados a otros ms complejos usando tcnicas de workflow o llamadas a servicios web de ms bajoniveldeunserviciowebimplementado.
1.3.
BENEFICIOS
J.McGovernet.al.[5]indicaquelosbeneficiosdelosservicioswebenunaempresason: La reusabilidad: La promesa de reutilizar aplicaciones heredadas, base de datos, objetos, y componentes en gran parte no se ha realizado. Los servicios web pueden jugar un rol significativo en mejorar la reusabilidad del software dentro de las organizaciones. Los servicios web pueden envolver aplicaciones heredadas, base de datos, objetos y componentes y exponerlos como servicios reutilizables. La probabilidadquelosservicioswebmejorenlareusabilidaddependedevariosfactores como:interoperatibilidad,modularidad,registrocentralydependenciasdetiempode compilacin reducido. La tecnologa interoperable mejora la reutilizacin. Por ejemplo, si es difcil para una aplicacin conectarse a y utilizar un componente, es pocoprobablequeelcomponenteseareutilizado.Losservicioswebseconstruyencon estndares abiertos, interoperables y ubicuos que maximizan su potencial para la reutilizacin. La creacin de una capa de servicios robusto mejora la reusabilidad, que conduceaunmejorretornodelainversin. EdwinValenciaCastillo
Localizacin transparente: Un entorno de servicios alcanzara una localizacin transparenteporquelalocalizacinsealmacenaenunregistro.Unclienteencuentray fija un servicio y sin importar donde se localiza el servicio. Por lo tanto, una organizacin tiene la flexibilidad para mover sus servicios a diferentes maquinas o mover un servicio a un proveedor externo. Es tambin posible mover cdigo de una plataforma a otra. La arquitectura orientada a servicios requiere que esos servicios soporten un contrato de publicacin. La forma que un servicio es implementado es irrelevante, por lo tanto, si llega a ser necesario mover un servicio de la plataforma J2EE a .Net, ningn cambio en los clientes es necesario. "Envolver y sustituir" es un patrn comn en un entorno orientado a servicios. Proporciona a la organizacin la flexibilidad para habilitar servicios en sistemas heredados sin perder la capacidad de los sistemas. Un sistema heredado habilitado por servicios puede sustituir un Nuevo componenteosistemasinrequerircambiosenelclientequeusaeseservicio. Composicin:Losdesarrolladoresensamblanaplicacionesdeuncatalogopreexistente de servicios reusables. Los servicios no dependen de ninguna aplicacin, porque los servicios son independientes, los desarrolladores usaran esos servicios en muchas aplicaciones. El proceso de diseo de interfaces promueve el diseo de interfaces modulares e independientes de la aplicacin para las cual fue diseada inicialmente. Las interfaces diseadas apropiadamente y la creacin de componentes independientespermitirmaximizarestepotencial. Escalabilidad y Disponibilidad: Un sistema es escalable si la inversin requerida para agregar ms poder de computo es menores que los beneficios adicionales proporcionados. Porque los clientes de un servicio conocen solamente acerca de la interfaz del servicio y no su implementacin, cambiar la implementacin para hacerla masescalableydisponiblerequierepocainversin. Mantienen la inversin en aplicaciones heredadas: Los servicios ayudan a mantener la inversin en aplicaciones heredadas porque estos especifican solo el mtodo de interaccin, y no el mtodo de implementacin. Los sistemas heredados pueden ser envueltos en un servicio facade. Este mtodo de crear servicios tiene la ventaja que permitenalasorganizacionesreemplazaraplicacionesheredadassincambiarlaforma enquelosclientesaccedenalservicio. Reducida dependencia del vendedor: Mientras la plataforma usada para construir aplicaciones soporte estndares de servicios web, el consumidor del servicio es irrelevante.Losservicioswebpermitenquelasorganizacionestomendecisionessobre queplataformausar,basadoenlosmeritosdelaplataformamsqueenelproveedor. Los servicios web representan un cambio importante de poder, del vendedor de hardwareysoftwarealconsumidordehardwareysoftware.
1.4.
ELEMENTOS
Los autores de [6] y [1], indican que un servicio web es ms una idea, un concepto cuya implementacin debe respetar una serie de reglas e interfaces para poder ser accedido por cualquier sistema conectado a la red, siempre que disponga de permiso para ello. Fuera de toda implementacin, como hemos dicho, existen una serie de partes bien
diferenciadas que tenemos que tener en cuenta a la hora de implementar y utilizar un servicio web. Estas son los agentes y los servicios, el cliente y el proveedor, la descripcin delservicio,lasemntica,yporltimolaspersonas,lasemnticaylosagentes. Agentes y Servicios: Un servicio web, constituye una idea o concepto que debe ser implementado por algn agente. El agente es un trozo o pieza de software que implementa esa funcionalidad que realiza el SW. Este agente tiene la peculiaridad de estar capacitado para enviar y recibir mensajes. De esto se desprende, que el agente eselencargadoderecibirlaspeticionesyenviarlasrespuestas.Sinembargo,elSWes el conjunto abstracto de funcionalidades ofrecidas. El agente ser escrito usando algn lenguaje de programacin y se ejecutar bajo una plataforma en concreto. Podemos variar este agente segn la implementacin que deseemos o necesitemos darle. Sin embargo, el SW que implemente el agente ser siempre el mismo, es decir, seacualsealaimplementacinquedemosaunagenteparaunSWdeterminado,este ltimosersemnticamentesiempreelmismo,loquevariarserelagente. El cliente y el proveedor: El SW pertenece a un propietario que puede ser bien una persona, bien una organizacin. La entidad proveedora ser la persona u organizacin que desarrolle un agente capaz de soportar un determinado servicio. La entidad que realizalaconsultapuedesertambinunapersonauorganizacinquedeseahaceruso del servicio que expone la entidad proveedora. Esta comunicacin tipo peticin respuesta se realiza entre agentes, ya que en el lado del que consulta tambin hay implementado un agente que se comunica con el agente de la entidad proveedora, que es el que implementa el servicio o el conjunto de servicios. Para que la comunicacin se lleve a cabo de manera correcta, las entidades participantes deben ponerse de acuerdo, tanto en la semntica como en los mecanismos utilizados en el intercambiodemensajes. Descripcin del Servicio: El intercambio de mensajes entre las entidades est guiado porunprotocoloquestasdebenseguirparaquelastransaccioneslleguenabuenfin. Este protocolo est documentado en la descripcin del SW (WSD, Web Service Description). La WSD es una descripcin completa del SW, escrito en un lenguaje denominado WSDL[7], y que es inteligible tanto por las mquinas como por las personas, aunque no sin cierta dificultad para estos ltimos. En esta descripcin se incluyentodosloselementosdeunSWsusceptiblesdeserdescritos,talycomosonel formato de los mensajes, los tipos de datos, los protocolos de transporte a travs de los cuales el servicio est disponible y los distintos formatos de serializacin utilizados para enviar el contenido de los mensajes entre los agentes que llevan a cabo esta comunicacin. En esta descripcin, tambin se pueden incluir una o varias direcciones o localizaciones de red o endpoints, mediante las cuales podremos invocar al agente proveedor o podemos obtener informacin acerca del patrn de comunicacin que hayseguir. Semnticas:DefiniremossemnticadeunSWcomoelcomportamientoqueseespera quetengaelmismo.Estecomportamiento,serefiereaquesperamosdelSWcuando leenviamosunmensajedepeticin.Delamismaformaquelasintaxisdeunobjetoes suestructura,lasemnticadeunobjetosereflejaenlasrelacionesquesteestablece con otros objetos. Mientas que en la sintaxis identificamos diferentes partes, en la semntica identificamos distintos contextos. Esta semntica tambin puede verse como un contrato entre la entidad que realiza la consulta y la entidad a la que va dirigida la consulta. Este contrato supone un total acuerdo entre las dos entidades, y
trata sobre cmo y porqu los agentes que intervienen en la comunicacin debern interactuar. Este acuerdo puede ser explcito o implcito, oral o escrito, inteligible por lamquinaoporlaspersonas. Personas,agentes y semnticas: Uno de los propsitos principales de los SW, es el de automatizar procesos que de lo contrario deberan ser llevados a cabo manualmente. El papel que tienen las personas en el uso y en la arquitectura de los SW se puede se puedeverendosaspectos: Las personas deben estar de acuerdo en la semntica y en la descripcin del servicio. Los usuarios de los SW debern estar implcitos o explcitamente de acuerdo con la semntica y la descripcin del servicio al cual dirige las peticiones, y con el que realizan la interaccin, mientras que este servicio pertenezca a una persona u organizacin. La entidad proveedora publicar la semnticayladescripcindesuserviciocomouncontratodeltipoolotomas o lo dejas, que tendr que ser aceptado por la entidad que contrate el servicio. Son las personas las que crean los agentes que intervienen en la comunicacin, el agente proveedor y el agente que realiza la peticin. Los creadores de los agentes deben asegurar que estos cumplen la semntica y la descripcindelservicio.Hayvariasformasdeasegurarestoltimo: a. Un agente puede ser codificado, de manera que permanentemente implementelasemnticayladescripcindeunservicio. b. Podemos codificar el agente, de una manera ms general, de forma que dinmicamente le pasemos la descripcin y/o la semntica del servicio deseadoenesemomento. c. Podemos crear en primer lugar el agente, y luego generar la descripcin y/olasemnticadelserviciodespus,apartirdelcdigodelagente. En la Figura 2. Se presenta un resumen donde se pueden observar la relacin de los elementoscitadosanteriormente.
Figura2.Elementosdelosserviciosweb[6] Como se puede ver, la entidad proveedora y la que realiza la peticin, se ponen de acuerdo respecto a la descripcin del servicio (mediante un documento en WSDL) y la semntica que guiarn la interaccin entre los agentes. Cada uno de los agentes, implementa la semntica del servicio, pero desde el punto de vista que le corresponde, es decir, desde el punto de vista del proveedor o del consumidor (el que realiza la peticin). Ambos agentes (el solicitante y el proveedor) intercambian mensajes SOAP en nombre de losrespectivospropietarios.
II.
ARQUITECTURADESERVICIOSWEB
La arquitectura de los servicios Web permite que ciertos servicios sean dinmicamente descritos, publicados, descubiertos e invocados en un ambiente de computacin distribuida, haciendo uso de los estndares WSDL, UDDI, SOAP y XML respectivamente, permitiendo a los desarrolladores implementar aplicaciones distribuidas, utilizando herramientas muy distintas (heterogneas) para crear aplicaciones que utilizan una combinacin de mdulos de software que son llamados desde diversos sistemas distribuidosenregionesgeogrficasdistintas. LosserviciosWebsonaplicacionesautocontenidasymodularesquepuedenser: Descritas mediante un lenguaje de descripcin de servicio, como el lenguaje WSDL (WebServiceDescriptionLanguage).[8]
10
Publicadas, al incluir las descripciones y polticas de uso en algn registro conocido, utilizando el mtodo de registro UDDI (Universal Description, Discovery and Integration).[9] Encontradas, tambin utilizando el estndar UDDI, al enviar peticiones al registro y recibir los detalles necesarios para la localizacin y enlace (binding) sobre aquel servicioqueseajustaalosparmetrosdelabsqueda. Asociadas, al utilizar la informacin contenida en la descripcin del servicio para crear unainstanciadeserviciodisponible(oProxy). Invocadassobrelared,alutilizarlainformacincontenidaenlosdetallesdeenlacede la descripcin del servicio; en un documento WSDL. Durante la invocacin, como veremosmsadelanteharemosusodelprotocoloSOAP.[10] Compuestasconotrosserviciosparaintegrarserviciosyaplicacionesnuevas,enloque constituirlabasedeSOA(ServiceOrientedArchitecture).
Todos los estndares comentados se basan en XML: los documentos WSDL, son documentos XML; el protocolo SOAP, que permite la comunicacin entre servicios, internamentetratainformacinXMLensusdosvariantes,porunladolamensajeraSOAP, tratando informacin XML explcita y por otro lado RPC, que la trata, pero de una manera implcita.
2.1.
COMPONENTESDELAARQUITECTURA
Loscomponentesqueconformanlaarquitecturadeservicioswebson: 2.1.1. Servicio La aplicacin es publicada para que sea utilizada por todos aquellos solicitantes que cumplan los requisitos especificados por el proveedor de servicios. Evidentemente la implementacin se realizar sobre una plataforma accesible en la red. El servicio se describe a travs del lenguaje de descripcin de servicios, WSDL. Tanto la descripcin como las polticas de uso han sido publicadas anteriormenteenunregistro. 2.1.2. ProveedordeServicio Desde el punto de vista comercial, es quien presta el servicio. Desde el punto de vistadelaarquitectura,eslaplataformaqueproveeelservicio. 2.1.3. RegistrodeServicios Es un repositorio de descripciones, donde los proveedores publican sus servicios y la forma de accederlos. Permitir adems a los solicitantes realizar distintos tipos de bsquedas, obteniendo de stas, los detalles necesarios para poder localizarlos yutilizarlos. 2.1.4. SolicitantedeServicios Desde el punto de vista comercial, la empresa que requiere cierto servicio. Desde el punto de vista de la arquitectura, la aplicacin cliente que busca e invoca un servicio.
11
2.2.
OPERACIONESDELAARQUITECTURA
LasoperacionesquesepuedenrealizarconlosserviciosWeb,sonlassiguientes: 2.2.1. Publicar/Cancelar Un proveedor de servicios podra publicar un determinado servicio comercial (e business) a uno o ms registros de servicios, adems de, evidentemente, cancelar dichapublicacinenunmomentodado. 2.2.2. Buscar Lossolicitantesdeservicios(clientes)podrninteractuarconunoomsregistros paradescubrirunconjuntodeservicioscomercialesconlosquepuedan interactuarparaencontrarunasolucinasusproblemas. 2.2.3. Enlazar(Bind) Los solicitantes de servicios negocian con los proveedores la forma de acceder e invocarasusservicioscomerciales(ebusiness). Como se comento, un servicio Web es una coleccin de funciones que son presentadas como una sola entidad y que es anunciada en la red para ser usada por otros programas. Sonporlotanto,bloquesdeconstruccinparacrearsistemasdistribuidosabiertos. En la figura 3 podemos observar la relacin existente entre los componentes y las operacionesdelaarquitectura.
Figura3.Relacionesentreloscomponentesqueconformanlaarquitectura deserviciosWeb Actualmente, las aplicaciones que se estn realizando, poseen la capacidad de buscar y seleccionar servicios dinmicamente en tiempo real, basndose en parmetros como el costo, la calidad, o la disponibilidad. Esto supone una gran ventaja a la hora de utilizar sistemas basados en servicios Web, ya que el sistema, de forma automtica, elegir el servicio que ms se ajuste a sus necesidades, y por lo tanto el rendimiento del sistema se verincrementado.
12
2.3.
MODELOSARQUITECTONICOS
El W3C Web Service Architecture Working Group[1] definen modelos arquitectnicos como subconjunto coherente de la arquitectura que se centra bsicamente en un aspecto concreto dentro de la arquitectura. Cada modelo intenta explicar al mximo el aspecto en elquesehacentrado.Unmodelotambindebedefinirtodaslasdependenciasquepueda presentar con respecto a otros aspectos incluidos en la arquitectura dentro de la cual se ubica. En la Figura 6 mostramos las relaciones existentes entre los distintos modelos medianteunarepresentacingrficadelosmismos.
Figura4.Metamodelodelaarquitecturadeserviciosweb[1] 2.3.1. ElModeloorientadoamensajes Este modelo se enfoca en aquellos aspectos relacionados con los mensajes, su estructura, el mtodo de transporte, etc. Este modelo no atiende ni al porqu de los mensajes ni a su significado. El inters principal de este modelo se sita en la estructura de los mensajes, las relaciones existentes entre los que envan los mensajes, los que los reciben y otros intermediarios que tengan que procesar tambin los mensajes para reenviarlos. Relacionados con los mensajes, hay una serie de conceptos que resultan interesantes dentro de la arquitectura y que este modelo comenta, mostrando cual es la relacin que guardan unos conceptos con otros,aunquelaprofundidadcon que debeser tratadoseescapaalaprofundidad conlaquetrataremoslacuestin.
13
Figura5.Modeloorientadoamensajes[1] 2.3.2. ElModeloorientadoaservicios Estemodelosecentraenaspectosdelaarquitecturarelacionadosconlosservicios y las acciones principalmente. El propsito principal de este modelo es explicar las relaciones existentes entre un agente, los servicios que ofrece o implementa y los solicitantes de los servicios. Como es lgico, un agente no podra llevar a cabo la tareadeofrecerserviciosalosclientessinotuvieralacapacidaddeenviaryrecibir mensajes, pero este modelo no hace referencia los mensajes o al mtodo de transporte de los mismos. El Modelo Orientado a Servicio se construye sobre el Modelo Orientado a Mensajes, pero centrndose en las acciones en lugar de los mensajes. En la figura 8 se muestran algunos conceptos relacionados con este modeloylasrelacionesexistentesentreellos.
Figura6.Modeloorientadoaservicios[1]
2.3.3. Modeloorientadoarecursos Estemodelosecentraenaquellosaspectosdelaarquitecturarelacionadosconlos recursosyelmodelodeservicioasociadoconlamanipulacindelosmismos. El Modelo Orientado a Recursos se construye sobre el Modelo Orientado a Servicios, principalmente por el desarrollo del modelo de servicio asociado al recurso y el conjunto de acciones para su manipulacin. La funcin principal de esta parte de la arquitectura es explicar la Web en s, y cmo se relaciona con los servicios web. Este modelo intenta explicar esto ltimo mostrando como un los recursos son un concepto independiente, y como la manipulacin de stos son solamente una instancia del Modelo de Servicios, slo que con sus propios servicios y acciones sobre los recursos. A continuacin en la figura 9, se muestran algunos conceptos relacionados con este modelo y las relaciones existentes entre ellos.
14
Figura7.Modeloorientadoarecursos[1]
2.3.4. ModelodePolticas Estemodelosecentraenaquellosaspectosdelaarquitecturarelacionadosconlas polticas, y por extensin, con la seguridad y la calidad del servicio. El concepto de poltica es muy simple, es simplemente una restriccin sobre el comportamiento de los agentes y los servicios. La seguridad, es bsicamente un conjunto de restricciones respecto del comportamiento de las acciones y del acceso a los recursos.De manerasimilar,lacalidad seconsidera tambinun tipoderestriccin que puede ser aplicada a los servicios. En el Modelo de Polticas, estas restricciones se modelan alrededor de los conceptos de poltica y sus relaciones con otros elementos de la arquitectura, por ello, el Modelo de Polticas resulta ser un marco de trabajo en el que implementar la seguridad. Sin embargo, existen muchos otros tipos de restricciones y polticas relevantes a los SW, incluyendo restriccionesaniveldeaplicacin.
Figura8.ModelodePolticas[1]
15
III.
ESTANDARESYESPECIFICACIONESRELACIONADOSCONLOS SERVICIOSWEB
En la actualidad existen organizaciones relacionadas con la definicin de estndares y especificaciones, estas se encuentran en constante trabajo, buscando que los servicios web sean cada vez ms interoperables y seguros. Una breve descripcin de estas organizaciones,obtenidade[11]sedetallaacontinuacin: WebServicesInteroperabilityOrganization(WSI),Esunaorganizacindeindustria abiertaquebuscapromoverlainteroperatibilidaddelosservicioswebentreplataformas, sistemasoperativosylenguajesdeprogramacin. La comunidad agrupa organizaciones lderes en el desarrollo servicios web que ayudan a desarrollar servicios web interoperables proporcionando direccin, practicas recomendadas y soporte de recursos. Especficamente, WSI crea, promueve y apoya protocolos genricos para el intercambio interoperable de mensajes entre los servicios web. World Wide Web Consortium (W3C) fue creada en octubre de 2004 para dirigir el World Wide Web desarrollando protocolos comunes que promuevan su evolucin y aseguren su interoperabilidad. El W3C esta conformado por mas de 350 organizaciones de todo el mundoyhaganadoreconocimientointernacionalporsuscontribucionesalcrecimientode la web. El W3C esta diseando la infraestructura, y definiendo la arquitectura y las tecnologasbaseparalosserviciosweb. Internet Engineering Task Force (IETF) Es una gran comunidad internacional abierta de diseadores de red, operadores, vendedores e investigadores referidos con la evolucin delaarquitecturadeinternetysuoperacin. Organization for the Advancement of Structured Information Standards (OASIS) Es un consorcio internacional sin fines de lucro que conduce el desarrollo, convergencia y adopcinde estndaresebusiness.El consorcioproduce msestndaresdeserviciosweb que cualquier otra organizacin junto con estndares para seguridad, ebusiness, y esfuerzos de estandarizacin en el sector pblico y mercados de aplicacin especifica. Fundado en 1993, OASIS tiene ms de 4000 participantes, representando a ms de 600 organizacionesymiembrosindividualesen100pases. Acontinuacinsemuestraelncleodeestndaresparalosserviciosweb.Laseparacin entrecapasindicalasdependenciasaproximadasentreestas.
16
Figura9.Piladeserviciosweb[1]
Comunications transporte: La especificacin de los estndares de servicios web (SOAP y WSDL es esencialmente independiente del medio de transporte. La interoperabilidad garantiza a HTTP como protocolo usado para transmitir mensajes SOAP, lo que no quita que se pueda utilizar cualquier otro protocolo para la mensajera. Mensajera: SOAP est en el ncleo de la capa de la mensajera en los servicios web. SOAP define un modelo de codificacin extensible, basado en XML. La importancia de SOAP es que brinda el marco para construir la operabilidad on the wire en tiempo de ejecucin. La capa de mensajera tambin est diseado para convivir con otros protocolosdemensajeranoXML Descripciones: Al ser dbilmente acoplado, el modelo orientado a servicios requiere que se expliciten las capacidades y los requisitos del servicio ofrecido. Se da soporte a la descripcin de servicios en dos niveles. La definicin funcional (qu hace el servicio) en la forma de lenguaje de definicin de interfaces (basado en XML) lo proporciona WSDL. ste describe los protocolos especficos de transporte y el modelo de mensajera a utilizar para interactuar con el mismo. Las descripciones sobre los requisitos de calidad del servicio (Como se utiliza el servicio) se ofrecen en forma de "polticas de servicio web", codificando informacin tal como los requisitos de seguridad del servicio, los protocolos fiables de mensajera a seguir o los requisitos de privacidad. La especificacin WSPolicy define un lenguaje simple para codificar estos requisitos. Procesos:EstacapaincluyeprocesostalescomoeldeDescubrimiento,lacoordinacin y la negociacin de la interaccin. El primero nos brinda la capacidad de descubrir dinmicamente nuestros servicios web, de vincularlos y de interactuar con ellos. La especificacin UDDI (Universal Description, Discovery and Integration) define el servicio y permite el descubrimiento de servicios basados en su funcin y capacidades declaradas,pudindose,enlosentornosmsdinmicos,definir contratosque regulen la interaccin entre dos socios de servicios respecto a caractersticas de la prestacin del servicio, consideraciones financieras, legales, etc. Esto se puede especificar en un EdwinValenciaCastillo
17
formato legible por la mquina. La capacidad de negociar estos contratos dinmicamente ser de vital importancia para llevar a cabo la visin completa del paradigmadelaorientacinaservicios. Asimismoen[3],podemosencontrarunarepresentacingraficayagrupacindetodoslos estndaresyespecificaciones.
Figura10.Estndaresyespecificacionesrelacionadosalosserviciosweb[3] La agrupacin de estos estndares, las cuales se obtuvieron de [3] y [11] , se describe a continuacin: Transporte BEEP, el protocolo extensible de intercambio de bloques (Blocks Extensible Exchange Protocol BEEP), referido generalmente como BXXP, es un framework para construir protocolos de aplicacin. Ha sido estandarizado por el IETF (Internet Engineering Task Force)yesparalosprotocolosdeinternetcomoXMLloesparalosdatos. Mensajes Estas especificaciones y estndares de mensajes intentan proporcionar un framework paraelintercambiodeinformacinenunentornodistribuidoydescentralizado. SOAP1.1(Note) SOAP1.2(Specification) WebServicesAddressing WebServicesNotification(WSBrokeredNotification,WSBaseNotification,WSTopics WebServicesAttachmentsProfile1.0 MTOMSerializationPolicyAssertion(WSMTOMPolicy)Version1.0 Descripcinydescubrimiento Los servicios web son significativos solo si los usuarios potenciales pueden encontrar informacin suficiente para permitir su ejecucin. El enfoque de estos estndares y especificacionesesladefinicindeunconjuntodeserviciosqueapoyenladescripcin y descubrimiento de los negocios, organizaciones y otros proveedores de servicios web; los servicios web que hacen disponibles y las interfaces tcnicas que se pueden utilizarparateneraccesoaestosservicios. UDDI3.0 WSDL1.1(Note) WSDL1.2(Workingdraft)
18
WSDL2.0(WorkingGroup) WebServicesSemanticsWSDLS WebServicesMetadataExchange WebServicesPolicyAssertionsLanguage WebServicesPolicyAttachment WebServicesPolicyFramework WebServicesResourceFramework Confiabilidad No es posible solucionar aspectos del negocio si los participantes no pueden estar seguros de la culminacin exitosa del intercambio de mensajes. La mensajera confiable que permite que los mensajes sean entregados confiablemente entre aplicaciones distribuidas en presencia de componentes software, sistemas o fallas de lared,esporlotantocriticoenlosserviciosweb. WebServicesReliableMessaging WSRMPolicyAssertion Transacciones Las transacciones son un concepto fundamental en la construccin de aplicaciones distribuidas confiables. Un entorno de servicios web requiere un comportamiento de coordinacin proporcionado por un mecanismo de transaccin tradicional para controlarlasoperacionesyelresultadodeunaaplicacin. WebServicesAtomicTransaction WebServicesBusinessActivity WebServicesCoordination Seguridad Usando estas especificaciones de seguridad, las aplicaciones pueden garantizar una comunicacin segura diseada para trabajar con un framework de servicios web en general. WebServicesFederationLanguage WSFederation:ActiveRequesterProfile WSFederation:PassiveRequesterProfile WebServicesProvisioning WebServicesSecureConversationLanguage WebServicesSecurity1.0 WebServicesSecurityAddendum WSSecurityKerberosBinding WebServicesSecurityPolicy WebServicesTrust SecurityAssertionMarkupLanguage(SAML) Procesosdenegocio Un proceso de negocio especifica un orden de ejecucin potencial de operaciones de una coleccin de servicios web, los datos compartidos entre estos servicios web, que socios estn involucrados y como ellos estn involucrados en el proceso del negocio, junto con el manejo de excepciones para las colecciones de servicios web y otros EdwinValenciaCastillo
19
aspectos involucrados como servicios mltiples y organizaciones participantes. BPEL especificaelprocesodenegocioycomolosservicioswebserelacionan. WSBPELExtensionforPeople BusinessProcessExecutionLanguageforWebServicesV1.1 Administracin La administracin de servicios web es definida como un conjunto de capacidades para descubrir la existencia, disponibilidad, funcionalidad, rendimiento, uso, asi como el control y configuracin de un servicio web con la arquitectura de servicios web. Pues losserviciosweblleganinfluyentesycrticosparalaoperacindelnegocio,latareade administrarloseimplementarlosesimperativaalxitodelasoperacionesdelnegocio. WebServicesDistributedManagement WebServicesManageability WebServicesManageabilityConcepts WebServicesManageabilityRepresentation WSResourceTransfer WebServicesServiceRegistryandRepository
Enlasiguientefigurasepresentatodoslosestndaresyespecificacionessegn[11]
FiguraNo.11.Piladeestndaresyespecificacionesdelosserviciosweb[11]
20
Enlosprrafossiguientespresentaremosunbreveresumendelosprincipalesestndares yespecificacionesdelosservicioswebysusaspectosprincipales.
3.1.
SOAP(SimpleObjectAccessProtocol)
El estndar SOAP (en su versin actual 1.2, recomendado por W3C en su segunda edicin enel2007[10])defineunprotocoloquedasoportealainteraccin(datos+funcionalidad) entre aplicaciones en entornos distribuidos y heterogneos, y es interoperable, es decir, neutral a la plataforma, lenguajes de programacin, independiente del hardware y protocolos. Funciona sobre la infraestructura (estndares) existentes en Internet. SOAP define cmo organizar la informacin XML de una manera estructurada y tipada para intercambiarla entre los distintos sistemas. El protocolo SOAP simplifica el acceso a los objetos, permitiendo a las aplicaciones invocar mtodos de objetos o funciones, que residenensistemasremotos. En [12] se indica que SOAP es fundamentalmente un paradigma de intercambio de mensajes en un slo sentido, sin estado, pero las aplicaciones pueden crear patrones de interaccin ms complejos (por ejemplo, peticin/respuesta, peticin/respuestas mltiples, etc.) combinando tales intercambios de un solo sentido con caractersticas proporcionadas por el protocolo utilizado y/o informacin especfica de la aplicacin en cuestin. SOAP no interfiere en la semntica de cualesquiera datos especficos de aplicacinquecomunica,nitampocoenasuntostalescomoenenrutamientodemensajes SOAP, transferencia de datos fiables, cortafuegos que atraviesa, etc. No obstante, SOAP proporciona el marco de trabajo por el que la informacin de aplicaciones especficas puede comunicarse de forma extensible. Tambin, SOAP proporciona una descripcin completadelasaccionesquedeberealizarunnodoSOAPalrecibirunmensajeSOAP. En[13],detallaqueSOAPespecifica: Un formato de mensaje para una comunidad unidireccional, describiendo cmo se empaquetalainformacinendocumentosXML. Un conjunto de convenciones para usar mensajes SOAP, para implementar el patrn de interaccin RPC, definiendo cmo los clientes pueden invocar un procedimiento remoto enviando un mensaje SOAP y cmo los servicios pueden responder enviando otromensajealllamador. Un conjunto de reglas que una entidad que procesa mensajes SOAP debe seguir, definiendo en particular los elementos XML que una entidad debe leer y entender, as como las acciones que deben tomar si no entienden el contenido (reglas de codificacindedatos). Una descripcin de cmo se debe transportar un mensaje SOAP sobre HTTP y SNMP. Se definirn bindings a otros protocolos de transporte en futuras versiones de la especificacin. LosmensajesSOAPsonfundamentalmentemensajesenunadireccin, desde unemisor (cliente) hacia un receptor (servidor), y las comunicaciones son del tipo request/response. Todos los mensajes son documentos XML con su propio esquema, que incluyesuspropiosespaciosdenombres(namespaces),elementosyatributos.
21
SOAP define dos namespaces: envelope y encoding. Como caracterstica destacable, podemos decir que no puede tener DTD asociados. Los mensajes SOAP constan de tres secciones(verfigura4):envelope,headerybody. Envelope (envoltura): Es el elemento raz del mensaje para describir su contenido y la formadeprocesarlo. Header(encabezado):informacindeidentificacindelcontenido. Body(cuerpo):eselcontenidodelmensaje.
Figura12.SeccionesdeunmensajeSOAP Se pueden realizar extensiones al protocolo; esto es posible gracias a la adiccin de mdulos de funcionalidad. Este enfoque permite a los desarrolladores usar los mdulos y funcionalidades que necesiten, sin la necesidad de tener que implementar la totalidad de estos. En pocas palabras, el protocolo puede ser extensible. Algunas de las extensiones msimportantesquesepuedenrealizarsonlasquesemuestranacontinuacin: Attachments: Hace referencia a la posibilidad de incluir un documento no XML, o archivo binario, enviar documentos de fax, imgenes de medicina, dibujos de ingeniera,ocualquierotrotipodeimgenes,codificadasenBase64. Routing/Intermediaries: Relacionadas con el proceso de encaminar mensajes SOAP a travs de intermediarios. Este mecanismo ofrece la posibilidad de agregar varios servicios Web y ofrecerlos como parte de un paquete. Esto es una tarea que permite hacer los servicios Web escalables a travs del direccionamiento, incluso, hacia mltiplesservidores. Reliable Messaging: Determina cuanto tiempo espera un servidor cuando enva un mensajeyesperaporlarespuesta. Security: Esta extensin nos permitir dar un marco de seguridad a la comunicacin. Algunos de los aspectos podran ser aplicar SSL, firma digital, etc. Mediante XML Signature podemos proporcionar integridad, autenticacin de mensajes, y/o servicios deautenticacindefirmas. Quality of Service (QoS): Es una medida para calificar la calidad del servicio, determinandolausabilidadyutilidaddelservicio. Context/Privacy:Referenciaalosmecanismosparaguardarelcontextoylaprivacidad delentornodelosusuarios.
22
Transaction Support: Permite que un grupo de operaciones o acciones se comporten comosifueranunasimpleunidad(otodofallaotodoesunxito). EncuantoalrendimientodelosmensajesdeSOAPutilizandoHTTPyXML,comparadocon elrendimientodemensajesbinariosutilizadosporCORBA,DCOMyRMI,sepuedeafirmar que en el caso de los ltimos, tanto el destinatario y remitente tienen conocimiento completodelcontenidodelmensajey nocodifican metainformacincomolosnombreso tipo de argumentos. Quizs este mtodo sea eficiente, pero dificulta a los intermediarios elprocesamientodemensajes.Ydebidoaquecadasistemautilizaunacodificacinbinaria distinta,dificultalaconstruccindesistemasinteroperables. Dado que SOAP utiliza XML para codificar mensajes, es relativamente sencillo procesar los mensajes en cada paso del proceso de llamada. Adems, la facilidad de depuracin de mensajesSOAPpermitelaconvergenciarpidadelasdiversasimplementacionesdeSOAP, locualesimportanteenlainteroperabilidadagranescala.
3.2.
WSDL(WebServiceDescriptionLanguage)
El WSDL (Web Service Description Language)[8], creado originalmente por IBM, Microsoft y Ariba. Tiene un rol y un propsito similar al de los IDL (Interface Definition Language) de las plataformas middleware es decir, ofrecer un software de conectividad que permite ofrecer un conjunto de servicios que hacen posible el funcionamiento de aplicaciones distribuidassobreplataformasheterogneas.UnarchivoWSDLesundocumentoXMLque describe los servicios Web, en particular sus interfaces. Como caracterstica que lo diferencia de los IDL, es que WSDL debe definir los mecanismos de acceso (protocolos) a los servicios Web. Otra caracterstica diferenciadora es la necesidad de definir (en la especificacin) la localizacin del servicio (puntos finales). La separacin de interfaces y enlaces de protocolos, y la necesidad de incluir informacin de localizacin permite la definicin de especificaciones modulares. WSDL permite definir interfaces ms complejas y expresivas; permitiendo definiciones de interacciones asncronas y diferentes paradigmasdeinteraccin,ylaposibilidaddecombinaroagruparoperaciones.Enlafigura 3, se muestra un diagrama con la arquitectura de los sistemas basados en servicios Web, enelqueserepresentanlosestndaresdescritos. WSDLesunformatoXMLquedescribelosserviciosderedcomounconjuntodeendpoints queprocesanmensajescontenedoresdeinformacinorientadatantoadocumentoscomo a procedimientos. Las operaciones y los mensajes se describen de forma abstracta, y despusseenlazanaunprotocoloderedyaunformatodemensajeconcretoparadefinir un endpoint de red. Los endpoints concretos relacionados se combinan en endpoints abstractos(servicios). El lenguaje WSDL es extensible, lo que permite la descripcin de endpoints de red y sus mensajes, independientemente de los formatos de los mensajes o protocolos de red utilizadosparacomunicarse. EldocumentoWSDLdeunservicioproporcionadospiezasde informacinbsicas:(1)una parte o interface abstracta (independiente de la aplicacin) y (2) una parte especfica, que
23
define los enlaces a protocolos e informacin de los puntos finales de acceso al servicio. Verfigura5.
Figura13EstructuradeundocumentoWSDL Laparteabstractaestcompuestapor: Definiciones de port types: anlogos a los interfaces en IDL. Cada port type es una coleccinlgicadeoperations. Operations:Cadaoperationdefineunintercambiosimpledemensajes. Message:Unmessageesunaunidaddecomunicacinquerepresentaunintercambio dedatosenunanicatransmisinlgica. Types: Un sistema de tipos (types) usados por las operations (por defecto XML Schema). Laparteespecficaestcompuestapor: Definiciones de Bindings: se especifica la codificacin de los mensajes, y los enlaces a protocolosdetodaslasoperacionesymensajesdefinidaenunporttype. Definiciones de Ports: se especifica en qu direccin (URI) se puede acceder a la implementacin del port type. Definen un punto final (lugar de la red) donde est el servicio. DefinicionesdeServices:definenunaagrupacindePorts. Esta es la forma que tiene WSDL de describir los servicios Web, en trminos de los mensajesqueaceptaygenera.Actacomocontratoentreunconsumidor(cliente)ydicho servicio. WSDL puede describir puntos finales y sus operaciones sin especificar el formato de los mensajes o los protocolos de red (SOAP, HTTPGET/POST y MIME) a los cuales el puntofinalestligado. El lenguaje de descripcin de servicios Web es, por lo tanto, el equivalente a un resumen diseadoenXML,enelcualsedescribenlosserviciosWeb,indicandodndeseubicanyla formadeinvocarlos.AcontinuacinsemuestraunejemplodedocumentoWSDL.
24
3.3.
UDDI(UniversalDescriptionDiscoveryandIntegration)
El UDDI[9], es un directorio que contiene un registro/repositorio de descripciones de serviciosWeb.Esteestndarpermitealasempresasregistrarseenuntipodedirectoriode Internet que les ayuda a anunciar sus servicios, de tal forma que el resto de compaas puedan localizar sus servicios y realizar transacciones en la Web. El proceso de registro y consultas se realiza utilizando mecanismos basados en XML y HTTP(S). Por lo tanto, la especificacin UDDI tiene dos objetivos esenciales, en primer lugar servir de soporte a los desarrolladores para encontrar informacin sobre servicios Web y poder construir clientes; y por otro lado, facilitar el enlace dinmico de servicios Web, permitiendo consultarreferenciasyaccederaserviciosdeinters. Siemprehasidounretolacomunicacinentrelosnegociosaniveldeaplicaciones,dadala enorme cantidad de plataformas, herramientas, mecanismos y procesos que cada cual utiliza. XML se presenta como la solucin para el intercambio de datos de una forma transparente. Tambin, la evolucin de protocolos como SOAP, ya comentado anteriormente, proporciona una plataforma para el intercambio de servicios sobre la red. Si el mecanismo de comunicacin entre las plataformas es el XML, y la forma de comunicacin es SOAP, la cuestin que se plantea es cmo encontrar a las organizaciones queproporcionanserviciosconlosquecomunicarse.LarespuestaeselUDDI. UDDI, aunque fue creado originalmente por IBM, Microsoft y Ariba, desde su versin 3, la organizacinOASIS[14]seencargadesumantenimiento. UDDI se concibi como un registro de negocio, es decir un servicio de directorio y un nombrado sofisticado conjuntamente. Especifica un marco para describir y descubrir servicios Web. UDDI define estructuras de datos y APIs para publicar descripciones de servicios en el registro, y mtodos de consulta para buscar descripciones publicadas. Las APIsdeUDDIestnespecificadasconWSDLyconSOAPBinding,loquepermiteaccedera ellascomoserviciosWeb. La especificacin UDDI tiene dos objetivos esenciales: (1) ser un soporte a los desarrolladores para encontrar informacin sobre servicios Web y poder construir aplicaciones clientes que los invoquen, y (2) facilitar el enlace dinmico de servicios Web, permitiendo consultar referencias y acceder a servicios de inters. La informacin en un registro UDDI se almacena en ficheros XML con una estructura jerrquica. Los elementos bsicosdeestaestructurason: BusinessEntity: Es el elemento toplevel, describe un negocio o una entidad que ha registradounservicioenUDDI. BusinessService: Describe un servicio Web que ha sido expuesto por una entidad de negocio, soporta el nombrado de un servicio Web y lo asocia con una entidad de negocioyconlainformacindebinding.Soportalaasignacindecategorasalservicio Web(industria,productos,cdigosgeogrficos,etc.). BindingTemplate: Describe la informacin tcnica necesaria para enlazar con un servicio Web en particular. Este elemento soporta el nombrado de un servicio Web y suasociacinconunaentidaddenegocioeinformacindebinding.Lainformacinde binding se describe como un punto de acceso que posee un atributo llamado UrlType utilizado para especificar los siete puntos de entrada: mailto, http, https, ftp, fax, phone,other.
25
tModel: Estructura de metadatos genrica para representar cualquier concepto o construccin (definiciones de protocolos, ficheros WSDL, XML Schemas, espacios de nombres,esquemasdecategoras,etc.).
Figura14.EstructuradedatosUDDI Conceptualmente,lainformacinproporcionadaporunaorganizacinqueofreceservicios WebenunregistroUDDIconstadetrescomponentes: Seccin Blanca: Es muy similar a la informacin que aparece en un directorio telefnico,queincluyedireccin,contactoyotrosidentificadoresconocidos. Seccin Amarilla: Es muy similar a su equivalente telefnico, e incluye categoras de catalogacin industrial tradicionales, ubicacin geogrfica, etc. Mediante el uso de cdigos y claves predeterminadas, los proveedores de servicios se pueden registrar y as facilitar a pospotenciales usuarios de sus servicios la bsqueda usando estos ndicesdeclasificacin. Seccin Verde: Contiene la informacin tcnica de los servicios ofrecidos por los proveedores. Se incluyen referencias de especificaciones de servicios Web as como informacin complementaria para los mecanismos diversos de bsqueda basados en URL.
3.4.
WSSECURITY
Esta especificacin maneja el cifrado y firmas digitales, permitiendo crear una aplicacin en la cual los mensajes no puedan ser escuchados ilegalmente y que l no repudio sea posible. Describe ampliaciones para los mensajes SOAP proporcionando calidad de proteccin con integridaddemensajes,confidencialidaddemensajesyautenticacinsimpledemensajes. La especificacin proporciona un conjunto de mecanismos para ayudar a desarrolladores de servicios web a asegurar el intercambio de mensajes SOAP. Estos mecanismos bsicos de seguridad pueden combinarse de varias formas para acomodar una variedad de modelosdeseguridadusandounavariedaddetecnologasdecifrado. Estosmodelosdeseguridadsedescribenen[15]yseresumenacontinuacin: Modelo de Seguridad de Mensajes: Especifica un modelo de seguridad de mensajes abstracto en trminos de seguridad de tokens combinado con firmas digitales para
26
proteger y autenticar mensajes SOAP. Los tokens de seguridad afirman validez y pueden ser usados para afirmar el enlace entre los secretos de autenticacin o claves ylasidentidadesdeseguridad. Proteccin de Mensajes: Proteger el contenido del mensaje de ser divulgado (confidencialidad) o modificado sin deteccin (integridad) son las principales preocupacionesdelaseguridad.Estaespecificacinproveeunmedioparaprotegerun mensaje por cifrado y/o firma digital de un cuerpo, una cabecera o cualquier combinacin de ellos (o partes de ellos). La integridad de los mensajes est provisto por una firma XML en conjunto con tokens de seguridad que aseguran que las modificaciones a mensajes sean detectados. Los mecanismos de seguridad son diseados para soportar mltiples firmas, potencialmente por mltiples actores/roles SOAPyparasonextensiblesparasoportarformatosdefirmaadicional. Demandas prdidas o invalidas: Un recipiente de mensajes debe rechazar mensajes conteniendo firmas invlidas, demandas de mensajes perdidos o mensajes que tienen valores inaceptables. Dichos mensajes son no autorizados (o malformados). Esta especificacin provee una forma flexible para que el productor de mensajes haga una demanda sobre las propiedades de seguridad asociando cero o ms tokens de seguridadconelmensaje.
Hay tres problemas principales involucrados en la seguridad del intercambio de mensajes SOAP, y los WSSecurity proveen respuestas para todo ellos, pero no directamente. Es de hecho, una especificacin que habla no sobre cmo proteger el mensaje, sino como permitiralreceptorqueconozcacmohasprotegidoelmensaje. El primer problema es identificar y autenticar el cliente. Porque hay muchas formas diferentesdecreartokensdeseguridad,WSsecuritynoespecificaunmedioenparticular, pero define algo como tokens de seguridad diferentes deben ser transferidos dentro de mensajes SOAP. Es decir, se deja al receptor conocer como extraer tokens de seguridad delmensajeparaprocesar. El segundo problema es asegurar la integridad del mensaje. WSSecurity usa firmas digitales para eso, empleando la especificacin de firmas XML mas que inventando algo nuevo. La firma XML es una recomendacin del W3C que provee un mecanismo para firmardigitalmentedocumentosXML. El tercer problema est en mantener el mensaje seguro y evitar que sea escuchado ilegalmentemientrasestaentrnsito.Unavezms,WSSecurityempleaotroestndardel W3C,elcifradoXML,queproporcionaunmecanismoparacifrardocumentosXML. WSSecurity define como agregar firmas XML y cabeceras de cifrado XML para mensajes SOAP.EnlasiguientefigurasemuestracomoseintegraWSSecurityaSOAP.
27
Figura15.WSSecurityintegradoconSOAP
3.5.
WSPOLICY
EstaespecificacinampliaelWSSecurity,permitiendodetallarmsespecficamentecmo yporquienunserviciopuedeserusado. ElframeworkWSPolicicy,esunaespecificacinquepermiteaunserviciowebtenerun conjuntodereglasquedebenserresueltas,oconsumidas.Losautoresdeclientesde servicioswebdebenentoncesestudiarlainformacindelaspolticasparaversipuedeno noadherirseaestaspolticas.As,unclientenopodraserinscritoparaacceder simplementeaunserviciowebquetengaunapolticaquerequierequetodoslos mensajesseanencriptadosofirmadosdealgunamanera. ElW3CdescribeelmodelodeSWPOLICYen[16],elcualconstade: Policy Assertion (Poltica de asercin) una poltica de asercin identifica un comportamientoquees unrequerimiento(ocapacidad) de untema,indicasemntica de dominio especifico (por ejemplo, seguridad, transacciones) y esperan ser definidas enespecificacionesseparadasydedominioespecifico. Policy Alternative (Poltica alternativa) una poltica alternativa es una construccin lgica que representa una coleccin potencialmente vaca de polticas de asercin. Una poltica sin aserciones indica sin comportamiento. Una poltica con una o ms asercionesindicacomportamientoimplicadoparaaquellasysoloaquellasaserciones. El vocabulario de una poltica alternativa es un conjunto de todos los tipos de aserciones dentro de la alternativa. El vocabulario de una poltica es un conjunto de todoslostiposdeasercionesusadosentodaslaspolticasalternativasenlapoltica. Unaasercincuyotipoespartedelvocabulariodeunapolticaperooestincluidoen unaalternativaesexplcitamenteprohibidoporlaalternativa. Las aserciones dentro de una alternativa no son ordenadas, y los aspectos como el ordenenlacualescomportamientoesaplicadoaunsujetoestnmasalldelalcance deestaespecificacin. Poltica: A nivel abstracto una poltica es una coleccin potencialmente vaca de polticas alternativas. Una poltica con cero alternativas no contiene opciones; una
28
polticaconunaomsalternativasindicaseleccinenrequerimientos(ocapacidades) dentrodelapoltica. Las alternativas no son ordenadas, y as los aspectos tales como preferencias entre alternativasenuncontextodatovanmsalldeestaespecificacin. Web services: Aplicado en el modelo de servicios web, una poltica es usada para transportar condiciones en una interaccin entre dos servicios web. La satisfaccin de aserciones en la poltica usualmente da como resultado un comportamiento que refleja estas condiciones. Tpicamente el proveedor de un servicio web expone una poltica para transportar condiciones, bajo las cuales proporciona el servicio. Un solicitantepuedeusarestapolticaparadecidirsiutilizaonoelservicio.Unsolicitante puede escoger cualquier alternativa puesto que cada una, es una configuracin vlida para la interaccin con el servicio, pero un solicitante debe escoger solo una simple alternativa para una interaccin con un servicio puesto que cada uno representa una configuracinalternativa.
3.6.
WSI
Aunquelosservicioswebsesuponefuerondiseadosparalainteroperatibilidad,enla actualidadhaybastanteflexibilidadenlasespecificaciones,yquelasinterpretaciones entrediferentesimplementacionespuedecausarproblemas.WSIproporcionaun conjuntodeestndaresyprcticasparaprevenirestosproblemas,ascomopruebas estandarizadasparaverificarsihayproblemas. Elprimerdesafoescomprenderelproblemadelainteroperatibilidadysuimportanciaen elmundodelosserviciosweb.Losservicioswebhoysonconstruidosusandounacompleja familiadetecnologasrelacionadasyestndares,quegeneranmuchasfuentesdetemas relacionadosconlainteroperatibilidad. ElWSIdefinidoenelBasicProfileVersion1.0porelWebServiceInteroperatibily Organizacin[17],consistedeunconjuntodeespecificacionesdeservicioswebno propietarios,juntoconaclaracionesyenmiendasaesasespecificacionesquepromueven lainteroperatibilidad.
3.7.
WSBPEL
EsunlenguajedecomposicindeServiciosWebOrientadoaProcesos.SebasaenWSDLy dehechounprocesoWSBPELpuedeserexpuestoatravsdesupropioWSDLyportanto ser invocado como cualquier otro Servicio Web (permitiendo la reutilizacin de los mismos). Naci como combinacin de WSFL (Web Service Flow Language de IBM, orientado a grafos y basado en el control de los links entre tareas) y XLANG (Web Services for Business Process Design de Microsoft, basado en un control de flujos con secuencias, condiciones, bucles, etc) y ha evolucionado adquiriendo lo mejor de cada uno e intentando evitar las malas prcticas de los mismos (debido a que el paradigma de utilizacin de ambos es distinto y a veces de lugar a situaciones de construccin sobrelapadas). WSBPELdefineunconjuntodetareasbsicasparalacomposicindeserviciosweb: Tareas de Invocacin (Invoke): Invocacin de operaciones oneway o request responseenunservicioweb. Tareas de Recepcin (Receive): Permite el bloqueo de un proceso a la espera de llegadadeunmensaje.
29
Tareas de Respuesta (Response): Permite enviar un mensaje en respuesta a un mensajerecibidopreviamente. TareasdeEspera(Wait):Permitelaesperaduranteuntiempodelproceso. TareasdeAsignacin(Assign):Permitecopiardatosdeunlugaraotro. TareasdeLanzamiento(Throw):Permiteindicarquehaocurridounerror. TareasdeFinalizacin(End):Permitefinalizarlaorquestacindelainstanciaencurso.
Adems, las tareas estructuradas son utilizadas para combinar las primitivas en otras ms complejas: Tareassecuenciales(sequence):Defineunordensecuencialdetareas. Tareas de decisin (switch): Permite seleccionar un camino en particular en base a unacondicin. Tareas de eleccin: Permite bloquear y esperar la llegada de un mensaje o establecer un tiempo lmite de espera (timeout). Cuando uno de los eventos ocurre, se ejecutan lastareasdesignadas. Tarea repetitiva (While): Permite repetir un grupo de tareas mientras se cumpla una determinadacondicin. Tareasparalelas:Permiteparalelizarlaejecucindeciertogrupodetareas. WSBPEL trata todos los estados como una coleccin de tipos de mensajes WSDL. Esa coleccin de mensajes que constituyen un estado es lo que se llama contenedor. Los mensajes de un contenedor pueden ser los enviados o recibidos con clientes o servicios externos; incluso los utilizados internamente por el proceso para computacin temporal delosmismos.Asimismo,lacomunicacinsedefineatravsdelosPortTypedelosWSDL. WSBPEL sostiene la idea de un contenedor para cada tarea en el flujo definido, cada uno de los cuales tiene una definicin de esquema. As, un mensaje se corresponde a un contenedor, que bsicamente es un servicio web con informacin adicional sobre como procesarlo,posiblesprecondicionesypostcondiciones. Demodogrfico,unprocesodefinidoenWSBPELtendralasiguienteforma:
Figura16ProcesoWSBPEL
30
Todos los accesos a datos y manejos de los mismos en WSBPEL es definido utilizando estndares como XPath y XSLT, adems de basarse en los contratos de servicios establecidospormediodelosWSDL. Durante la ejecucin de un proceso se pueden establecer ms de una conversacin con servicios externos, por lo que es necesario establecer mecanismos a nivel de aplicacin para corresponder los mensajes y conversaciones con las instancias de procesos que sean objetos de los mismos. Para ello, WSBPEL ofrece lo que se conoce como Correlation Sets o Grupos de Correlaciones. Estos son conjuntos de propiedades, que juntos sirven para definir una conversacin a nivel de aplicacin dentro de una instancia de proceso. Bsicamente son identificadores nicos de instancias de proceso, que permite saber en todo momento que instancia corresponde a qu mensaje recibido o enviado a travs del mismo. WSBPEL puede ser utilizado tanto para orquestacin de servicios (llamadas a procesos ejecutables; entendiendo como tal las llamadas a servicios y la especificacin de como se llevan a cabo) como para coreografa de servicios (llamadas a procesos abstractos; entendiendocomotallosmensajespblicosaintercambiarentredosomspartes). Por lo general, la implementacin de WSBPEL vara segn el fabricante y de hecho algunos lo interpretan como un Script XML que puede ser ejecutado con un motor especfico; mientras que otros lo interpretan como un lenguaje de intercambio. La ltima especificacin, la 2.0 incluye nuevas caractersticas como inicializacin de variables, transformacin XSLT de variables, acceso XPath a datos de variables, etc. Esta especificacin ha sido aprobada el 31/01/2007 por OASIS y se la documentacin de este estndarestdisponibleen[18].
IV.
RESTUNAPROPUESTAALTERNATIVAASOAP
En los ltimos aos se ha popularizado un estilo de arquitectura Software conocido como REST (Representational State Transfer). Este nuevo estilo ha supuesto una nueva opcin deestilodeusodelosServiciosWeb. Los Servicios Web basados en REST intentan emular al protocolo HTTP o protocolos similares mediante la restriccin de establecer la interfaz a un conjunto conocido de operaciones estndar (por ejemplo GET, PUT,). Por tanto, este estilo se centra ms en interactuarconrecursosconestado,queconmensajesyoperaciones. UnejemplodeutilizacindeSOAPyRESTesAmazon,quienposeeambosestilosdeusode sus servicios Web. Pero el 85% de sus clientes prefieren la interfaz REST. A pesar de la promocin que las empresas han invertido para ensalzar a SOAP, parece que es evidente quelosdesarrolladoresprefieren,enalgunoscasos,laaproximacinmssencilla,REST.
4.1.
DEFINICION
El autor de [19] indica que REST es un estilo de arquitectura de software para sistemas hipermediasdistribuidostalescomolaWeb.Eltrminofueintroducidoenlatesisdoctoral deRoyFielding[20]en2000,quienesunodelosprincipalesautoresdelaespecificacinde HTTP. En realidad, REST se refiere estrictamente a una coleccin de principios para el diseo de arquitecturas en red. Estos principios resumen como los recursos son definidos y diseccionados. El trmino frecuentemente es utilizado en el sentido de describir a cualquier interfaz que transmite datos especficos de un domino sobre HTTP sin una capa
31
adicional, como hace SOAP. Estos dos significados pueden chocar o incluso solaparse. Es posible disear un sistema software de gran tamao de acuerdo con la arquitectura propuesta por Fielding sin utilizar HTTP o sin interactuar con la Web. As como tambin es posible disear una simple interfaz XML+HTTP que no sigue los principios REST, y en cambioseguirunmodeloRPC. Cabe destacar que REST no es un estndar, ya que es tan solo un estilo de arquitectura. AunqueRESTnoesunestndar,estbasadoenlosestndaresHTTP,URL,Representacin delosrecursos(XML/HTML/GIF/JPEG/)yTiposMIME(text/xml,text/html,).
4.2.
PRINCIPIOS
Losobjetivosdeesteestilodearquitecturaselistanacontinuacin: Escalabilidad de la interaccin con los componentes. La Web ha crecido exponencialmente sin degradar su rendimiento. Una prueba de ellos es la variedad de clientes que pueden acceder a travs de la Web: estaciones de trabajo, sistemas industriales,dispositivosmviles, Generalidad de interfaces. Gracias al protocolo HTTP, cualquier cliente puede interactuar con cualquier servidor HTTP sin ninguna configuracin especial. Esto no es deltodociertoparaotrasalternativas,comoSOAPparalosServiciosWeb. Puesta en funcionamiento independiente. Este hecho es una realidad que debe tratarsecuandosetrabajaenInternet.Losclientesyservidorespuedenserpuestasen funcionamientoduranteaos.Portanto,losservidoresantiguosdebensercapacesde entenderse con clientes actuales y viceversa. Disear un protocolo que permita este tipo de caractersticas resulta muy complicado. HTTP permite la extensibilidad mediante el uso de las cabeceras, a travs de las URIs, a travs de la habilidad para crearnuevosmtodosytiposdecontenido. Compatibilidad con componentes intermedios. Los ms populares intermediaros son varios tipos de proxys para Web. Algunos de ellos, las caches, se utilizan para mejorar el rendimiento. Otros permiten reforzar las polticas de seguridad: firewalls. Y por ltimo, otro tipo importante de intermediarios, gateway, permiten encapsular sistemas no propiamente Web. Por tanto, la compatibilidad con intermediarios nos permite reducir la latencia de interaccin, reforzar la seguridad y encapsular otros sistemas.
32
REFERENCIASBIBLIOGRAFICAS
[1] [2] [3] [4] W3CWorldWideWebConsortium.(2004)."WebServicesArchitecture."Accedidoel 16/03/2008,2008,dehttp://www.w3.org/TR/2004/NOTEwsarch20040211/. W3CWorldWideWebConsortium.(2008)."GuaBrevedeServiciosWeb."Accedidoel 11/02/2008,dehttp://www.w3c.es/divulgacion/guiasbreves/ServiciosWeb. IBM.(2008)."StandardsandWebservices."Accedidoel16/03/2008,de http://www.ibm.com/developerworks/webservices/standards/. M.Endrei,J.Ang,A.Arsanjani,S.Chua,P.Comte,P.Krogdahl,M.Luo,andT.Newling, Patterns:ServiceOrientedArchitectureandWebServices:InternationalBusinessMachines CorporationRedBooks,2004. J.McGovern,S.Tyagi,M.Stevens,andS.Matthew,JavaWebServicesArchitecture.San Francisco:MorganKaufmann,2003. I.Garcia,M.Polo,F.Ruiz,andM.Piattini,Serviciosweb:UniversidaddeCastillaLa Mancha,2005. W3CWorldWideWebConsortium.(2001)."WebServiceDefinitionLanguage(WSDL)." Accedidoel29/03/2008,dehttp://www.w3.org/TR/wsdl. W3CWorldWideWebConsortium.(2007)."WebServicesDescriptionLanguage(WSDL) Version2.0Part1:CoreLanguage."Accedidoel29/03/2008,de http://www.w3.org/TR/wsdl20/. OASIS.(2004)."UDDISpecTC."Accedidoel30/3/2008,dehttp://www.oasis open.org/committees/uddispec/doc/spec/v3/uddiv3.0.220041019.htm. W3CWorldWideWebConsortium.(2007)."SOAPVersion1.2."Accedidoel30/3/2008, dehttp://www.w3.org/TR/soap/. InnoQ.(2006)."WebServicesStandards:AnoverviewoftheWebservicesstandards landscape"Accedidoel23/4/2008,dehttp://www.innoq.com/soa/wsstandards/. W3CWorldWideWebConsortium.(2003)."SOAPVersin1.2Parte0:Fundamentos." Accedidoel30/3/2008,dehttp://www.w3c.es/Traducciones/es/TR/2003/RECsoap12 part020030624/. V.Pelechano,"Serviciosweb.Estandares,extensionesyperspectivasdefuturo,"2005. OASIS.(2007)."OASISStandardsandOtherApprovedWork."Accedidoel30/3/2008,de http://www.oasisopen.org/specs/index.php. OASIS.(2004)."WebServicesSecurity."Accedido,28/04/2008,dehttp://docs.oasis open.org/wss/2004/01/oasis200401wsssoapmessagesecurity1.0.pdf. W3CWorldWideWebConsortium.(2006)."WebServicesPolicy1.2Framework(WS Policy)."Accedidoel5/5/2008,dehttp://www.w3.org/Submission/WSPolicy/. WebServiceInteroperatibilyOrganizacion.(2004)."BasicProfileVersion1.0."Accedidoel 05/05/2008,dehttp://www.wsi.org/Profiles/BasicProfile1.020040416.html. OASIS.(2007)."OASISWebServicesBusinessProcessExecutionLanguage(WSBPEL)TC PublicDocuments."Accedidoel05/05/2008,dehttp://www.oasis open.org/committees/documents.php?wg_abbrev=wsbpel. R.N.Marset.(2006)."RESTVSWEBSERVICES."Accedidoel8/4/2008,de http://www.dsic.upv.es/~rnavarro/NewWeb/docs/RestVsWebServices.pdf. R.T.Fielding,"ArchitecturalStylesandtheDesignofNetworkbasedSoftware Architectures."vol.DoctorofPhilosophyinInformationandComputerScienceIrvine: UniversityofCalifornia,2000.8/4/2008
[5] [6] [7] [8]
[9] [10] [11] [12]
[13] [14] [15] [16] [17] [18]
[19] [20]
33

Web Services. Estado Del Arte

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Web Services. Estado Del Arte

Uploaded by

Copyright:

Available Formats

UNIVERSIDADPONTIFICADESALAMANCACAMPUSDEMADRID

[5] [6] [7] [8]

[9] [10] [11] [12]

[13] [14] [15] [16] [17] [18]

You might also like