WS-Universidad Técnica Federico Santa María

Universidad Técnica Federico Santa María
Departamento de Informática
Programa de Magíster en Tecnologías de la Información

Web Services
Sergio Sánchez R. email: ssanchez@uvm.cl

Ricardo Vásquez V. email: rvasquez@csav.com

Resumen

En la última década los Web Services han tomado un sitial importante dentro del entorno de los
desarrolladores de aplicaciones, por las ventajas que entregan a nivel de distribución de servicios e
integración de sistemas heterogéneos. Por esto el objetivo fundamental de este estudio es dar a conocer los
Web Services de forma conceptual (sin entrar en detalles de implementación) y poder determinar
detalladamente como estos dan respuesta a las problemáticas comunes que subyacen de sus ventajas: manejo
de seguridad, coordinación de procesos y manejo transacciones. Durante este estudio se comprenderá el
funcionamiento de los Web Services, las arquitecturas de componentes propuestas por empresas importantes
para el manejo de las problemáticas planteadas anteriormente y un ejemplo aplicado de publicación simple de
servicios mediante Web Services e integración de sistemas.

1 Introducción

Durante los inicios del desarrollo de las aplicaciones uno de los problemas que mas se trato de
solucionar era que los sistemas fueran independientes de la plataforma de hardware y sistema operativo, lo
que de alguna forma se logra con la aparición de lenguajes de programación que permiten realizar esa
diferencia, como por ejemplo Java. Luego, el ambiente WEB abrió las puertas para generar aplicaciones
muchos más independientes y accesibles desde cualquier parte del mundo, pero aún así existía un problema
que se debía solucionar que era la heterogeneidad de los diferentes sistemas, los cuales estaban escritos en
lenguajes distintos por lo que su interoperabilidad se hacía compleja. Es en este punto donde nace una
solución que se empapa de diversas tecnologías que funcionan, y que de alguna forma solucionan este
problema de comunicación entre aplicaciones que se encuentran en ambientes distribuidos (La WEB) y que se
desarrollan absolutamente de forma distinta. Está solución es conocida como Web Services, también en
muchos textos se realiza una relación directa con SOA (Arquitectura Orientada a Servicios), esto ya que los
Web Services son considerados los servicios bases para su funcionamiento, dejando claro que se podrían
utilizar otros, por esto no es bueno mezclar los conceptos del todo.
En este estudio daremos a conocer los fundamentos de los Web Services y los nuevos problemas que
se les presentan, sobretodo en la integración de sistemas y procesos de negocios. Además se dará a conocer
una aplicabilidad real de la tecnología dentro de una de las empresas nacionales más importantes.

2 Desarrollo del informe

2.1 Aspectos Generales de los Web Services.

Uno de los conceptos, en la última década, que ha tomado importancia en el mundo del desarrollo de
aplicaciones es el de Web Services. Desde el punto de vista más simple, se podría mencionar que los Web
Services son Servicios Web, entendiendo por servicios “programas que pueden ser accedidos por la red” (En
este caso la red sería la WEB). Desde el punto de vista de un desarrollador, un Web Service es un componente
independiente que posee un conjunto de funcionalidades que pueden ser accedidas desde cualquier lugar y
plataforma. Desde cualquier lugar, quiere decir que estarán disponibles dichos servicios a través de un medio
común de comunicación (la WEB). Desde cualquier plataforma, quiere decir que los datos que se reciben y
son enviados por los Web Services son independientes de la plataforma de origen o destino, esto se logra
utilizando para la presentación de los datos el Lenguaje Extendido de Marcas (XML).
El organismo encargado de desarrollar gran parte de los estándares de Internet, denominado W3C
(Word Wide Web Consortium) posee en la actualidad un grupo de investigación especializado en Web

1

