• Categories
• Jabón
• Arquitectura orientada a servicios
• Red mundial
• Tecnología
• Ingeniería de software

Citation preview

       

 

UNIVERSIDAD PONTIFICA DE SALAMANCA CAMPUS DE MADRID 

Estado del Arte de  los Servicios Web  PRIMER AVANCE DEL TRABAJO DE INVESTIGACION DEA

Edwin Alberto Valencia Castillo  11/04/2008   

Estado del Arte de los Servicios Web  2008   

INDICE  INDICE _________________________________________________________________________________  2  INTRODUCCION _________________________________________________________________________  3  I. 

SERVICIOS WEB _____________________________________________________________________  4  1.1.  1.2.  1.3.  1.4. 

II. 

DEFINICION ____________________________________________________________________  4  CARACTERISTICAS _______________________________________________________________  5  BENEFICIOS ____________________________________________________________________  6  ELEMENTOS ____________________________________________________________________  7 

ARQUITECTURA DE SERVICIOS WEB ____________________________________________________  10  2.1.  COMPONENTES DE LA ARQUITECTURA  _____________________________________________  11  2.1.1.  Servicio __________________________________________________________________  11  2.1.2.  Proveedor de Servicio _______________________________________________________  11  2.1.3.  Registro de Servicios ________________________________________________________  11  2.1.4.  Solicitante de Servicios ______________________________________________________  11  2.2.  OPERACIONES DE LA ARQUITECTURA _______________________________________________  12  2.2.1.  Publicar/Cancelar __________________________________________________________  12  2.2.2.  Buscar ___________________________________________________________________  12  2.2.3.  Enlazar (Bind) _____________________________________________________________  12  2.3.  MODELOS ARQUITECTONICOS ____________________________________________________  13  2.3.1.  El Modelo orientado a mensajes ______________________________________________  13  2.3.2.  El Modelo orientado a servicios _______________________________________________  14  2.3.3.  Modelo orientado a recursos _________________________________________________  14  2.3.4.  Modelo de Políticas  ________________________________________________________  15 

III.  ESTANDARES Y ESPECIFICACIONES RELACIONADOS CON LOS SERVICIOS WEB__________________  16  3.1.  3.2.  3.3.  3.4.  3.5.  3.6.  3.7.  IV. 

SOAP (SIMPLE OBJECT ACCESS PROTOCOL) _______________________________________________  21  WSDL (WEB SERVICE DESCRIPTION LANGUAGE) ____________________________________________  23  UDDI (UNIVERSAL DESCRIPTION DISCOVERY AND INTEGRATION) _________________________________  25  WS‐SECURITY  _________________________________________________________________  26  WS‐POLICY____________________________________________________________________  28  WS‐I _________________________________________________________________________  29  WS‐BPEL  _____________________________________________________________________  29  REST UNA PROPUESTA ALTERNATIVA A SOAP _________________________________________  31 

4.1.  4.2. 

DEFINICION ___________________________________________________________________  31  PRINCIPIOS  ___________________________________________________________________  32 

REFERENCIAS BIBLIOGRAFICAS ____________________________________________________________  33 

   

 

2   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008   

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  número  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  más complejas. Para establecer dichas comunicaciones, se han creado estándares  que se han agrupado bajo la denominación de servicios web.    Estos estándares permiten que las empresas categoricen los tipos de servicios que  ofrecen, describir cómo debe interactuar con otras aplicaciones y definir como será  codificada  la  información  intercambiada  entre  un  cliente  y  un  proveedor  de  un  servicio determinado.    En la actualidad, las empresas están usando los servicios web como construcciones  básicas  para  el  desarrollo  de  aplicaciones,  creando  nuevas  arquitecturas  de  software  orientadas  a  servicios  (Service‐Oriented  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  más  flexible,  donde  las  empresas  compartan  información,  procesos  y  sus  mejores  prácticas  a  través  de  toda  la  empresa,  con  capacidades  modulares  que  puedan  ser  rápidamente  configuradas para crear oportunidades y resolver problemas.    El  presente  trabajo  busca  detallar  el  estado  del  arte  de  los  servicios  web  y  sus  arquitecturas, tratando de describir  sus estándares y nuevas tendencias.   

 

 

3   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008   

I.

SERVICIOS WEB 

 

1.1.

DEFINICION  El W3C 1     Web  Services  Architecture  Working  Group,  define  un  servicio  web  como  un  sistema  software  diseñado  para  soportar  la  interacción  interoperable  de  maquina  a  máquina  sobre  una  red.  Tiene  una  interfaz  descrita  en  un  formato  procesable  por  un  computador (específicamente WSDL). Otros sistemas interactúan con los servicios web en  una  manera  preestablecida  por  su  descripción  usando  mensajes  SOAP,  típicamente   usando  el  protocolo  HTTP  con  una  serialización  XML  en  conjunto  con  otros  estándares  web relacionados.[1]    Además, especifica que un servicio web proporciona un medio estándar para inter‐operar  entre diferentes aplicaciones software, ejecutándose en una variedad de plataformas y/o  frameworks[1]    El W3C también define a un servicio web como: Una aplicación 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 múltiples definiciones sobre lo que son los Servicios Web, lo que  muestra su complejidad a la hora de dar una adecuada definición que englobe todo lo que  son e implican. Una posible sería hablar de ellos como un conjunto de aplicaciones o de  tecnologías  con  capacidad  para  interoperar  en  la  Web.  Estas  aplicaciones  o  tecnologías  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  llamando a estos procedimientos a través de la Web.    IBM,  al  respecto  considera,  que  los  servicios  web  son  un  conjunto  de  estándares  emergentes  que  habilitan  la  integración  interoperable  entre  sistemas  y  procesos  de  TI  heterogéneos.  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  científicos  y  de  negocios    más  básicos  hasta  los  más  complejos  En  resumen  los  servicios  web  mantienen  y  proporcionan  un  mecanismo  estándar  común  para  la  integración  interoperable  entre  sistemas  dispares  y  la  clave  de  su  utilidad  es  la  estandarización.  Este  mecanismo  común  para  entregar  un  “servicio”  lo  hace  ideal  para  implementar un arquitectura orientada a servicios (SOA).[3]  Podemos  concluir  que  los  servicios  web  son  aplicaciones  auto‐contenidas,  auto‐descritas  que  pueden  ser  publicadas,  localizadas  e  invocadas  a  través  de  la  web.  Una  vez 

                                                              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  máximo  potencial  desarrollando  protocolos  comunes  que  permitan  su  evolución  y  aseguren  su  interoperabilidad. 

1

 

4   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008    desarrolladas, otras aplicaciones (y otros servicios web) pueden descubrirlas e invocarlas  respectivamente.    Un ejemplo de funcionamiento de los servicios web extraído de [2] se muestran en la Fig. 1., donde un usuario (que juega el papel de cliente dentro de los Servicios Web), a través  de  una  aplicación,  solicita  información  sobre  un  viaje  que  desea  realizar  haciendo  una  petición a una agencia de viajes que ofrece sus servicios a través de Internet. La agencia de  viajes ofrecerá a su cliente (usuario) la información requerida. Para proporcionar al cliente  la  información  que  necesita,  esta  agencia  de  viajes  solicita  a  su  vez  información  a  otros  recursos (otros Servicios Web) en relación con el hotel y la compañía aérea. La agencia de  viajes obtendrá información de estos recursos, lo que la convierte a su vez en cliente de  esos otros Servicios Web que le van a proporcionar la información solicitada sobre el hotel  y la línea aérea. Por último, el usuario realizará el pago del viaje a través de la agencia de  viajes  que  servirá  de  intermediario  entre  el  usuario  y  el  servicio  Web  que  gestionará  el  pago.   

 

  Figura 1. Los servicios web en funcionamiento[2]   

1.2.

CARACTERISTICAS  En M. Endrei et.al.[4] identificamos las características principales de los servicios web, los  cuales se describen a continuación:  • Los  servicios  web  son  auto‐contenidos:  En  el  lado  del  cliente,  no  se  requiere  ningún  software  adicional.  Un  lenguaje  de  programación  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  servicios web, habilitar una aplicación existente sin escribir una línea de código.  • Los  servicios  web  son  auto‐descritos:  Ni  el  cliente  ni  el  servidor  conoce  o  pretende  conocer acerca de cualquier cosa además del formato y contenido de los mensajes de  peticiones  y  respuestas  (Integración  de  aplicaciones  débilmente  acopladas).  La  definición del formato del mensaje viaja con el mensaje. No se requiere repositorios  de metadatos externos o herramientas generadoras de código.  

5   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008    • •

•

•

• •

1.3.

Los servicios web son modulares: Los servicios web son una tecnología para desplegar  y  proporcionar  acceso  a  funciones  del  negocio  sobre  la  web;  J2EE,  CORBA,  y  otros  estándares son tecnologías que permiten implementar estos servicios web.  Los servicios web pueden ser publicados, localizados e invocados a través de la web:  Los estándares requeridos para hacer esto son:  o Simple Object Access Protocol (SOAP), también conocido como protocolo de la  arquitectura orientada a servicios, es un RPC basado en XML y un protocolo de  mensajería.   o Web  Service  Description  Language  (WSDL),  es  una  interfaz  descriptiva  y  un  protocolo de lenguaje obligatorio.  o Universal  Description,  Discovery,  and  Integration  (UDDI),  un  mecanismo  de  registro que se puede usar para buscar descripciones de servicios web.  Los  servicios  web  son  inter‐operables  e  independientes  del  lenguaje:  La  interacción  entre  un  proveedor  de  servicio  y  un  solicitante  del  servicio  está  diseñado  para  ser  completamente independiente del lenguaje y la plataforma. Esta interacción 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  lenguaje está usando el otro.  Los servicios web son intrinsecamente abiertos y basados en estándares: XML y HTTP  son los fundamentos técnicos para los servicios web. Una gran parte de la tecnología  de los servicios web se ha construido usando proyectos open source. Por lo tanto la  independencia del vendedor y la inter‐operatibilidad son metas realistas.   Los servicios web son dinámicos: Los e‐business dinámicos pueden convertirse en una  realidad  usando  servicios  web,  porque  con  UDDI  y  WSDL,  la  descripción  y  descubrimiento de los servicios web pueden ser automatizados.  Los  servicios  web  son  componibles:  Servicios  web  simples  pueden  ser  agregados  a  otros más complejos usando técnicas de workflow o llamadas a servicios web de más  bajo nivel de un servicio web implementado. 

BENEFICIOS  J. McGovern et.al.[5] indica que los beneficios de los servicios web en una empresa son:   • 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  probabilidad que los servicios web mejoren la reusabilidad depende de varios factores  como: inter operatibilidad, modularidad, registro central y dependencias de tiempo de  compilación  reducido.  La  tecnología  interoperable  mejora  la  reutilización.  Por  ejemplo,  si  es  difícil  para  una  aplicación  conectarse  a  y  utilizar  un  componente,  es  poco probable que el componente sea reutilizado. Los servicios web se construyen con  estándares  abiertos,  interoperables  y  ubicuos  que  maximizan  su  potencial  para  la  reutilización. La creación de una capa de servicios robusto mejora la reusabilidad, que  conduce a un mejor retorno de la inversión.    

6   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008    •

Localización  transparente:  Un  entorno  de  servicios  alcanzara  una  localización  transparente porque la localización se almacena en un registro. Un cliente encuentra y  fija  un  servicio  y  sin  importar  donde  se  localiza  el  servicio.  Por  lo  tanto,  una  organización  tiene  la  flexibilidad  para  mover  sus  servicios  a  diferentes  maquinas  o  mover un servicio a un proveedor externo. Es  también posible mover código  de una  plataforma  a  otra.  La  arquitectura  orientada  a  servicios  requiere  que  esos  servicios  soporten  un  contrato  de  publicación.  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,  ningún  cambio  en  los  clientes  es  necesario.  "Envolver  y  sustituir"  es  un  patrón  común  en  un  entorno  orientado  a  servicios.  Proporciona  a  la  organización  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  componente o sistema sin requerir cambios en el cliente que usa ese servicio. 

•

Composición: Los desarrolladores ensamblan aplicaciones de un catalogo preexistente  de  servicios  reusables.  Los  servicios  no  dependen  de  ninguna  aplicación,  porque  los  servicios  son  independientes,  los  desarrolladores  usaran  esos  servicios  en  muchas  aplicaciones.  El  proceso  de  diseño  de  interfaces  promueve  el  diseño  de  interfaces  modulares e independientes de la aplicación para las cual fue diseñada inicialmente.  Las  interfaces  diseñadas  apropiadamente  y  la  creación  de  componentes  independientes permitirá maximizar este potencial.  

•

Escalabilidad y Disponibilidad: Un sistema es escalable si la inversión requerida para  agregar  más  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 implementación, cambiar la implementación para hacerla  mas escalable y disponible requiere poca inversión.  

•

Mantienen la inversión en aplicaciones heredadas: Los servicios ayudan a mantener  la  inversión  en  aplicaciones  heredadas  porque  estos  especifican    solo  el  método  de  interacción,  y  no  el  método  de  implementación.  Los  sistemas  heredados  pueden  ser  envueltos  en  un  servicio  facade.  Este  método  de  crear  servicios  tiene  la  ventaja  que  permiten a las organizaciones reemplazar aplicaciones heredadas sin cambiar la forma  en que los clientes acceden al servicio. 

•

Reducida  dependencia  del  vendedor:  Mientras  la  plataforma  usada  para  construir  aplicaciones  soporte  estándares  de  servicios  web,  el  consumidor  del  servicio  es  irrelevante. Los servicios web permiten que las organizaciones tomen decisiones sobre  que plataforma usar, basado en los meritos de la plataforma más que en el proveedor.  Los  servicios  web  representan  un  cambio  importante  de  poder,  del  vendedor  de  hardware y software al consumidor de hardware y software. 

 

 

 

 

1.4.

ELEMENTOS  Los autores de [6] y [1], indican que un servicio web es más una idea, un concepto cuya  implementación  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  implementación,  como  hemos  dicho,  existen  una  serie  de  partes  bien 

7   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008    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 descripción  del servicio, la semántica, y por último las personas, la semántica y los agentes.  • Agentes  y  Servicios:  Un  servicio  web,  constituye  una  idea  o  concepto  que  debe  ser  implementado  por  algún  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  es el encargado de recibir las peticiones y enviar las respuestas. Sin embargo, el SW es  el  conjunto  abstracto  de  funcionalidades  ofrecidas.  El  agente  será  escrito  usando  algún  lenguaje  de  programación  y  se  ejecutará  bajo  una  plataforma  en  concreto.  Podemos  variar  este  agente  según  la  implementación  que  deseemos  o  necesitemos  darle. Sin embargo, el SW que implemente el agente será siempre el mismo, es decir,  sea cual sea la implementación que demos a un agente para un SW determinado, este  último será semánticamente siempre el mismo, lo que variará será el agente.  • El  cliente  y  el  proveedor:  El  SW  pertenece  a  un  propietario  que  puede  ser  bien  una  persona, bien una organización. La entidad proveedora será la persona u organización  que desarrolle un agente capaz de soportar un determinado servicio. La entidad que  realiza la consulta puede ser también una persona u organización que desea hacer uso  del  servicio  que  expone  la  entidad  proveedora.  Esta  comunicación  tipo  petición‐ respuesta  se  realiza  entre  agentes,  ya  que  en  el  lado  del  que  consulta  también  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  comunicación  se  lleve  a  cabo  de  manera  correcta,  las  entidades  participantes  deben  ponerse de acuerdo, tanto en la semántica como en los mecanismos utilizados en el  intercambio de mensajes.  • Descripción del Servicio: El intercambio de mensajes entre las entidades está guiado  por un protocolo que éstas deben seguir para que las transacciones lleguen a buen fin.  Este  protocolo  está  documentado  en  la  descripción  del  SW  (WSD,  Web  Service  Description).  La  WSD  es  una  descripción  completa  del  SW,  escrito  en  un  lenguaje  denominado  WSDL[7],  y  que  es  inteligible  tanto  por  las  máquinas  como  por  las  personas,  aunque  no  sin  cierta  dificultad  para  estos  últimos.  En  esta  descripción  se  incluyen todos los elementos de un SW susceptibles de ser descritos, tal y como son el  formato de los mensajes, los tipos de datos, los protocolos de transporte a través de  los cuales el servicio está disponible y los distintos formatos de serialización utilizados  para  enviar  el  contenido  de  los  mensajes  entre  los  agentes  que  llevan  a  cabo  esta  comunicación. En esta descripción, también se pueden incluir una o varias direcciones  o localizaciones de red o endpoints, mediante las cuales podremos invocar al agente  proveedor  o  podemos  obtener  información  acerca  del  patrón  de  comunicación  que  hay seguir.  • Semánticas: Definiremos semántica de un SW como el comportamiento que se espera  que tenga el mismo. Este comportamiento, se refiere a qué esperamos del SW cuando  le enviamos un mensaje de petición. De la misma forma que la sintaxis de un objeto es  su estructura, la semántica de un objeto se refleja en las relaciones que éste establece  con  otros  objetos.  Mientas  que  en  la  sintaxis  identificamos  diferentes  partes,  en  la  semántica  identificamos  distintos  contextos.  Esta  semántica  también  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 

8   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008    trata  sobre  cómo  y  porqué  los  agentes  que  intervienen  en  la  comunicación  deberán  interactuar. Este acuerdo puede ser explícito o implícito, oral o escrito, inteligible por  la máquina o por las personas.  • Personas, agentes y semánticas: Uno de los propósitos principales de los SW, es el de  automatizar procesos que de lo contrario deberían ser llevados a cabo manualmente.  El papel que tienen las personas en el uso y en la arquitectura de los SW se puede se  puede ver en dos aspectos:  • Las personas deben  estar de acuerdo en la semántica y en la descripción  del  servicio. Los usuarios de los SW deberán estar implícitos o explícitamente de  acuerdo  con  la  semántica  y  la  descripción  del  servicio  al  cual  dirige  las  peticiones,  y  con  el  que  realizan  la  interacción,  mientras  que  este  servicio  pertenezca a una persona u organización. La entidad proveedora publicará la  semántica y la descripción de su servicio como un contrato del tipo “o lo tomas  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  comunicación,  el  agente  proveedor  y  el  agente  que  realiza  la  petición.  Los  creadores de los agentes deben asegurar que estos cumplen la semántica y la  descripción del servicio. Hay varias formas de asegurar esto último:  a. Un  agente  puede  ser  codificado,  de  manera  que  permanentemente  implemente la semántica y la descripción de un servicio.  b. Podemos  codificar  el  agente,  de  una  manera  más  general,  de  forma  que  dinámicamente  le  pasemos  la  descripción  y/o  la  semántica  del  servicio  deseado en ese momento.  c. Podemos  crear  en  primer  lugar  el  agente,  y  luego  generar  la  descripción  y/o la semántica del servicio después, a partir del código del agente.  En  la  Figura  2.  Se  presenta  un  resumen  donde  se  pueden  observar  la  relación  de  los  elementos citados anteriormente.   

9   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008   

  Figura 2. Elementos de los servicios web [6]    Como  se  puede  ver,  la  entidad  proveedora  y  la  que  realiza  la  petición,  se  ponen  de  acuerdo  respecto  a  la  descripción  del  servicio  (mediante  un  documento  en  WSDL)  y  la  semántica  que  guiarán  la  interacción  entre  los  agentes.  Cada  uno  de  los  agentes,  implementa la semántica 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 petición).  Ambos agentes (el solicitante y el proveedor) intercambian mensajes SOAP en nombre de  los respectivos propietarios. 