Service, lo que demuestra la importancia que tiene dicho concepto dentro de estos últimos años. Este grupo de
trabajo ha entregado una definición formal acerca de los Web Services, la que se presenta a continuación:
“Un Web Service es una aplicación de software identificada mediante una URI (Uniform Resource
Identifier. También se utiliza URL), cuya interfaz es capaz de ser definida, descrita, y descubierta mediante
artefactos XML, y soportar interacciones directas con otras aplicaciones de software usando mensajes basados
en XML y protocolos basados en Internet” [WEB-01].
Consensuando está definición técnica con la visión de los desarrolladores, se puede mencionar que el
Web Service es un componte de software que debe ser definido, descrito y descubierto mediante artefactos
XML. Es bueno dejar claro dentro del concepto técnico que un Web Service no posee interfaces como una
aplicación común, sino que solo publica un conjunto de funcionalidades que podrán ser accedidas por otras
aplicaciones.
Un Web Service se basa en las siguientes tecnologías para dar cumplimiento a las definiciones
entregadas anteriormente [WEB-02]:
Un formato que describa la interfaz del componente (sus métodos y atributos) basado en XML. Por lo
general este formato es el WSDL (Web Service Description Language).
Un protocolo de aplicación basado en mensajes y que permite que una aplicación interactúe con el Web
Service. Por lo general este protocolo es SOAP (Simple Object Access Protocol).
Un protocolo de transporte que se encargue de transportar los mensajes por Internet. Por lo general este
protocolo es el HTTP (Hiper-Text Transport Protocol). Pudieran existir variantes para el transporte, pero
no son del estudio de este documento. Si requiere mayor información ver [TAR-01].
En la figura 1 se da a conocer la forma en que estas tecnologías interactúan para permitir la
comunicación entre un proceso que requiere la utilización de un Web Service y el mismo Web Service.

Explicación Breve del Proceso:
2
1.- Se realiza un registro en el catalogo UDDI (Universal
Description, Discovery, and Integration). Este catalogo esta en
1 formato XML. En palabras simples es como un directorio de
páginas amarillas de Web Services. Este paso es conocido como
3 Publicación.
2.- Se realiza la búsqueda de un Web Service en el Catalogo
UDDI. Este paso es conocido como Búsqueda.
3.- Se obtiene la referencia al Web Service. En la aplicación que
requiere el servicio se crea un Proxy, el cuál es un componente
lógico que emula las interfaces del Web Service, para así
4
permitir su utilización transparente para el desarrollador.
4.- Se establece la comunicación entre el componente que
Figura 1. Interconexión de los requiere el servicio y el Web Service. Esto se realiza utilizando
Componentes para permitir la el protocolo SOAP sobre HTTP regularmente. Este paso es
comunicación mediante Web Services conocido como Interacción.
[TAR-01].

Para una mayor comprensión técnica se definirán, más en detalle, cada una de las tecnologías que
permiten la utilización de Web Service [WEB-03]:
SOAP (Simple Object Access Protocol): protocolo estándar creado por Microsoft, IBM y otros, el cuál se
utiliza para codificar la información de los mensajes de petición y respuesta de los Web Services que se
envían a través de una red. Es un protocolo ligero de mensajes XML. Por lo tanto, este protocolo permite
codificar las llamadas a los métodos de un Web Service y entender como debe codificar el Web Service
el resultado para que el peticionario del servicio lo pueda interpretar.
WSDL (Web Services Description Language): lenguaje desarrollado en forma conjunta por Microsoft e
IBM. Este lenguaje describe la interfaz pública de los Web Service. Está basado en XML y describe la
forma de comunicación, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios
para interactuar con los servicios listados en un catálogo.

Sergio Sánchez R. 2
Ricardo Vásquez V.

UDDI (Universal, Description, Discovery and Integration): es un directorio de Web Services distribuido
y basado en Web que permite que se listen, busquen, y descubran este tipo de componentes de software.
Por último, para concluir este punto, es bueno mencionar que los Web Services no son la solución a
todos los problemas, e idealmente fueron definidos para trabajar dentro los siguientes ámbitos [WEB-02]:
Servicios simples y públicos: se expondrá una funcionalidad simple accesible desde Internet. Ej.: se
puede crear un servicio para entregar la temperatura de una ciudad en particular, al cuál pueden acceder
diferentes aplicaciones.
Integración de Aplicaciones: se usan como extensiones de sistemas ya existentes, para que estos sean
accesibles por aplicaciones y sistemas heterogéneos desarrollados bajo cualquier plataforma y lenguaje y
que participan en procesos comunes.
Sistemas de Grid Computing: la definición de Grid Computing: “es una tecnología innovadora que
permite utilizar de forma coordinada todo tipo de recursos (entre ellos cómputo, almacenamiento y
aplicaciones específicas) que no están sujetos a un control centralizado. En este sentido es una nueva
forma de computación distribuida, en la cual los recursos pueden ser heterogéneos (diferentes
arquitecturas, supercomputadores, clusters...) y se encuentran conectados mediante redes de área extensa
(por ejemplo Internet)” [WEB-03]. En este caso de arquitecturas distribuidas la utilización de Web
Services es muy provechosa sobre todo en el compartimiento de aplicaciones y datos heterogéneos.
En los puntos siguientes se darán a conocer temas relevantes para el trabajo eficiente y efectivo de
los Web Services.