II.

ARQUITECTURA DE SERVICIOS WEB 

  La  arquitectura  de  los  servicios  Web  permite  que  ciertos  servicios  sean  dinámicamente  descritos,  publicados,  descubiertos  e  invocados  en  un  ambiente  de  computación  distribuida,  haciendo  uso  de  los  estándares  WSDL,  UDDI,  SOAP  y  XML  respectivamente,  permitiendo  a  los  desarrolladores  implementar  aplicaciones  distribuidas,  utilizando  herramientas  muy  distintas  (heterogéneas)  para  crear  aplicaciones  que  utilizan  una  combinación  de  módulos  de  software  que  son  llamados  desde  diversos  sistemas  distribuidos en regiones geográficas distintas.     Los servicios Web son aplicaciones auto‐contenidas y modulares que pueden ser:   • Descritas  mediante  un  lenguaje  de  descripción  de  servicio,  como  el  lenguaje  WSDL  (Web Service Description Language). [8] 

10   

Edwin Valencia Castillo  

 

Estado del Arte de los Servicios Web  2008    • • • • •

Publicadas,  al  incluir  las  descripciones  y  políticas  de  uso  en  algún  registro  conocido,  utilizando  el  método  de  registro  UDDI  (Universal  Description,  Discovery  and  Integration).[9]   Encontradas,  también  utilizando  el  estándar  UDDI,  al  enviar  peticiones  al  registro  y  recibir  los  detalles  necesarios  para  la  localización  y  enlace  (binding)  sobre  aquel  servicio que se ajusta a los parámetros de la búsqueda.   Asociadas, al utilizar la información contenida en la descripción del servicio para crear  una instancia de servicio disponible (o Proxy).   Invocadas sobre la red, al utilizar la información contenida en los detalles de enlace de  la  descripción  del  servicio;  en  un  documento  WSDL.  Durante  la  invocación,  como  veremos más adelante haremos uso del protocolo SOAP.[10]   Compuestas con otros servicios para integrar servicios y aplicaciones nuevas, en lo que  constituirá la base de SOA (Service‐Oriented Architecture). 

  Todos  los  estándares  comentados  se  basan  en  XML:  los  documentos  WSDL,  son  documentos  XML;  el  protocolo  SOAP,  que  permite  la  comunicación  entre  servicios,  internamente trata información XML en sus dos variantes, por un lado la mensajería SOAP,  tratando información XML explícita y por otro lado RPC, que la trata, pero de una manera  implícita.     

2.1.

COMPONENTES DE LA ARQUITECTURA  Los componentes que conforman la arquitectura de servicios web son:  2.1.1. Servicio  La  aplicación  es  publicada  para  que  sea  utilizada  por  todos  aquellos  solicitantes  que  cumplan  los  requisitos  especificados  por  el  proveedor  de  servicios.  Evidentemente la implementación se realizará sobre una plataforma accesible en  la  red.  El  servicio  se  describe  a  través  del  lenguaje  de  descripción  de  servicios,  WSDL.  Tanto  la  descripción  como  las  políticas  de  uso  han  sido  publicadas  anteriormente en un registro.   2.1.2. Proveedor de Servicio  Desde el punto de vista comercial, es quien presta el servicio. Desde el punto de  vista de la arquitectura, es la plataforma que provee el servicio.  2.1.3. Registro de Servicios  Es un repositorio de descripciones, donde los proveedores publican sus servicios y  la forma de accederlos. Permitirá además a los solicitantes realizar distintos tipos  de búsquedas, obteniendo de éstas, los detalles necesarios para poder localizarlos  y utilizarlos.  2.1.4. Solicitante de Servicios  Desde el punto de vista comercial, la empresa que requiere cierto servicio. Desde  el  punto  de  vista  de  la  arquitectura,  la  aplicación  cliente  que  busca  e  invoca  un  servicio.  

11   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008   

2.2.

OPERACIONES DE LA ARQUITECTURA  Las operaciones que se pueden realizar con los servicios Web, son las siguientes:   2.2.1. Publicar/Cancelar  Un  proveedor  de  servicios  podría  publicar  un  determinado  servicio  comercial  (e‐ business) a uno o más registros de servicios, además de, evidentemente, cancelar  dicha publicación en un momento dado.   2.2.2. Buscar  Los solicitantes de servicios (clientes) podrán interactuar con uno o más registros  para descubrir un conjunto de servicios comerciales con los que puedan  interactuar para encontrar una solución a sus problemas.  2.2.3. Enlazar (Bind)  Los  solicitantes  de  servicios  negocian  con  los  proveedores  la  forma  de  acceder  e  invocar a sus servicios comerciales (e‐business).   Como  se  comento,  un  servicio  Web  es  una  colección  de  funciones  que  son  presentadas  como una sola entidad y que es anunciada en la red para ser usada por otros programas.  Son por lo tanto, bloques de construcción para crear sistemas distribuidos abiertos.   En  la  figura  3  podemos  observar  la  relación  existente  entre  los  componentes  y  las  operaciones de la arquitectura. 

  Figura 3. Relaciones entre los componentes que conforman la arquitectura  de servicios Web    Actualmente,  las  aplicaciones  que  se  están  realizando,  poseen  la  capacidad  de  buscar  y  seleccionar  servicios  dinámicamente  en  tiempo  real,  basándose  en  parámetros  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  automática,  elegirá  el  servicio que más se ajuste a sus necesidades, y por lo tanto el rendimiento del sistema se  verá incrementado.    

12   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008   

2.3.

MODELOS ARQUITECTONICOS  El  W3C  Web  Service  Architecture  Working  Group[1]  definen  modelos  arquitectónicos  como subconjunto coherente de la arquitectura que se centra básicamente en un aspecto  concreto dentro de la arquitectura. Cada modelo intenta explicar al máximo el aspecto en  el que se ha centrado. Un modelo también debe definir todas las dependencias que pueda  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  mediante una representación gráfica de los mismos. 

  Figura 4. Metamodelo de la arquitectura de servicios web [1]  2.3.1. El Modelo orientado a mensajes  Este  modelo  se  enfoca  en  aquellos  aspectos  relacionados  con  los  mensajes,  su  estructura, el método de transporte, etc. Este modelo no atiende ni al porqué de  los mensajes ni a su significado. El interés principal de este modelo se sitúa en la  estructura  de  los  mensajes,  las  relaciones  existentes  entre  los  que  envían  los  mensajes,  los  que  los  reciben  y  otros  intermediarios  que  tengan  que  procesar  también  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 relación que guardan unos conceptos con  otros, aunque la profundidad con que debe ser tratado se escapa a la profundidad  con la que trataremos la cuestión. 

 

13   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008    Figura 5. Modelo orientado a mensajes[1]  2.3.2. El Modelo orientado a servicios  Este modelo se centra en aspectos de la arquitectura relacionados con los servicios  y las acciones principalmente. El propósito 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 lógico, un agente no podría llevar a cabo la  tarea de ofrecer servicios a los clientes si no tuviera la capacidad de enviar y recibir  mensajes,  pero  este  modelo  no  hace  referencia  los  mensajes  o  al  método  de  transporte  de  los  mismos.  El  Modelo  Orientado  a  Servicio  se  construye  sobre  el  Modelo  Orientado  a  Mensajes,  pero  centrándose  en  las  acciones  en  lugar  de  los  mensajes.  En  la  figura  8  se  muestran  algunos  conceptos  relacionados  con  este  modelo y las relaciones existentes entre ellos.   

Figura 6. Modelo orientado a servicios[1] 

 