2.2 Seguridad en Web Services

Considerando que los Web Services son componentes de software, es bueno mencionar que su
desarrollo es soportado por el Framework .NET de Microsoft y el Framework J2EE de Sun. Esto es
importante de mencionar ya que existen formas de aplicar seguridad en el desarrollo de los Web Services
utilizando particularidades del entorno de desarrollo y las plataformas en que ellos trabajan (Entiéndase para
este caso plataformas como sistemas operativos y servidores web). Durante este punto no se definirán las
particularidades de los ambientes de desarrollo para la seguridad, pero si desea tener mayor información ver
[WEB-07] y [WEB-08].
Parece razonable considerar el tema de la seguridad en el trabajo de Web Services, ya que como
principio básico sería importante tener seguridad que al servicio al cuál accedo a buscar información sea
realmente el servicio que necesito, además que las respuestas que se entreguen sean realmente las correctas.
Claramente la seguridad tiene un mayor trasfondo que lo mencionado anteriormente, pero esa incertidumbre
pone en el tapete la duda sobre el trabajo con estos componentes. Con respecto al punto de la seguridad la
W3C en la especificación de la Arquitectura de Web Services (WSA) indica algunos requisititos que se deben
cumplir entorno a la seguridad, los cuales son:
Tratar la seguridad de los Web Services a través de dominios y plataformas distribuidas. Para mayor
detalle de este requisito ver punto AC006 de la [WEB-09].
Permitir la protección de privacidad para el cliente de un Web Services a través de múltiples dominios y
servicios. Para mayor detalle ver punto AC020 de la [WEB-09].
Estas indicaciones apuntan directamente a considerar que uno de los fuertes de los Web Services es
su trabajo en ambientes distribuidos, lo que entrega problemáticas por ejemplo como la suplantación. Y el
otro punto está orientado a entender que debe existir una seguridad para los clientes que acceden a estos
servicios, entendiendo que el cliente debe confiar plenamente en que la contraparte solicitada es realmente lo
esperado, esto también sucede al revés, en los casos que los servicios solicitados no sean públicos.
Entorno a estos requisitos Microsoft e IBM durante el año 2002 trabajaron en la definición de una
arquitectura de seguridad para los Web Services, la cuál se muestra en la figura 2, actualmente esta iniciativa
esta siendo coordinada por OASIS [WEB-10].

Ricardo Vásquez V.

Cada uno de los componentes de este stack
3 serán descritos en detalle más adelante
demostrando que cumple con las especificaciones
básicas de seguridad exigidas por la W3C. A
2
continuación se entrega una visón general de las
capas que conforman esta arquitectura:
1 1.- Es el modelo de seguridad de mensajes, está
capa provee lo básico para las demás capas de la
arquitectura.
2.- Es la Policy Layer (Capa Política) la cuál
incluye una política de Web Service de punto final
Figura 2. Stack de Protocolos de la Arquitectura de (WS-Policy), un modelo de confianza (WS-
Seguridad Definida por Microsoft e IBM. [WEB-11] Truest), y un modelo de privacidad (WS-Privacy).
Juntas estas especificaciones iniciales proporcionan la base sobre la cual se puede trabajar para establecer
servicios interoperables seguros de Web Services a través de dominios de confianza.
3.- Está capa esta determinada para trabajar con los clientes, partners, y organizaciones estándares (Customer
Layer) para proveer a continuación especificaciones de seguridad federada lo cuál incluye: conversación
segura (WS-SecureConversation), confianza federada (WS-Federation) y autorización (WS- Authorization).
Está explicación de la arquitectura permite determinar que cumple con los requisitos solicitados por
W3C entorno a considerar la seguridad de los Web Service en ambientes distribuidos (Según figura 2 punto 1
y 2) y dar privacidad a los clientes en estos ambientes (Según figura 2 punto 3). A continuación se describen
en detalle cada uno de los protocolos definidos en las diversas capas:
WS-Security [WEB-11]: aborda el tema de la seguridad haciendo uso de las especificaciones y los
estándares existentes. Con ello se evita la necesidad de definir una solución de seguridad completa en
WS-Security. La industria ha resuelto muchos de estos problemas. Kerberos y X.509 se ocupan del tema
de la autenticación. Asimismo, X.509 emplea la infraestructura de clave pública (PKI) existente en la
administración de claves. XML Encryption y XML Signature describen distintas formas de cifrar y
firmar el contenido de los mensajes XML. XML Canonicalization analiza los modos de hacer que XML
esté preparado para el proceso de firma y cifrado. Lo que WS-Security aporta a las especificaciones
existentes es un marco en el que incorporar estos mecanismos a un mensaje SOAP. Esta tarea se realiza
en un modo neutral de transporte.

Figura 3 Proceso Común al utilizar WS-Security

WS-Policy [WEB-04]: establece como los solicitantes y proveedores del servicio pueden especificar
requisitos que determinen cómo debe llevarse a cabo la comunicación. Generalmente esos requisitos en
su mayoría hacen referencia a políticas de seguridad: Mecanismos de autentificación, algoritmos
criptográficos, longitudes de claves, tratamientos de información personal, etc.
WS-Trust [WEB-04]: especifica mecanismos para establecer diferentes modelos de confianza.
WS-Privacy [WEB-04]: proporcionará un marco de trabajo para generar sentencias sobre requerimientos
y preferencias de privacidad de información.
WS-SecureConversation [WEB-04]: proporcionar mecanismos para contextos de seguridad para el
establecimiento de comunicación autenticada. El contexto de seguridad comprende aspectos tales como
el establecimiento de claves de sesión, claves derivadas, algoritmos, etc.
Ricardo Vásquez V.

WS-Federation [WEB-04]: componente que tiene que ver con la federación de cuentas y gestión de
identidad. Este actualmente posee soporte para SAML (Security Assertions Markup Language),
estándar de OASIS para la autentificación de usuarios.
WS-Authorization [WEB-04]: proporcionará mecanismos para descubrir los requerimientos de
declaración/privilegio de un servicio.
Esta arquitectura es una de las alternativas consideradas para entregar seguridad en los Web Services,
dejando claro que pueden existir otras, ya que está es dirigida por Microsoft e IBM solamente.
En resumen, es bueno considerar en este tipo de arquitecturas distribuidas poner énfasis en la
seguridad, por lo que, está arquitectura mostrada responde a los requisitos necesarios definidos por W3C, y
cualquier iniciativa que aparezca deberá considerar dichos requisitos.

2.3 Coordinación y Transacciones en Web Services

Una de las aplicaciones interesantes en las cuales pueden ser utilizados los Web Services es para la
implementación de procesos de negocios empresariales.
Los Web Services han permitido avanzar en permitir el intercambio de información entre
organizaciones diferentes que implementan sus procesos de negocios de forma distinta (B2B, Business to
Business). Estos servicios se utilizan para comunicar las distintas organizaciones de forma independiente de
las soluciones de negocio adoptadas por cada una de ellas, permitiendo de esta forma a las empresas ofrecer
su “información” destinada a los distintos “procesos de negocio”. Así es posible que otras organizaciones que
quieran acceder a dicha información e interactuar con esta organización puedan hacerlo mediante el acceso a
los Servicios que hubiese ofrecido la organización para ese efecto. De tal modo, es posible apreciar el
intercambio de información de una manera totalmente automática, lo cual permite obtener ahorros en los
costos y una mayor eficiencia en los procesos.
En el escenario descrito anteriormente, los Web Services ofrecen a las actividades de negocio una
plataforma excelente para realizar la comunicación entre las organizaciones. Muchos de estos procesos de
negocios son muy complejos por lo que un solo Web Service es insuficiente para completar el proceso, por lo
que en la realidad se necesita acceder a varios servicios los cuales deben ser supervisados y “coordinados”
para realizar dichos intercambios de información. Es por tal razón, que se necesitan mecanismos que permitan
realizar la coordinación para estos complejos procesos que surgen de las distintas entidades. Dentro de los
mecanismos existentes en la actualidad se encuentran un conjunto de especificaciones llamadas WS-
Cordination y WS-Transaction que han sido desarrollados por IBM, Microsoft y BEA [WEB-12].

2.3.1 Coordinación