2.3.3. Modelo orientado a recursos  Este modelo se centra en aquellos aspectos de la arquitectura relacionados con los  recursos y el modelo de servicio asociado con la manipulación de los mismos.  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  manipulación.  La  función  principal  de  esta parte de la arquitectura es explicar la Web en sí, y cómo se relaciona con los  servicios  web.  Este  modelo  intenta  explicar  esto  último  mostrando  como  un  los  recursos  son  un  concepto  independiente,  y  como  la  manipulación  de  éstos  son  solamente  una  instancia  del  Modelo  de  Servicios,  sólo  que  con  sus  propios  servicios y acciones sobre los recursos. A continuación en la figura 9, se muestran  algunos conceptos relacionados con este modelo y las relaciones existentes entre  ellos.   

14   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008   

Figura 7. Modelo orientado a recursos[1] 

 

2.3.4. Modelo de Políticas  Este modelo se centra en aquellos aspectos de la arquitectura relacionados con las  políticas, y por extensión, con la seguridad y la calidad del servicio. El concepto de  política  es  muy  simple,  es  simplemente  una  restricción  sobre  el  comportamiento  de  los  agentes  y  los  servicios.  La  seguridad,  es  básicamente  un  conjunto  de  restricciones  respecto  del  comportamiento  de  las  acciones  y  del  acceso  a  los  recursos. De manera similar, la calidad se considera también un tipo de restricción  que  puede  ser  aplicada  a  los  servicios.  En  el  Modelo  de  Políticas,  estas  restricciones  se  modelan  alrededor  de  los  conceptos  de  política  y  sus  relaciones  con otros elementos de la arquitectura, por ello, el Modelo de Políticas resulta ser  un  marco  de  trabajo  en  el  que  implementar  la  seguridad.  Sin  embargo,  existen  muchos  otros  tipos  de  restricciones  y  políticas  relevantes  a  los  SW,  incluyendo  restricciones a nivel de aplicación. 

Figura 8. Modelo de Políticas[1] 

15   

Edwin Valencia Castillo  

 

 

Estado del Arte de los Servicios Web  2008   

III.

ESTANDARES Y ESPECIFICACIONES RELACIONADOS CON LOS  SERVICIOS WEB  En  la  actualidad  existen  organizaciones  relacionadas  con  la  definición  de  estándares  y  especificaciones,  estas  se  encuentran  en  constante  trabajo,  buscando  que  los  servicios  web  sean  cada  vez  más  interoperables  y  seguros.  Una  breve  descripción  de  estas  organizaciones, obtenida de  [11] se detalla a continuación:    Web Services Interoperability Organization (WS‐I), Es una organización de industria  abierta que busca promover la interoperatibilidad de los servicios web entre plataformas,  sistemas operativos y lenguajes de programación.   La comunidad agrupa organizaciones líderes en el desarrollo servicios web que ayudan a  desarrollar  servicios  web  interoperables  proporcionando  dirección,  practicas  recomendadas  y  soporte  de  recursos.  Específicamente,  WS‐I  crea,  promueve  y  apoya  protocolos  genéricos  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 evolución y aseguren su  interoperabilidad.  El  W3C  esta  conformado  por  mas  de  350  organizaciones  de  todo  el  mundo y ha ganado reconocimiento internacional por sus contribuciones al crecimiento de  la  web.  El  W3C  esta  diseñando  la  infraestructura,  y  definiendo    la  arquitectura  y  las  tecnologías base para los servicios web.     Internet  Engineering  Task  Force  (IETF)  Es  una  gran  comunidad  internacional  abierta  de  diseñadores  de  red,  operadores,  vendedores  e  investigadores  referidos  con  la  evolución  de la arquitectura de internet y su operación.       Organization  for  the  Advancement  of  Structured  Information  Standards  (OASIS)  Es  un  consorcio  internacional  sin  fines  de  lucro  que  conduce  el  desarrollo,  convergencia  y  adopción de estándares e‐business. El consorcio produce más estándares de servicios web  que  cualquier  otra  organización  junto  con  estándares  para  seguridad,  e‐business,  y  esfuerzos  de  estandarización    en  el  sector  público    y  mercados  de  aplicación  especifica.  Fundado  en  1993,  OASIS  tiene  más  de  4000  participantes,  representando    a  más  de  600  organizaciones y miembros individuales en 100 países.    A continuación se muestra el núcleo de estándares para los servicios web. La separación  entre capas indica las dependencias aproximadas entre estas.   

16   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008   

Figura 9. Pila de servicios web[1]    •

•

•

•

17   

 

Comunications  ó  transporte:  La  especificación  de  los  estándares  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  mensajería.   Mensajería: SOAP está en el núcleo de la capa de la mensajería en los servicios web.  SOAP define un modelo de codificación extensible, basado en XML. La importancia de  SOAP es que brinda el marco para construir la operabilidad on the wire en tiempo de  ejecución.  La  capa  de  mensajería  también  está  diseñado  para  convivir  con  otros  protocolos de mensajería no‐XML   Descripciones:  Al  ser  débilmente  acoplado,  el  modelo  orientado  a  servicios  requiere  que se expliciten las capacidades y los requisitos del servicio ofrecido. Se da soporte a  la descripción de servicios en dos niveles. La definición funcional (qué hace el servicio)  en  la  forma  de  lenguaje  de  definición  de  interfaces  (basado  en  XML)  lo  proporciona  WSDL.  Éste  describe  los  protocolos  específicos  de  transporte  y  el  modelo  de  mensajería  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  "políticas  de  servicio  web",  codificando  información  tal  como  los  requisitos  de  seguridad del servicio, los protocolos fiables de mensajería a seguir o los requisitos de  privacidad. La especificación WS‐Policy define un lenguaje simple para codificar estos  requisitos.   Procesos: Esta capa incluye procesos tales como el de Descubrimiento, la coordinación  y  la  negociación  de  la  interacción.  El  primero  nos  brinda  la  capacidad  de  descubrir  dinámicamente  nuestros  servicios  web,  de  vincularlos  y  de  interactuar  con  ellos.  La  especificación  UDDI  (Universal  Description,  Discovery  and  Integration)  define  el  servicio y permite el descubrimiento de servicios basados en su función y capacidades  declaradas, pudiéndose, en los entornos más dinámicos, definir contratos que regulen  la interacción entre dos socios de servicios respecto a características de la prestación  del servicio, consideraciones financieras, legales, etc. Esto se puede especificar en un  Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008    formato  legible  por  la  máquina.  La  capacidad  de  negociar  estos  contratos  dinámicamente  será  de  vital  importancia  para  llevar  a  cabo  la  visión  completa  del  paradigma de la orientación a servicios.     Asimismo en [3], podemos encontrar una representación grafica y agrupación de todos los  estándares y especificaciones.   

  Figura 10. Estándares y especificaciones relacionados a los servicios web[3]    La  agrupación  de  estos  estándares,  las  cuales  se  obtuvieron  de  [3]  y  [11]  ,  se  describe  a  continuación:  • 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 aplicación. Ha sido estandarizado por el IETF (Internet Engineering Task  Force) y es para los protocolos de internet como XML lo es para los datos.  • Mensajes  Estas especificaciones y estándares de mensajes intentan proporcionar un framework  para el intercambio de información en un entorno distribuido y descentralizado.  SOAP 1.1 (Note)   SOAP 1.2 (Specification)   Web Services Addressing  Web Services Notification (WS‐BrokeredNotification, WS‐BaseNotification, WS‐Topics  Web Services Attachments Profile 1.0   MTOM Serialization Policy Assertion (WS‐MTOMPolicy) Version 1.0   • Descripción y descubrimiento  Los servicios web son significativos solo si los usuarios potenciales pueden encontrar  información  suficiente  para  permitir  su  ejecución.  El  enfoque  de  estos  estándares  y  especificaciones es la definición de un conjunto de servicios que apoyen la descripción  y  descubrimiento  de  los  negocios,  organizaciones  y  otros  proveedores  de  servicios  web; los servicios web que hacen disponibles y las interfaces técnicas que se pueden  utilizar para tener acceso a estos servicios.  UDDI 3.0   WSDL 1.1 (Note)   WSDL 1.2 (Working draft)  

18   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008    WSDL 2.0 (Working Group)   Web Services Semantics ‐‐ WSDL‐S   Web Services Metadata Exchange   Web Services Policy Assertions Language   Web Services Policy Attachment   Web Services Policy Framework   Web Services Resource Framework     •

Confiabilidad  No  es  posible  solucionar  aspectos  del  negocio  si  los  participantes  no  pueden  estar  seguros  de  la  culminación  exitosa  del  intercambio  de  mensajes.  La  mensajería  confiable  que  permite  que  los  mensajes  sean  entregados  confiablemente  entre  aplicaciones distribuidas en presencia de componentes software, sistemas o fallas de  la red, es por lo tanto critico en los servicios web.  Web Services Reliable Messaging   WS‐RM Policy Assertion  

•

Transacciones  Las  transacciones  son  un  concepto  fundamental  en  la  construcción  de  aplicaciones  distribuidas confiables. Un entorno de servicios web requiere un comportamiento de  coordinación  proporcionado  por  un  mecanismo  de  transacción  tradicional  para  controlar las operaciones y el resultado  de una aplicación.  Web Services Atomic Transaction   Web Services Business Activity   Web Services Coordination  

•

Seguridad  Usando  estas  especificaciones  de  seguridad,  las  aplicaciones  pueden  garantizar  una  comunicación  segura  diseñada  para  trabajar  con  un  framework  de  servicios  web  en  general.  Web Services Federation Language   WS‐Federation: Active Requester Profile   WS‐Federation: Passive Requester Profile   Web Services Provisioning   Web Services Secure Conversation Language   Web Services Security 1.0   Web Services Security Addendum   WS‐Security Kerberos Binding   Web Services Security Policy   Web Services Trust   Security Assertion Markup Language (SAML)  

•

Procesos de negocio  Un proceso de negocio especifica un orden de ejecución potencial de operaciones de  una colección de servicios web, los datos compartidos entre estos servicios web, que  socios están involucrados y como ellos están involucrados en el proceso del negocio,  junto  con  el  manejo  de  excepciones  para  las  colecciones  de  servicios  web  y  otros 

 

 

 

19   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008    aspectos  involucrados  como  servicios  múltiples  y  organizaciones  participantes.  BPEL  especifica el proceso de negocio y como los servicios web se relacionan.  WS‐BPEL Extension for People   Business Process Execution Language for Web Services V1.1     •

Administración  La administración de servicios web es definida como un conjunto de capacidades para  descubrir  la  existencia,  disponibilidad,  funcionalidad,  rendimiento,  uso,  asi  como  el  control y configuración  de un servicio web con la arquitectura de servicios web. Pues  los servicios web llegan influyentes y críticos para la operación del negocio, la tarea de  administrarlos e implementarlos es imperativa al éxito de las operaciones del negocio.  Web Services Distributed Management   Web Services Manageability   Web Services Manageability ‐‐ Concepts   Web Services Manageability ‐‐ Representation   WS‐ResourceTransfer   Web Services Service Registry and Repository  

  En la siguiente figura se presenta todos los estándares y especificaciones según [11]   

Figura No.  11. Pila de estándares y especificaciones de los servicios web[11]   

20   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008    En los párrafos siguientes presentaremos un breve resumen de los  principales estándares  y especificaciones de los servicios web y sus aspectos principales. 

3.1.

SOAP (Simple Object Access Protocol)  El estándar SOAP (en su versión actual 1.2, recomendado por W3C en su segunda edición  en el 2007[10]) define un protocolo que da soporte a la interacción (datos + funcionalidad)  entre  aplicaciones  en  entornos  distribuidos  y  heterogéneos,  y  es  interoperable,  es  decir,  neutral  a  la  plataforma,  lenguajes  de  programación,  independiente  del  hardware  y  protocolos.  Funciona  sobre  la  infraestructura  (estándares)  existentes  en  Internet.  SOAP  define  cómo  organizar  la  información  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  métodos  de  objetos  o  funciones,  que  residen en sistemas remotos.    En  [12]  se  indica  que  SOAP  es  fundamentalmente  un  paradigma  de  intercambio  de  mensajes en un sólo sentido, sin estado, pero las aplicaciones pueden crear patrones de  interacción  más  complejos  (por  ejemplo,  petición/respuesta,  petición/respuestas  múltiples,  etc.)  combinando  tales  intercambios  de  un  solo  sentido  con  características  proporcionadas  por  el  protocolo  utilizado  y/o  información  específica  de  la  aplicación  en  cuestión.  SOAP  no  interfiere  en  la  semántica  de  cualesquiera  datos  específicos  de  aplicación que comunica, ni tampoco en asuntos tales como en enrutamiento de mensajes  SOAP,  transferencia  de  datos  fiables,  cortafuegos  que  atraviesa,  etc.  No  obstante,  SOAP  proporciona  el  marco  de  trabajo  por  el  que  la  información  de  aplicaciones  específicas  puede  comunicarse  de  forma  extensible.  También,  SOAP  proporciona  una  descripción  completa de las acciones que debe realizar un nodo SOAP al recibir un mensaje SOAP.    En [13], detalla que SOAP especifica:  • Un  formato  de  mensaje  para  una  comunidad  unidireccional,  describiendo  cómo  se  empaqueta la información en documentos XML.   • Un conjunto de convenciones para usar mensajes SOAP, para implementar el patrón  de  interacción  RPC,  definiendo  cómo  los  clientes  pueden  invocar  un  procedimiento  remoto enviando un mensaje SOAP y cómo los servicios pueden responder enviando  otro mensaje al llamador.   • 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  codificación de datos).   • Una descripción de cómo se debe transportar un mensaje SOAP sobre HTTP y SNMP.  Se  definirán  bindings  a  otros  protocolos  de  transporte  en  futuras  versiones  de  la  especificación.   Los mensajes SOAP son fundamentalmente mensajes en una dirección, desde un “emisor”  (cliente)  hacia  un  “receptor”  (servidor),  y  las  comunicaciones  son  del  tipo  request/response. Todos los mensajes son documentos XML con su propio esquema, que  incluye sus propios espacios de nombres (namespaces), elementos y atributos.    

21   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008    SOAP  define  dos  namespaces:  envelope  y  encoding.  Como  característica  destacable,  podemos  decir  que  no  puede  tener  DTD  asociados.  Los  mensajes  SOAP  constan  de  tres  secciones (ver figura 4): envelope, header y body.   • Envelope (envoltura): Es el elemento raíz del mensaje para describir su contenido y la  forma de procesarlo.  • Header (encabezado): información de identificación del contenido.   • Body(cuerpo): es el contenido del mensaje.    

  Figura 12. Secciones de un mensaje SOAP    Se  pueden  realizar  extensiones  al  protocolo;  esto  es  posible  gracias  a  la  adicción  de  módulos de funcionalidad. Este enfoque permite a los desarrolladores usar los módulos 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  más importantes que se pueden realizar son las que se muestran a continuación:   • Attachments:  Hace  referencia  a  la  posibilidad  de  incluir  un  documento  no  XML,  o  archivo  binario,  enviar  documentos  de  fax,  imágenes  de  medicina,  dibujos  de  ingeniería, o cualquier otro tipo de imágenes, codificadas en Base64.  • Routing/Intermediaries: Relacionadas con el proceso de encaminar mensajes SOAP a  través  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  través  del  direccionamiento,  incluso,  hacia  múltiples servidores.   • Reliable  Messaging:  Determina  cuanto  tiempo  espera  un  servidor  cuando  envía  un  mensaje y espera por la respuesta.   • Security: Esta extensión nos permitirá dar un marco de seguridad a la comunicación.  Algunos  de  los  aspectos  podrían  ser  aplicar  SSL,  firma  digital,  etc.  Mediante  XML  Signature podemos proporcionar integridad, autenticación de mensajes, y/o servicios  de autenticación de firmas.   • Quality  of  Service  (QoS):  Es  una  medida  para  calificar  la  calidad  del  servicio,  determinando la usabilidad y utilidad del servicio.   • Context/Privacy: Referencia a los mecanismos para guardar el contexto y la privacidad  del entorno de los usuarios.  

22   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008    •

Transaction Support: Permite que un grupo de operaciones o acciones se comporten  como si fueran una simple unidad (o todo falla o todo es un éxito).     En cuanto al rendimiento de los mensajes de SOAP utilizando HTTP y XML, comparado con  el rendimiento de mensajes binarios utilizados por CORBA, DCOM y RMI, se puede afirmar  que  en  el  caso  de  los  últimos,  tanto  el  destinatario  y  remitente  tienen  conocimiento  completo del contenido del mensaje y no codifican meta información como los nombres o  tipo de argumentos. Quizás este método sea eficiente, pero dificulta a los intermediarios  el procesamiento de mensajes. Y debido a que cada sistema utiliza una codificación binaria  distinta, dificulta la construcción de sistemas interoperables.   Dado que SOAP utiliza XML para codificar mensajes, es relativamente sencillo procesar los  mensajes  en  cada  paso  del  proceso  de  llamada.  Además,  la  facilidad  de  depuración  de  mensajes SOAP permite la convergencia rápida de las diversas implementaciones de SOAP,  lo cual es importante en la interoperabilidad a gran escala.    

3.2.

WSDL (Web Service Description Language)  El WSDL (Web Service Description Language)[8], creado originalmente por IBM, Microsoft  y Ariba. Tiene un rol y un propósito 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  distribuidas sobre plataformas heterogéneas. Un archivo WSDL es un documento XML que  describe  los  servicios  Web,  en  particular  sus  interfaces.  Como  característica  que  lo  diferencia de los IDL, es que WSDL debe definir los mecanismos de acceso (protocolos) a  los  servicios  Web.  Otra  característica  diferenciadora  es  la  necesidad  de  definir  (en  la  especificación)  la  localización  del  servicio  (puntos  finales).  La  separación  de  interfaces  y  enlaces  de  protocolos,  y  la  necesidad  de  incluir  información  de  localización  permite  la  definición de especificaciones modulares. WSDL permite definir interfaces más complejas  y  expresivas;  permitiendo  definiciones  de  interacciones  asíncronas  y  diferentes  paradigmas de interacción, y la posibilidad de combinar o agrupar operaciones. En la figura  3, se muestra un diagrama con la arquitectura de los sistemas basados en servicios Web,  en el que se representan los estándares descritos.     WSDL es un formato XML que describe los servicios de red como un conjunto de endpoints  que procesan mensajes contenedores de información orientada tanto a documentos como  a  procedimientos.  Las  operaciones  y  los  mensajes  se  describen  de  forma  abstracta,  y  después se enlazan a un protocolo de red y a un formato de mensaje concreto para definir  un  endpoint  de  red.  Los  endpoints  concretos  relacionados  se  combinan  en  endpoints  abstractos (servicios).    El  lenguaje  WSDL  es  extensible,  lo  que  permite  la  descripción  de  endpoints  de  red  y  sus  mensajes,  independientemente  de  los  formatos  de  los  mensajes  o  protocolos  de  red  utilizados para comunicarse.     El documento WSDL de un servicio proporciona dos piezas de información básicas: (1) una  parte o interface abstracta (independiente de la aplicación) y (2) una parte específica, que 