El mundo de los Web Services no se encuentra libre de complicaciones que pueden ser producidas
por ataques (al compartir un medio masivo como Internet), fallos de red, problemas de coherencia de la
información en todo el sistema, etc. Por tanto, un punto de vital importancia para los Web Services que
implementan complejos procesos de negocio es mantener la coherencia y consistencia de la información en
todos los sistemas que forman parte de la red distribuida de información a la cual pertenecen. Para conseguir
la coherencia y consistencia se necesita utilizar mecanismos de Coordinación.
La coordinación permite que todas las entidades que participan en el proceso de negocio tomen parte
en el mismo de forma ordenada, para que los resultados sean consistentes con todo el sistema de información
en todo momento [WEB-12].
Los procesos de negocios a coordinar pueden ser muy variados, por lo cual pueden causar que un
determinado protocolo de coordinación sea no válido. Por este motivo se han estado desarrollando variados
mecanismos que intentan ser altamente genéricos para que las distintas modificaciones o cambios que son
necesarios para coordinar los procesos de negocios puedan ser incluidos sin problemas. El mecanismo
genérico descrito para realizar la coordinación en Web Services es la especificación denominada WS-
Coordination.
WS-Coordination proporciona una infraestructura que permite dar soporte a concretas formas de
coordinación (protocolos de coordinación). Esta especificación fue publicada el año 2002 por IBM, Microsoft

Ricardo Vásquez V.

y BEA Systems. Entre los objetivos generales que describe esta especificación podemos mencionar los
siguientes [WEB-13]:
Método que permite introducir identificadores únicos en los mensajes intercambiados entre los servicios
(Coordination Context, Cabecera SOAP).
Método para informar del rol que asume cada participante en una conversación (Activation Interface).
Método para que los Web Services registren su interés en participar de la conversación (Registration
Interface).
Estos objetivos son logrados de forma independiente del protocolo de coordinación ejecutado por los
participantes.
WS-Coordination permite
establecer varios tipos de
coordinación los cuales pueden
verse en la figura 5. Estos tipos
de coordinación pueden ser
implementados dependiendo de
de la complejidad del proceso
Figura 4 Tipos de Coordinación. de negocio.

Entre los componentes que se encuentran en WS-Coordination podemos mencionar las abstracciones
utilizadas en la descripción de las interacciones entre un coordinador y sus participantes [WEB-13]:
Coordination Protocol: Corresponde al conjunto de reglas a las cuales una conversación debe ajustarse al
momento de su desarrollo (descripción del protocolo de coordinación).
Coordination Type: Corresponde a la especificación del tipo de protocolo utilizado, vale decir, un valor
de coordination type representa una conversación concreta.
Coordination Context: corresponde a la estructura de datos utilizada para detallar la conversación a la
cual pertenecen los mensajes SOAP intercambiados.
En cuanto a las formas de interacción que es posible encontrar entre un coordinador y sus
participantes podemos mencionar [WEB-13]:
Activación: esta interacción ocurre cuando un participante solicita a un coordinador la creación de un
nuevo contexto de coordinación, vale decir, la creación de una nueva conversación.
Registro: Esta interacción ocurre cuando un participante se registra en un coordinador para participar en
una conversación.
Interacciones específicas del protocolo: Estas interacciones ocurren cuando el coordinador y los
participantes registrados intercambian mensajes específicos del protocolo de coordinación de
conversación.
En resumen WS-Coordination aporta la capacidad de registrar a los sistemas que tomaran parte en un
proceso de negocio y generar un contexto con información (tanto del registro como de la coordinación) para
entregarla a los otros sistemas participantes en el proceso de negocio.

2.3.2 Transacciones

Hemos hablado sobre la necesidad de mantener la información de forma consistente en todos los
sistemas que participan del entorno distribuido. Para lograr este propósito es necesario junto con la
coordinación manejar otro concepto que tiene su origen en las base de datos. Este concepto al cual nos
referimos es el de Transacción.
Una transacción permite obtener consistencia debido a que el sistema envuelve los cambios de
información que se realizan en el mismo como una unidad atómica en dicha transacción. Esto quiere decir que
si la transacción por alguna razón falla el intercambio de información contenida en la transacción no toma
efecto, quedando todos los sistemas participantes del entorno distribuido de manera coherente y consistente
con la situación al momento anterior a iniciarse la transacción fallida. Ahora si la transacción resulta exitosa,
todos lo cambios serán propagados a los sistemas participantes del entorno distribuido. En resumen una
transacción es una operación o un conjunto de operaciones, que se llevarán a cabo si la operación se realiza de

Ricardo Vásquez V.