23   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008    define los enlaces a protocolos e información de los puntos finales de acceso al servicio.  Ver figura 5.   

  Figura 13 Estructura de un documento WSDL    La parte abstracta está compuesta por:   • Definiciones  de  port  types:  análogos  a  los  interfaces  en  IDL.  Cada  port  type  es  una  colección lógica de operations.   • Operations: Cada operation define un intercambio simple de mensajes.   • Message: Un message es una unidad de comunicación que representa un intercambio  de datos en una única transmisión lógica.   • Types:  Un  sistema  de  tipos  (types)  usados  por  las  operations  (por  defecto  XML  Schema).   La parte específica está compuesta por:   • Definiciones de Bindings: se especifica la codificación de los mensajes, y los enlaces a  protocolos de todas las operaciones y mensajes definida en un port type.   • Definiciones  de  Ports:  se  especifica  en  qué  dirección  (URI)  se  puede  acceder  a  la  implementación del port type. Definen un punto final (lugar de la red) donde está el  servicio.   • Definiciones de Services: definen una agrupación de Ports.   Esta  es  la  forma  que  tiene  WSDL  de  describir  los  servicios  Web,  en  términos  de  los  mensajes que acepta y genera. Actúa como contrato entre un consumidor (cliente) y dicho  servicio. WSDL puede describir puntos finales y sus operaciones sin especificar el formato  de  los  mensajes  o  los  protocolos  de  red  (SOAP,  HTTP‐GET/POST  y  MIME)  a  los  cuales  el  punto final está ligado.     El lenguaje de descripción de servicios Web es, por lo tanto, el equivalente a un resumen  diseñado en XML, en el cual se describen los servicios Web, indicando dónde se ubican y la  forma de invocarlos. A continuación se muestra un ejemplo de documento WSDL.    

24   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008   

3.3.

UDDI (Universal Description Discovery and Integration)  El  UDDI[9],  es  un  directorio  que  contiene  un  registro/repositorio  de  descripciones  de  servicios Web. Este estándar permite a las empresas registrarse en un tipo de directorio de  Internet  que  les  ayuda  a  anunciar  sus  servicios,  de  tal  forma  que  el  resto  de  compañías  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  especificación UDDI tiene dos objetivos esenciales, en primer lugar servir de soporte a los  desarrolladores  para  encontrar  información  sobre  servicios  Web  y  poder  construir  clientes;  y  por  otro  lado,  facilitar  el  enlace  dinámico  de  servicios  Web,  permitiendo  consultar referencias y acceder a servicios de interés.     Siempre ha sido un reto la comunicación entre los negocios a nivel de aplicaciones, dada la  enorme  cantidad  de  plataformas,  herramientas,  mecanismos  y  procesos  que  cada  cual  utiliza.  XML  se  presenta  como  la  solución  para  el  intercambio  de  datos  de  una  forma  transparente.  También,  la  evolución  de  protocolos  como  SOAP,  ya  comentado  anteriormente, proporciona una plataforma para el intercambio de servicios sobre la red.  Si  el  mecanismo  de  comunicación  entre  las  plataformas  es  el  XML,  y  la  forma  de  comunicación es SOAP, la cuestión que se plantea es cómo encontrar a las organizaciones  que proporcionan servicios con los que comunicarse. La respuesta es el UDDI.   UDDI, aunque fue creado originalmente por IBM, Microsoft y Ariba, desde su versión 3, la  organización OASIS[14] se encarga de su mantenimiento.     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  API’s  para  publicar  descripciones  de  servicios en el registro, y  métodos de  consulta para buscar descripciones publicadas. Las  API’s de UDDI están especificadas con WSDL y con SOAP Binding, lo que permite acceder a  ellas como servicios Web.     La  especificación  UDDI  tiene  dos  objetivos  esenciales:  (1)  ser  un  soporte  a  los  desarrolladores  para  encontrar  información  sobre  servicios  Web  y  poder  construir  aplicaciones clientes que los invoquen, y (2) facilitar el enlace dinámico de servicios Web,  permitiendo  consultar  referencias  y  acceder  a  servicios  de  interés.  La  información  en  un  registro UDDI se almacena en ficheros XML con una estructura jerárquica. Los elementos  básicos de esta estructura son:   • BusinessEntity: Es el elemento “top‐level”, describe un negocio o una entidad que ha  registrado un servicio en UDDI.   • 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  negocio y con la información de binding. Soporta la asignación de categorías al servicio  Web (industria, productos, códigos geográficos, etc.).   • BindingTemplate:  Describe  la  información  técnica  necesaria  para  enlazar  con  un  servicio Web en particular. Este elemento soporta el nombrado de un servicio Web y  su asociación con una entidad de negocio e información de binding. La información de  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   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008    •

tModel:  Estructura  de  metadatos  genérica  para  representar  cualquier  concepto  o  construcción  (definiciones  de  protocolos,  ficheros  WSDL,  XML  Schemas,  espacios  de  nombres, esquemas de categorías, etc.).  

Figura 14. Estructura de datos UDDI  Conceptualmente, la información proporcionada por una organización que ofrece servicios  Web en un registro UDDI consta de tres componentes:   • Sección  Blanca:  Es  muy  similar  a  la  información  que  aparece  en  un  directorio  telefónico, que incluye dirección, contacto y otros identificadores conocidos. • Sección Amarilla: Es muy  similar a su equivalente telefónico, e incluye  categorías de  catalogación  industrial  tradicionales,  ubicación  geográfica,  etc.  Mediante  el  uso  de  códigos y claves predeterminadas, los proveedores de servicios se pueden registrar y  así  facilitar  a  pos‐potenciales  usuarios  de  sus  servicios  la  búsqueda  usando  estos  índices de clasificación.  • Sección  Verde:  Contiene  la  información  técnica  de  los  servicios  ofrecidos  por  los  proveedores.  Se  incluyen  referencias  de  especificaciones  de  servicios  Web  así  como  información  complementaria para los mecanismos diversos de búsqueda basados en  URL.  

3.4.

WS­SECURITY 

  Esta  especificación  maneja  el  cifrado  y  firmas  digitales,  permitiendo  crear  una  aplicación  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 protección con  integridad de mensajes, confidencialidad de mensajes y autenticación simple de mensajes.  La especificación proporciona un conjunto de mecanismos para ayudar a desarrolladores  de servicios web a asegurar el intercambio de mensajes SOAP. Estos mecanismos básicos  de  seguridad  pueden  combinarse  de  varias  formas  para  acomodar  una  variedad  de  modelos de seguridad usando una variedad de tecnologías de cifrado.    Estos modelos de seguridad se describen en [15]  y se resumen a continuación:   • Modelo  de Seguridad  de  Mensajes:  Especifica un  modelo de seguridad  de  mensajes  abstracto  en  términos  de  seguridad  de  tokens  combinado  con  firmas  digitales  para 

26   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008   

•

•

proteger  y  autenticar  mensajes  SOAP.  Los  tokens  de  seguridad  afirman  validez  y  pueden ser usados para afirmar el enlace entre los secretos de autenticación o claves  y  las identidades de seguridad.   Protección  de  Mensajes:  Proteger  el  contenido  del  mensaje  de  ser  divulgado  (confidencialidad)  o  modificado  sin  detección  (integridad)  son  las  principales  preocupaciones de la seguridad. Esta especificación provee un medio para proteger un  mensaje  por  cifrado  y/o  firma  digital  de  un  cuerpo,  una  cabecera  o  cualquier  combinación  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  diseñados para soportar múltiples firmas, potencialmente por múltiples actores/roles  SOAP y para son extensibles para soportar formatos de firma adicional.   Demandas  pérdidas  o  invalidas:  Un  recipiente  de  mensajes  debe  rechazar  mensajes  conteniendo firmas inválidas, demandas de mensajes perdidos o mensajes que tienen  valores  inaceptables.  Dichos  mensajes  son  no  autorizados  (o  malformados).    Esta  especificación provee una forma flexible para que el productor de mensajes haga una  demanda  sobre  las  propiedades  de  seguridad  asociando  cero  o  más  tokens  de  seguridad con el mensaje.  

  Hay tres problemas principales involucrados en la seguridad del intercambio de mensajes  SOAP, y los WS‐Security proveen respuestas para todo ellos, pero no directamente. Es de  hecho,  una  especificación  que  habla  no  sobre  cómo  proteger  el  mensaje,  sino  como  permitir al receptor que conozca cómo has protegido el mensaje.  El  primer  problema  es  identificar  y  autenticar  el  cliente.  Porque  hay  muchas  formas  diferentes de crear tokens de seguridad, WS‐security no especifica un medio en particular,  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  del mensaje para procesar.  El  segundo  problema  es  asegurar  la  integridad  del  mensaje.  WS‐Security  usa  firmas  digitales  para  eso,  empleando  la  especificación  de  firmas  XML  mas  que  inventando  algo  nuevo.  La  firma  XML  es  una  recomendación  del  W3C  que  provee  un  mecanismo  para  firmar digitalmente documentos XML.  El  tercer  problema  está  en  mantener  el  mensaje  seguro  y  evitar  que  sea  escuchado  ilegalmente mientras esta en tránsito. Una vez más, WS‐Security emplea otro estándar del  W3C, el cifrado XML, que proporciona un mecanismo para cifrar documentos XML.  WS‐Security define como agregar firmas XML y cabeceras de  cifrado XML para mensajes  SOAP. En la siguiente figura se muestra como se integra WS‐Security a SOAP.   