forma completa y obteniendo resultados esperados, o se descartarán dichas operaciones en caso de no
satisfacer todos los requisitos exigidos a la misma [WEB-12].
Hoy en día, la complejidad de los procesos de negocio determina que el tiempo de ejecución que
tienen los servicios que atienden a los procesos sea muy elevado, además adicionalmente estos servicios se
encuentran ubicados en un entorno como la Web, la cual se encuentra siempre amenazada por continuos y
múltiples tipos de fallas (caídas de servidores, saturación en petición de servicios, fallas de conexión, etc.), las
cuales generan como resultado que el problema de la coherencia y consistencia de la información se
transforme en algo bastante común.
Entonces para lograr que los procesos de negocios puedan ser implementados con Web Services, ya
mencionamos en el punto anterior la existencia de un componente que apoya a la coordinación (WS-
Coordination), pero este componente también se ayuda de un segundo componente el cual permite manejar el
concepto de transacciones para los Web Services, el cual corresponde a la especificación de WS-Transaction.
WS-Transaction se apoya en la infraestructura de WS-Coordination, la cual modela el contexto de la
transacción. Esta especificación tiene su origen como ya lo habíamos mencionado en el contexto de las bases
de datos y es utilizado en entornos distribuidos cuando dos o más Web Services están involucrados en una
interacción (conversación) y las operaciones invocadas no son independientes. El objetivo final es que todas
las operaciones sean ejecutadas con éxito, o en caso contrario ninguna de ellas sea ejecutada. Las
transacciones en Web Services poseen algunas diferencias notables con las generadas en bases de datos, entre
las cuales podemos mencionar que el tiempo que cuesta en completar un transacción en Web Services es
muchísimo más largo de lo que toma en una base de datos debido a que en los Web Services es posibles
ejecutar complejos procesos de negocios; otra diferencia es que se amplia la variedad de recursos y
operaciones a aplicar sobre ellos [WEB-12].
La especificación de WS-Transaction fue publicada el año 2002 por IBM, Microsoft y BEA. La cual
especifica un protocolo estándar para la ejecución de transacciones en entornos de Web Services. La
especificación establece dos tipos de transacciones [WEB-13]:
Atomic Transactions: Corresponde a transacciones atómicas o de corta duración, en las cuales se
conserva la idea de las propiedades ACID (Atomicidad, Coherencia, Aislamiento y Durabilidad) en un
sentido muy estricto, lo que resulta en que todas las operaciones dentro de una transacción se ejecutan
con éxito o no se ejecuta ninguna. Este tipo de transacciones por lo general resultan en entornos muy
confiables.
Business Activities: Corresponde a transacciones de larga duración en la cual las propiedades ACID son
flexibilizadas. Las operaciones son todas invocadas a los participantes, los cuales después de su ejecución
informan al coordinador si estas operaciones han sido completadas con éxito. Si alguna de estas
operaciones falla, se requiere la ejecución de operaciones de “compensación” ya que acá los cambios son
permanentes desde el principio, por tanto si la operación falla se deberá realizar operaciones que permitan
deshacer los cambios.
De los dos tipos de mecanismos de transacción, el más utilizado para implementar procesos de
negocios complejos es por transacción Busines Activities.

En la figura podemos esquematizar el stack para
Web Services considerando las especificaciones
de WS-Coordination y WS-Transaction para
tratar los aspectos de coordinación de las
operaciones que estos realizan.

Figura 5 Stack para Web Services considerando
coordinación y transacciones.

2.4 Aplicación práctica de Web Services en un entorno empresarial

Para ratificar todo lo detallado en esta monografía referente a los Web Services, se presentará una
aplicación concreta en la cual pueden ser utilizados Web Services en un entorno empresarial.
Ricardo Vásquez V.