27   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008   

  Figura 15. WS‐Security integrado con SOAP   

3.5.

WS­POLICY  Esta especificación amplia el WS‐Security, permitiendo detallar más específicamente cómo  y por quien un servicio puede ser usado.  El framework WS‐Policicy, es una especificación que permite a un servicio web tener un  conjunto de reglas que deben ser resueltas, o consumidas. Los autores de clientes de  servicios web deben entonces estudiar la información de las políticas para ver si pueden o  no adherirse a estas políticas. Así, un cliente no podría ser inscrito para acceder  simplemente a un servicio web que tenga una política que requiere que todos los  mensajes sean encriptados o firmados de alguna manera.  El W3C describe el modelo de SW‐POLICY en [16], el cual consta de :  • Policy  Assertion  (Política  de  aserción)  una  política  de  aserción  identifica  un  comportamiento que es un requerimiento (o capacidad) de un tema, indica semántica  de dominio especifico (por ejemplo, seguridad, transacciones) y esperan ser definidas  en especificaciones separadas y de dominio especifico.     • Policy  Alternative  (Política  alternativa)  una  política  alternativa  es  una  construcción  lógica  que  representa  una  colección  potencialmente  vacía  de  políticas  de  aserción.  Una  política  sin  aserciones  indica  sin  comportamiento.  Una  política  con  una  o  más  aserciones indica comportamiento implicado para aquellas y solo aquellas aserciones.    El  vocabulario  de  una  política  alternativa  es  un  conjunto  de  todos  los  tipos  de  aserciones  dentro  de  la  alternativa.  El  vocabulario  de  una  política  es  un  conjunto  de  todos los tipos de aserciones usados en todas las políticas alternativas en la política.  Una aserción cuyo tipo es parte del vocabulario de una política pero o está incluido en  una alternativa es explícitamente prohibido por la alternativa.  Las  aserciones  dentro  de  una  alternativa  no  son  ordenadas,  y  los  aspectos  como  el  orden en la cual es comportamiento es aplicado a un sujeto están mas allá del alcance  de esta especificación.   • Política:  A  nivel  abstracto  una  política  es  una  colección  potencialmente  vacía  de  políticas  alternativas.  Una  política  con  cero  alternativas  no  contiene  opciones;  una 

28   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008   

•

3.6.

política con una o más alternativas indica selección en requerimientos (o capacidades)  dentro de la política.  Las  alternativas  no  son  ordenadas,  y  así  los  aspectos  tales  como  preferencias  entre  alternativas en un contexto dato van más allá de esta especificación.  Web  services:  Aplicado  en  el  modelo  de  servicios  web,  una  política  es  usada  para  transportar condiciones en una interacción entre dos servicios web. La satisfacción de  aserciones  en  la  política  usualmente  da  como  resultado  un  comportamiento  que  refleja  estas  condiciones.  Típicamente  el  proveedor  de  un  servicio  web  expone  una  política  para  transportar  condiciones,  bajo  las  cuales  proporciona  el  servicio.  Un  solicitante puede usar esta política para decidir si utiliza o no el servicio. Un solicitante  puede escoger cualquier alternativa puesto que cada una, es una configuración válida  para la interacción  con el servicio, pero un solicitante debe escoger solo una simple  alternativa para una interacción con un servicio puesto que cada uno representa una  configuración alternativa. 

WS­I  Aunque los servicios web se supone fueron diseñados para la interoperatibilidad, en la  actualidad hay bastante flexibilidad en las especificaciones, y que las interpretaciones  entre diferentes implementaciones puede causar problemas. WS‐I proporciona un  conjunto de estándares y prácticas para prevenir estos problemas, así como pruebas  estandarizadas para verificar si hay problemas.  El primer desafío es comprender el problema de la interoperatibilidad y su importancia en  el mundo de los servicios web. Los servicios web hoy son construidos usando una compleja  familia de tecnologías relacionadas y estándares, que generan muchas fuentes de temas  relacionados con la interoperatibilidad.  El WS‐I definido en el Basic Profile Version 1.0 por el Web Service Interoperatibily  Organización [17], consiste de un conjunto de especificaciones de servicios web no  propietarios, junto con aclaraciones y enmiendas a esas especificaciones que promueven  la interoperatibilidad.   

3.7.

WS­BPEL   Es un lenguaje de composición de Servicios Web Orientado a Procesos. Se basa en WSDL y  de hecho un proceso WS‐BPEL puede ser expuesto a través de su propio WSDL y por tanto  ser  invocado  como  cualquier  otro  Servicio  Web  (permitiendo  la  reutilización  de  los  mismos).  Nació  como  combinación  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  prácticas  de  los  mismos  (debido  a  que  el  paradigma  de  utilización  de  ambos  es  distinto  y  a  veces  de  lugar  a  situaciones  de  construcción  sobrelapadas).  WS‐BPEL define un conjunto de tareas básicas para la composición de servicios web:  • Tareas  de  Invocación  (Invoke):  Invocación  de  operaciones  one‐way  o  request‐ response en un servicio web.  • Tareas  de  Recepción  (Receive):  Permite  el  bloqueo  de  un  proceso  a  la  espera  de  llegada de un mensaje. 

29   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008    •

Tareas  de  Respuesta  (Response):  Permite  enviar  un  mensaje  en  respuesta  a  un  mensaje recibido previamente.  Tareas de Espera (Wait): Permite la espera durante un tiempo del proceso.  Tareas de Asignación (Assign): Permite copiar datos de un lugar a otro.  Tareas de Lanzamiento (Throw): Permite indicar que ha ocurrido un error.  Tareas de Finalización (End): Permite finalizar la orquestación de la instancia en curso. 

• • • •   Además, las tareas estructuradas son utilizadas para combinar las primitivas en otras más  complejas:  • Tareas secuenciales (sequence): Define un orden secuencial de tareas.  • Tareas  de  decisión  (switch):  Permite  seleccionar  un  camino  en  particular  en  base  a  una condición.  • Tareas de elección: Permite bloquear y esperar la llegada de un mensaje o establecer  un tiempo límite de espera (timeout). Cuando uno de los eventos ocurre, se ejecutan  las tareas designadas.  • Tarea repetitiva (While): Permite repetir un grupo de tareas mientras se cumpla una  determinada condición.  • Tareas paralelas: Permite paralelizar la ejecución de cierto grupo de tareas.    WS‐BPEL  trata  todos  los  estados  como  una  colección  de  tipos  de  mensajes  WSDL.  Esa  colección  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  computación  temporal  de los mismos. Asimismo, la comunicación se define a través de los PortType de los WSDL.    WS‐BPEL sostiene la idea de un contenedor para cada tarea en el flujo definido, cada uno  de  los  cuales  tiene  una  definición  de  esquema.  Así,  un  mensaje  se  corresponde  a  un  contenedor,  que  básicamente  es  un  servicio  web  con  información  adicional  sobre  como  procesarlo, posibles pre‐condiciones y post‐condiciones.    De modo gráfico, un proceso definido en WS‐BPEL tendría la siguiente forma: 

Figura 16 Proceso WS‐BPEL 

30   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008    Todos  los  accesos  a  datos  y  manejos  de  los  mismos  en  WS‐BPEL  es  definido  utilizando  estándares  como  XPath  y  XSLT,  además  de  basarse  en  los  contratos  de  servicios  establecidos por medio de los WSDL.  Durante  la  ejecución  de  un  proceso  se  pueden  establecer  más  de  una  conversación  con  servicios  externos,  por  lo  que  es  necesario  establecer  mecanismos  a  nivel  de  aplicación  para corresponder los mensajes y conversaciones con las instancias de procesos que sean  objetos  de  los  mismos.  Para  ello,  WS‐BPEL  ofrece  lo  que  se  conoce  como  “Correlation  Sets”  o  Grupos  de  Correlaciones.  Estos  son  conjuntos  de  propiedades,  que  juntos  sirven  para  definir  una  conversación  a  nivel  de  aplicación  dentro  de  una  instancia  de  proceso.  Básicamente  son  identificadores  únicos  de  instancias  de  proceso,  que  permite  saber  en  todo momento que instancia corresponde a qué mensaje recibido o enviado a través del  mismo.  WS‐BPEL  puede  ser  utilizado  tanto  para  orquestación  de  servicios  (llamadas  a  procesos  ejecutables; entendiendo como tal las llamadas a servicios y la especificación de como se  llevan  a  cabo)  como  para  coreografía  de  servicios  (llamadas  a  procesos  abstractos;  entendiendo como tal los mensajes públicos a intercambiar entre dos o más partes).  Por  lo  general,  la  implementación  de  WS‐BPEL  varía  según  el  fabricante  y  de  hecho  algunos  lo  interpretan  como  un  Script  XML  que  puede  ser  ejecutado  con  un  motor  específico; mientras que otros lo interpretan como un lenguaje de intercambio. La última  especificación,  la  2.0  incluye  nuevas  características  como  inicialización  de  variables,  transformación  XSLT  de  variables,  acceso  XPath  a  datos  de  variables,  etc.  Esta  especificación ha sido aprobada el 31/01/2007 por OASIS y se la documentación de este  estándar está disponible en [18]. 

IV.

REST UNA PROPUESTA ALTERNATIVA A SOAP  En los últimos años se ha popularizado un estilo de arquitectura Software conocido como  REST  (Representational  State  Transfer).  Este  nuevo  estilo  ha  supuesto  una  nueva  opción  de estilo de uso de los Servicios Web.  Los  Servicios  Web  basados  en  REST  intentan  emular  al  protocolo  HTTP  o  protocolos  similares  mediante  la  restricción  de  establecer  la  interfaz  a  un  conjunto  conocido  de  operaciones  estándar  (por  ejemplo  GET,  PUT,…).  Por  tanto,  este  estilo  se  centra  más  en  interactuar con recursos con estado, que con mensajes y operaciones.  Un ejemplo de utilización de SOAP y REST es Amazon, quien posee ambos estilos de uso de  sus  servicios  Web.  Pero  el  85%  de  sus  clientes  prefieren  la  interfaz  REST.  A  pesar  de  la  promoción que las empresas han invertido para ensalzar a SOAP, parece que es evidente  que los desarrolladores prefieren, en algunos casos, la aproximación más sencilla, REST.  

4.1.

DEFINICION  El  autor  de  [19]  indica  que  REST  es  un  estilo  de  arquitectura  de  software  para  sistemas  hipermedias distribuidos tales como la Web. El término fue introducido en la tesis doctoral  de Roy Fielding[20] en 2000, quien es uno de los principales autores de la especificación de  HTTP.   En realidad, REST se refiere estrictamente a una colección de principios para el diseño de  arquitecturas  en  red.  Estos  principios  resumen  como  los  recursos  son  definidos  y  diseccionados.  El  término  frecuentemente  es  utilizado  en  el  sentido  de  describir  a  cualquier interfaz que transmite datos específicos de un domino sobre HTTP sin una capa 

31   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008    adicional, como hace SOAP. Estos dos significados  pueden  chocar o incluso solaparse. Es  posible  diseñar  un  sistema  software  de  gran  tamaño  de  acuerdo  con  la  arquitectura  propuesta por Fielding sin utilizar HTTP o sin interactuar con la Web. Así como también es  posible  diseñar  una  simple  interfaz  XML+HTTP  que  no  sigue  los  principios  REST,  y  en  cambio seguir un modelo RPC.   Cabe destacar que REST no es un estándar, ya que es tan solo un estilo de arquitectura.  Aunque REST no es un estándar, está basado en los estándares HTTP, URL, Representación  de los recursos (XML/HTML/GIF/JPEG/…) y Tipos MIME (text/xml, text/html, …). 

4.2.

PRINCIPIOS  Los objetivos de este estilo de arquitectura se listan a continuación:   • Escalabilidad  de  la  interacción  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  través  de  la  Web:  estaciones  de  trabajo,  sistemas  industriales, dispositivos móviles,…   •

Generalidad  de  interfaces.  Gracias  al  protocolo  HTTP,  cualquier  cliente  puede  interactuar con cualquier servidor HTTP sin ninguna configuración especial. Esto no es  del todo cierto para otras alternativas, como SOAP para los Servicios Web.  

•

Puesta  en  funcionamiento  independiente.  Este  hecho  es  una  realidad  que  debe  tratarse cuando se trabaja en Internet. Los clientes y servidores pueden ser puestas en  funcionamiento durante años. Por tanto, los servidores antiguos deben ser capaces de  entenderse  con  clientes  actuales  y  viceversa.  Diseñar  un  protocolo  que  permita  este  tipo  de  características  resulta  muy  complicado.  HTTP  permite  la  extensibilidad  mediante  el  uso  de  las  cabeceras,  a  través  de  las  URIs,  a  través  de  la  habilidad  para  crear nuevos métodos y tipos de contenido.  

•

Compatibilidad con componentes intermedios. Los más populares intermediaros son  varios tipos de proxys para Web. Algunos de ellos, las caches, se utilizan para mejorar  el  rendimiento.  Otros  permiten  reforzar  las  políticas  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  interacción,  reforzar  la  seguridad  y  encapsular  otros  sistemas.  

 

 

32   

Edwin Valencia Castillo  

Estado del Arte de los Servicios Web  2008   

REFERENCIAS BIBLIOGRAFICAS  [1]  [2]  [3]  [4] 

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

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

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

[19]  [20] 

W3C World Wide Web Consortium. (2004). "Web Services Architecture."   Accedido el  16/03/2008, 2008, de http://www.w3.org/TR/2004/NOTE‐ws‐arch‐20040211/.  W3C World Wide Web Consortium. (2008). "Guía Breve de Servicios Web."   Accedido el  11/02/2008, de http://www.w3c.es/divulgacion/guiasbreves/ServiciosWeb.  IBM. (2008). "Standards and Web services."   Accedido el 16/03/2008, de  http://www.ibm.com/developerworks/webservices/standards/.  M. Endrei, J. Ang, A. Arsanjani, S. Chua, P. Comte, P. Krogdahl, M. Luo, and T. Newling,  Patterns: Service‐Oriented Architecture and Web Services: International Business Machines  Corporation RedBooks, 2004.  J. McGovern, S. Tyagi, M. Stevens, and S. Matthew, Java Web Services Architecture. San  Francisco: Morgan Kaufmann, 2003.  I. Garcia, M. Polo, F. Ruiz, and M. Piattini, Servicios web: Universidad de Castilla‐La  Mancha, 2005.  W3C World Wide Web Consortium. (2001). "Web Service Definition Language (WSDL)."    Accedido el 29/03/2008, de http://www.w3.org/TR/wsdl.  W3C World Wide Web Consortium. (2007). "Web Services Description Language (WSDL)  Version 2.0 Part 1: Core Language."   Accedido el 29/03/2008, de  http://www.w3.org/TR/wsdl20/.  OASIS. (2004). "UDDI Spec TC."   Accedido el 30/3/2008, de http://www.oasis‐ open.org/committees/uddi‐spec/doc/spec/v3/uddi‐v3.0.2‐20041019.htm.  W3C World Wide Web Consortium. (2007). "SOAP Version 1.2."   Accedido el 30/3/2008,  de http://www.w3.org/TR/soap/.  InnoQ. (2006). "Web Services Standards: An overview of the Web services standards  landscape "   Accedido el 23/4/2008, de http://www.innoq.com/soa/ws‐standards/.  W3C World Wide Web Consortium. (2003). "SOAP Versión 1.2 Parte 0: Fundamentos."    Accedido el 30/3/2008, de http://www.w3c.es/Traducciones/es/TR/2003/REC‐soap12‐ part0‐20030624/.  V. Pelechano, "Servicios web. Estandares, extensiones y perspectivas de futuro," 2005.  OASIS. (2007). " OASIS Standards and Other Approved Work."   Accedido el 30/3/2008, de  http://www.oasis‐open.org/specs/index.php.  OASIS. (2004). "Web Services Security."   Accedido, 28/04/2008, de http://docs.oasis‐ open.org/wss/2004/01/oasis‐200401‐wss‐soap‐message‐security‐1.0.pdf.  W3C World Wide Web Consortium. (2006). "Web Services Policy 1.2 ‐ Framework (WS‐ Policy)."   Accedido el 5/5/2008, de http://www.w3.org/Submission/WS‐Policy/.  Web Service Interoperatibily Organizacion. (2004). "Basic Profile Version 1.0."   Accedido el  05/05/2008, de http://www.ws‐i.org/Profiles/BasicProfile‐1.0‐2004‐04‐16.html.  OASIS. (2007). "OASIS Web Services Business Process Execution Language (WSBPEL) TC  Public Documents."   Accedido el 05/05/2008, de http://www.oasis‐ open.org/committees/documents.php?wg_abbrev=wsbpel.  R. N. Marset. (2006). "REST VS WEB SERVICES."   Accedido el 8/4/2008, de  http://www.dsic.upv.es/~rnavarro/NewWeb/docs/RestVsWebServices.pdf.  R. T. Fielding, "Architectural Styles and the Design of Network‐based Software  Architectures." vol. Doctor of Philosophy in Information and Computer Science Irvine:  University of California, 2000.8/4/2008 

   

33   

Edwin Valencia Castillo