El entorno empresarial elegido ha sido la Compañía Sudamericana de Vapores (en adelante CSAV),
la cual corresponde a una empresa chilena de transporte marítimo, la que actualmente es la más grande de
Latinoamérica.
CSAV fue fundada en 1872 en el Puerto de Valparaíso (Chile), siendo una de las compañías más
antiguas del mundo. En el comienzo las actividades de CSAV consistían exclusivamente de servicios de
cabotaje en la costa pacífico Chilena, pero muy rápidamente se fueron extendiendo a lo largo de la costa
Oeste de Sudamérica hasta el Canal de Panamá. Posteriormente extendió la esfera de sus operaciones a los
Estados Unidos, Europa, el lejano Oriente y Japón, al Sudeste Asiático/islas del Pacífico y la costa este de
Sudamérica.
CSAV opera a través de los cinco continentes, ofreciendo servicio de "línea", por los cuales es capaz
de proveer tráficos permanentes a ciertos puertos, itinerarios fijos y naves preparadas para transportar un gran
número de contenedores y una alta variedad de carga convencional. Asimismo, CSAV posee barcos
especialmente diseñados para carga congelada, vehículos, carga a granel y productos forestales. Otorgando un
servicio "puerta a puerta", a cualquier destino, el cual normalmente es conducido en conjunto con las
subsidiarias de CSAV: Sudamericana Agencias Aéreas y Marítimas S.A. SAAM, como una agencia marítima
de transporte de mercancías, y COSAN, Terminal de contenedores en Santiago [WEB-14].
CSAV debido a su operación y complejo proceso de negocio que involucra múltiples agencias en
todo el mundo, las cuales apoyan el proceso de transporte y con las cuales requiere tener una estrecha relación
de intercambio de información. Actualmente CSAV requiere mejorar su plataforma de intercambio de
información con sus agencias relacionadas. Para lograr este propósito se puede implementar un proyecto
tecnológico para lograr el intercambio de información mediante el uso e implementación de una plataforma de
Web Services.
Esta plataforma tecnológica de Web Services permitirá una mayor visibilidad de las agencias, las
cuales serán capaces de conseguir información relativa a sus reservaciones (booking), Bill of Ladings (BL’s)
y Notas de Corrección de fletes (FCN). La plataforma de Web Services permitirá integrar las distintas
agencias con CSAV, las cuales se encuentran en distintas plataformas tecnológicas. Además permitirá
intercambiar grandes volúmenes de datos con un bajo consumo de tráfico de red ya que los Web Services
trabajaran sobre Internet.
Para comenzar el proyecto de esta plataforma podemos definir un piloto con tres Web Services
destinados al intercambio de información entre CSAV y sus agencias relacionadas. Los Web Services a
implementar son:
GET_BOOKINGS: Este servicio tendrá la responsabilidad de entregar los documentos de reservas de
carga. Para obtener los documentos de carga será necesario ingresar ciertos parámetros que permitirán
obtener la información necesaria y que usualmente es obtenida por las agencias.
Especificación del Web Service.
Service Name Get_Bookings
Type Web Service
Location http://<Server>/AgencyServices/AgencyServices.asmx
Parámetros para el Web Service GetBookings.
Nombre Tipo Largo Descripción Req.
1 userId Carácter 15 Código de Usuario S
2 password Carácter 20 Password de Usuario N
3 systemId Carácter Sin uso N
4 xmlFilters Carácter Estructura xml con los valores para filtros. S
5 xmlBookings Carácter Estructura Xml con los Bookings N
6 errorCode Entero Código de Error N
7 errorMessage Carácter 150 Mensaje de Error N

GET_BLANDFCN: Este servicio tendrá la responsabilidad de entregar los Documentos correspondientes
a los Bill of Lading (manifiesto de embarque internacional) y a las FCN que son las correcciones de
Fletes que son hechas a los Bill of Lading en el caso que exista un error o a petición de un cliente.

Ricardo Vásquez V.

Service Name Get_BlsAndFCNs
Type Web Service
Parámetros para el Web Service Get_BlAndFcns.
5 xmlDocuments Carácter Estructura Xml con los Documentos N

GET_BOOKINGLEGS: Este Servicio tendrá la responsabilidad de entregar la información relativa a los
tramos que hará una determinada reserva de carga o una carga ya conformada.
Service Name Get_BookingLegs
Type Web Service
Parámetros para el Web Service Get_BookingLegs.
5 xmlSteps Carácter Estructura Xml con los Bookings Legs N

La implementación de estos simples Web Services permitirán una mejor comunicación en lo referido a las
necesidades de información entre las agencias relacionadas y CSAV. Además esta implementación deja de
manifiesto el potencial que puede tener el uso de Web Services para el intercambio de información entre
distintas organizaciones (B2B) para el manejo de sus procesos de negocios.

3 Conclusiones

Encontrar las respuestas a problemas tecnológicos, está demostrado que más que ser una solución al
problema únicamente abre un conjunto de nuevos problemas que deben ser solucionados. Esto ha pasado en la
historia de los Web Services, ya que entran como una solución a la problemática de poder publicar servicios
simples mediante Internet, y también a posteriori se convierten en una de las alternativas para poder realizar la
integración de aplicaciones y procesos de negocios.
Bajo el enfoque inicial del trabajo de un Web Service se pueden realizar estas nuevas tareas
asignadas, pero no de la mejor forma, por lo que se hace absolutamente necesaria la implementación de
nuevos componentes que permitan manejar la seguridad, la coordinación y los procesos envueltos en
transacciones. Las grandes compañías como Microsoft e IBM ponen delante de sus intereses comerciales
estos nuevos problemas, permitiendo que su unión de cómo fruto la definición de componentes formados en
un arquitectura que apoyen y permitan el correcto desenvolvimiento de los Web Services, dentro del contexto
de las problemáticas planteadas.

Ricardo Vásquez V.

Es bueno mencionar que los Web Services no son la panacea, pero si permiten de una forma no muy
compleja solucionar problemas que se vuelven cada vez más cotidianos en el ámbito de los negocios y el uso
de las nuevas tecnologías.
En resumen, esta tecnología tiene algo claro sus fundamentos básicos, los cuales tienen soporte desde
las empresas de framerwork de desarrollo más importantes Microsoft, SUN e IBM, pero que en lo tangencial
a los nuevos problemas no están en completo acuerdo lo que de alguna forma limita un desarrollo mejor de la
tecnología. Es de esperar que en un mediano plazo existan los estándares necesarios que nos mejoren el
panorama global y que abarquen y solucionen los nuevos problemas presentados a esta tecnología.

Referencias

[WEB-01] www.w3.org/2002/ws/. Sitio oficial del grupo de estudio de Web Services de W3C.
[WEB-02] www.moisesdaniel.com/es/wri/wsepsu. Documento introductorio sobre Web Services y sus
diversos escenarios de uso.
[WEB-03] http://es.wikipedia.org. Sitio utilizado para la obtención de las diversas definiciones de
protocolos que se encuentran en este articulo.
[WEB-04] www.willydev.net/descargas/prev/WSSev.pdf. Titulo: “La seguridad en ‘web services’: entre
la incertidumbre y la sobreinformación”, Roberto López Navarro, Servicio e Integración,
2003. Documento aborda el ámbito de la seguridad en web services desde las diversas
perspectivas existentes hasta la fecha de publicación.
[WEB-05] http://www-128.ibm.com/developerworks/library/ws-secroad/ . Arquitectura de Seguridad
Propuesta por Microsoft e IBM.
[WEB-06] http://www-306.ibm.com/software/solutions/webservices/ws_spec_sec.html . Especificación
de la arquitectura de seguridad propuesta por Microsoft e IBM.
[WEB-07] www.mundotutoriales.com. Tutorial: “De la seguridad en Servicios Web para .NET”,
Willy.Net. Aborda temas de seguridad asociados a Web Services bajo una arquitectura
Microsoft.
[WEB-08] http://www.amereiaf.org.mx/cursos/VisionWebServicesJava.pdf. Presentación que se centra
en el desarrollo de Web Services en el entorno J2EE. Mencionando en uno de sus puntos la
seguridad.
[WEB-09] http://www.w3.org/TR/2002/WD-wsa-reqs-20021114. Documento que define los requisitos
para la creación de la Arquitectura para los Web Services (WSA). Dentro de estos
requerimientos se toca el tema de seguridad.
[WEB-10] http://www.oasis-open.org/committees/tc_cat.php?cat=ws. Sitio de OASIS (Organization for
the Advancement of Structured Information Standards) coordinador actual del tema de
seguridad en Web Services. Para lo cuál posee un grupo de trabajo asociado al tema.
[WEB-11] http://msdn.microsoft.com/. Buscar: “Security in a Web Services World: A Proposed
Architecture and Roadmap”, 2002. Este artículo describe en detalle la Arquitectura de
Seguridad para Web Services propuesta por Microsoft e IBM. Buscar “WS-Security”, 2002.
Este artículo describe en detalle la especificación WS-Security.
[WEB-12] http://internetng.dit.upm.es/business%20activity.pdf. García M. Iván, “Coordinación de
procesos de negocio en entornos de servicios web: implementación de business activity”,
Universidad Politécnica de Madrid.
[WEB-13] http://iaaa.cps.unizar.es/docencia/SWD/9.CoordinacionEstandares.pdf. Presentación que trata
“Estándares relacionados con la Coordinación de Servicios” de los profesores Álvarez P &
Bañares J., Programa de Doctorado de Informática e Ingeniería de Sistemas, Universidad de
Zaragoza. España.
[WEB-14] http://www.csav.com/pages/sp_compania.htm Sitio Web con información referente a
Compañía Sudamericana de Vapores.
[TAR-01] “Tarea 1 Sistemas Distribuidos y Middleware - Using Message-Oriend Middleware for
Reliable Web Services Messaging”, Sergio Sánchez & Ricardo Vásquez, MTI – 2006.

Ricardo Vásquez V.

WS-Universidad Técnica Federico Santa María

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (16)

Semelhante a WS-Universidad Técnica Federico Santa María

Semelhante a WS-Universidad Técnica Federico Santa María (20)

WS-Universidad Técnica Federico Santa María