- Objetivos
- Historia del protocolo de acceso
a objetos simples - SOAP
- Procesamiento de
mensajes - Extensiones al protocolo
SOAP - Ventajas de la
utilización de SOAP - Desventajas de
utilización de SOAP - ¿Por qué utilizar
Web Services y SOAP en las empresas? - Conclusiones
- Bibliografía
Hoy en día existe una tendencia muy marcada en
las empresas por el
desarrollo de
aplicaciones que trabajen sobre Internet, principalmente por
la ventaja de la distribución global de la información. Las tecnologías
más usadas para el desarrollo de estas aplicaciones, han
sido CORBA, COM y EJB. Cada una de estas tecnologías
proporciona un marco de trabajo para
la activación de objetos remotos, mediante la solicitud a
un servidor de
aplicaciones o mediante un servidor Web para la
ejecución de servicios de
aplicación. Estas tecnologías han probado ser
efectivas para el establecimiento de sitios Web corporativos; sin
embargo, presentan algunas desventajas como la falta de
interoperabilidad, la dependencia a la arquitectura de
trabajo, así como el lenguaje de
programación.
Esto ha llevado a la industria a
considerar un nuevo modelo de
computación distribuida de objetos, sin
tener la dependencia de plataformas, modelos de
desarrollo y lenguajes de
programación usados y como una medida de
solución nace SOAP(Simple Object Access
Protocol) que es una estrategia de
desarrollo de aplicaciones distribuidas usando tecnologías
diversas adoptada por las diferentes organizaciones
del mundo para resolver los problemas de
falta de interoperabilidad entre las tecnologías
anteriormente mencionadas, tomando como base protocolos ya
establecidos y con gran aceptación en Internet, como
HTML y
XML.
SOAP no es más que un protocolo
estándar que permite la
comunicación y la interoperabilidad entre diversas
aplicaciones Web desarrolladas bajo tecnologías
diferentes.
- Conocer la historia del protocolo
SOAP - Identificar a SOAP como un protocolo para promover la
interoperabilidad entre aplicaciones Web. - Comprender el funcionamiento de SOAP.
- Mostrar la utilidad de
SOAP en las organizaciones - Conocer las ventajas y desventajas que implican la
utilización de SOAP.
1. HISTORIA DEL PROTOCOLO DE ACCESO A
OBJETOS SIMPLES
La evolución tecnológica y
búsqueda de soluciones a
la computación distribuida no es un problema reciente, es
por ello que desde el año 1980 se dieron los inicios en
este tema aunque los protocolos de comunicación no era objeto de interés de
los desarrolladores en ese momento; realizar aplicaciones que
dentro de una misma máquina se comunicaran entre
sí, era suficiente.
Posteriormente en el año de 1990 alcanzaron
popularidad objetos como COM (Componet Object Model) introducido
por Microsoft y
CORBA (Common Object Request Broker Architecture) introducido por
OMG (Object Management Group).
En general, COM y CORBA son modelos para escribir y
encapsular código
binario. Estos son componentes que pueden ser fácilmente
llamados desde cualquier aplicación que soporte COM o
CORBA. Sin embargo estos modelos no son fácilmente
interoperables, de tal manera que COM puede solamente llamar a
COM, y lo mismo ocurre con CORBA.
Conectar una maquina a otra se transformó en una
prioridad cuando las redes locales se
generalizaron, fue entonces que OMG estableció IIOP
(Internet Inter-ORB Protocol) como el protocolo de
comunicación para CORBA. Microsoft creo DCOM
(Distributed COM), más tarde Sun Microsystems lanzo al
mercado RMI
(Remote Method Invocation).
Con estos protocolos se pueden llamar componentes que se
encuentren en otras computadoras a
través de la red. Estas llamadas se
realizan bajo la forma de RPC (Remote Procedure Call). Es
necesario aclarar que estos protocolos no son
interoperables.
La solución está disponible para tener
comunicación entre aplicaciones desde cualquier
máquina a cualquier otra sin importar el sistema
operativo, entorno de lenguajes, modelos de objetos
distribuidos y usando los estándares de
Internet.
Para resolver estas dificultades de interoperabilidad se
desarrolló SOAP, el cual se dio a conocer en 1999 y fue un
resultado de desarrolladores de Microsoft Corp., DevelopMentor
Inc. y Userland Software Inc. SOAP 1.1 fue
liberada el 8 de Mayo del 2000, por W3C, con la
contribución de las siguientes empresas: Ariba Inc.,
Commerce One Inc., Compaq Computer Corp, Hewlett-Packard Co., IBM
Corp., IONA Technologies PLC, Lotus
Development Corp., y SAP
AG.
Esto fue un buen signo de la industria para aceptar e
implementar estándares basados en protocolo
interoperables. Actualmente este protocolo esta siendo
desarrollado por el XML Protocol Working Group de la W3C, en la
versión 1.2.
SOAP (Simple Object Access Protocol,
Protocolo Simple de Acceso a Objetos) es un protocolo de mensajes
entre computadores. SOAP especifica el formato de mensaje que
accede e invoca a los objetos, mas que un objeto en
particular.
La idea detrás de SOAP es la misma que RPC.
También define un protocolo para llamadas a métodos
remotos, sin embargo SOAP contiene:
- Información adicional incluida en el documento
XML (lenguaje de
marcado extensible), que describe el contenido y como
podría ser procesada. - Definición de la especificación de
algunas estructuras
en XML, tales como arrays. - El modelo descentralizado, esto significa que puede
ser procesado por varios intermediarios. - Características especificas para operaciones
clásicas de RPC con parámetros in/out,
etc.
2.1
OBJETIVOS
PRIMORDIALES DE SOAP
a) Establecer un protocolo estándar de
invocación de servicios remotos, basado en protocolos
estándares de Internet: HTTP (Protocolo
de transporte de
Hipertexto) para la transmisión y XML (lenguaje de marcado
extensible) para la codificación de datos.
b) Independencia
de plataforma, lenguaje de desarrollo e implementación
(modelo de objetos).
El protocolo de comunicación HTTP es el empleado
intrínsecamente para la conexión sobre Internet.
Garantiza que cualquier cliente con un
navegador estándar pueda conectarse con un servidor
remoto. La transmisión de datos se empaqueta con XML, que
se ha convertido en el estándar del intercambio de datos,
salvando las incompatibilidades entre otros protocolos, tales
como el NDR (Network Data Representation) o el CDR (Common Data
Representation).
Por otra parte, los servidores Web
pueden procesar las peticiones de usuario, empleando las
tecnologías de Servlets, paginas ASP (Active
Server Pages) o JSP (Java Server
Pages), o un servidor de aplicaciones, invocando objetos de tipos
CORBA, COM o EJB.
Como SOAP circunscribe información adicional
incluida en el documento XML a continuación se
presentará la descripción de dicho documento.
2.1.1
Descripción de los componentes básicos de un
documento XML
XML esta interesado en describir el contenido de los
documentos que
están almacenados en un formato electrónico, de
forma tal que sea legible y comprensible tanto para las personas
como para el software, un archivo en
formato XML contiene una mezcla del documento y etiquetas XML,
las cuales organizan y definen los componentes del
documento.
La clase
más simple de documento es un archivo de texto, el
archivo es considerado como un flujo de datos, una secuencia
lineal de caracteres las cuales son leídas y procesadas
por el software en un estricto orden.
En un sistema
tradicional, las etiquetas son consideradas como instrucciones
que son interpretadas, por ejemplo, para ejecutar cambios en el
estilo del tipo de fuente que pueden significar un salto de
línea, pero que no deberán aparecer ni estar
presentes en el texto.
2.1.2
Estructura de
un documento XML
Un documento basado en XML esta formado de dos piezas
esencialmente, una estructura lógica
y una estructura física, la estructura
lógica le permite a un documento dividirse en unidades y
sub-unidades llamadas elementos. La estructura
física contiene los componentes del documento, llamadas
entidades, algunas veces almacenadas separadamente en
otros archivos,
así que la información puede ser reutilizada,
también pueden incluirse por referencia datos que no tiene
un formato XML como son las imágenes.
La estructura de un documento XML se puede definir a
partir de dos estándares. El primero es la
especificación de XML, que define las reglas
predeterminadas para la construcción de todos los documentos XML,
cualquier documento que se ajuste a las reglas básicas
definidas en la especificación se denominan documentos
XML bien formados debido a que XML actualmente es un
meta-lenguaje (un lenguaje que describe a otros
lenguajes), ya que no hay una lista predefinida de elementos, el
usuario puede llamar usar sus elementos como desee, sin embargo,
el segundo estándar (que es opcional), lo crean los
autores del documento y se especifica en una definición de
tipo de documento DTD (Document Type Definition), que explica
cuales elementos son permitidos en un documento en
particular.
XML tiene un alto grado de control sobre la
estructura lógica del documento, cada documento puede ser
comparado con las reglas de su DTD lo que determina si es valido,
cuando el documento XML se ajusta a las reglas definidas en la
DTD, se denomina documento XML valido. Los esquemas son
similares a los DTD, pero utilizan un formato diferente, los DTD
y los esquemas resultan bastante útiles cuando el
contenido de un grupo de
documentos comparten un conjunto de reglas común y deben
ser analizados para determinar su valides.
Un documento XML contiene instrucciones especiales
llamadas tags, las cuales usualmente encierran las partes
identificables de un documento. SOAP define 3 formas distintas de
expresar los tipos de datos de
un tag:
- Utilizar el atributo ‘xsi: type’
en cada tag, explícitamente referenciando el tipo de
datos de acuerdo con la especificación del esquema
XML. - Referenciar un esquema XML que defina particularmente
ese tipo de datos exacto. - Referenciar otro esquema que defina el tipo de datos
de un tipo de elemento dentro del cual se declara.
Las etiquetas XML no directamente especifican el estilo
de presentación, pero en lugar de esto dan nombre a los
objetos, estas usualmente ordenan e identifican un objeto en un
flujo de datos. Una etiqueta de inicio, una etiqueta de fin,
junto con los datos encerrados por estos, componen un elemento;
el tag de inicio es delimitado usando los caracteres
‘<’ y ‘>’, el tag de fin es
delimitado por los caracteres ‘</’ y
‘>’:
Adicionalmente un elemento XML puede contener elementos
embebidos, y todo un documento debe estar encerrado por un solo
elemento documento, la estructura jerárquica de un
documento puede ser visualizada como una caja dentro de cajas
ó como una estructura en árbol.
Los nombres de los elementos son sensibles a
minúsculas y mayúsculas, de esta forma
‘descripción’, ‘DESCRIPCION’ y
‘Descripción’, pueden hacer referencia a
elementos diferentes, el nombre que aparece en el tag de inicio
debe ser exactamente igual con el nombre del tag de
finalización para los elementos.
Cada elemento debe estar completamente encerrado por
otro elemento, (cualquier documento XML que se componga
apropiadamente, es decir que sus elementos estén
adecuadamente anidados uno dentro del otro, es determinado un
documento XML bien formado), excepto por el elemento padre de
todos los elementos (root ó raíz del
documento).
Algunas estructuras jerárquicas pueden ser
recursivas. Un elemento puede directamente o indirectamente
contener instancias de si mismo. En una estructura anidada no hay
un limite establecido para el nivel de anidación en los
elementos.
Los símbolos ‘<’ y
‘>’ son caracteres que tienen el rol de
delimitadores de las marcas para los
tags XML, estos no pueden aparecer como datos o caracteres a
causa de la ambigüedad y confusión que pueden causar.
Por lo tanto será necesario usar una forma de
códigos de escape en lugar de estos caracteres,
‘<’ representa al tag de inicio
‘<’ y ‘>’ representa a el tag
de fin ‘>’
Es posible para un elemento el contener
información acerca de su contenido además de su
nombre. Por ejemplo, se desea saber el uso para el cual
está destinado determinado equipo de computo, si es un
servidor ó un PC de escritorio, esta información es
llamada meta-dato, y está almacenada en los
atributos, los atributos son un mecanismo para agregar
información descriptiva a un elemento, un solo elemento
puede contener uno o más atributos.
Para cada atributo es necesario tener una dupla, nombre
y valor.
Cuando no se usa un DTD, el valor es simplemente
considerado como una unidad de texto, no se hace ninguna
distinción entre valores
numéricos y caracteres, pero cuando es utilizado un DTD se
puede ejercer mayor control sobre el rango de valores permitidos
para cada atributo. Un atributo es asociado con un elemento en
particular por el DTD, y le es asignado un atributo de tipo
‘character data’ que puede contener valores
que consisten de caracteres generales, un atributo de tipo
‘name token’, puede contener solo una palabra
simple, no son permitidos los espacios en blanco, los valores de
los atributos pueden restringirse desde una palabra a un grupo de
palabras en una enumeración, el DTD también puede
especificarnos un valor por defecto.
A continuación se muestra un
esquema del funcionamiento de SOAP
La especificación SOAP menciona que las
aplicaciones deben ser independientes del lenguaje de desarrollo,
por lo que las aplicaciones cliente y servidor pueden estar
escritas con HTML, DHTML, Java, Visual Basic u
otras herramientas y
lenguajes disponibles. Lo importante es tener alguna
implementación de SOAP (dependiendo de la herramienta de
desarrollo elegida) y enlazar sus librerías con la
aplicación. Aunque esto no es estrictamente necesario, es
preferible trabajar usando dichas librerías, con el fin de
no reescribir un código ya probado.
Las peticiones con el uso del protocolo HTTP emplean el
comando POST para transmitir información entre el cliente
y el servidor.
Por otra parte el término
Object en el nombre significa que
se adhiere al paradigma de
la
programación orientada a
objetos.
SOAP es un marco extensible y descentralizado que
permite trabajar sobre múltiples
pilas de protocolos de
redes informáticas. Los
procedimientos de llamadas remotas pueden
ser modelados en la forma de varios mensajes SOAP interactuando
entre sí.
Estos mensajes constan de 3 secciones: envelope, header
y body.
Donde:
- envelope (envoltura): Es el elemento
raíz del mensaje para describir su contenido y la forma
de procesarlo. - header (encabezado): Es la
información de identificación del
contenido. Un grupo de reglas de
codificación para expresar las instancias de tipos de
datos definidos por la aplicación. - body (cuerpo): Es el contenido del
mensaje. Una convención para representar
las llamadas y las respuestas a procedimientos
remotos.
2.2.1
Modelo de intercambio de mensajes
- Los mensajes SOAP son transmisiones unidireccionales
desde un emisor a un receptor. - Se suelen combinar mensajes para implementar
patrones, como petición/respuesta. - Las implementaciones SOAP se pueden optimizar para
explotar las características específicas de
sistemas de red
concretos.
Una aplicación SOAP debe procesar un mensaje
siguiendo un orden de acciones:
- Identificar las partes del mensaje SOAP dirigido a
dicha aplicación. - Aceptar las partes obligatorias identificadas en el
paso 1 y procesarlas de la forma adecuada. De lo contrario,
descartar el mensaje. - Si la aplicación SOAP no es el destino final
del mensaje, quitar todas las partes identificadas en el paso 1
antes de reenviar el mensaje.
También hay que tener en cuenta que este
protocolo es extensible.
4. EXTENSIONES AL PROTOCOLO
SOAP
SOAP puede ser extendido realizando adiciones de
módulos de funcionalidad. Este enfoque permite a los
desarrolladores usar los módulos y funcionalidad que ellos
necesitan, sin tener la necesidad de implementar la totalidad de
estos.
Algunas de las extensiones que pueden ser deseables en
los proveedores
son las siguientes:
Attachments – La posibilidad de incluir un
documento no XML, archivo binario ó de 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 al
proceso de
rutear mensajes SOAP a través de intermediarios. Esto
ofrece la posibilidad de agregar varios Web Services (WS) y
ofrecerlos como parte del paquete, es una manera de hacer a los
WS escalables, a través del direccionamiento, incluso
hacia múltiples servidores
Security – Dar un marco de seguridad a la
comunicación. Algunos de los aspectos podrían ser
aplicar SSL, firma digital, etc. XML referent nos ayuda a
responder: quien envía el mensaje y si el mensaje fue
alterado en la ruta.
Quality of Services – QoS es una medida que
puede ser comparada con el número o calificación
dada a los ASP o ISP, que mide la calidad del
servicio, un
concepto
similar puede manejarse para los Web Services.
Context/Privacy – Hace referencia a guardar
el contexto y privacidad, del entorno de los usuarios. (Platform
for Privacy and �referentes (P3P)).
Transaction Support – Permitir que un grupo
de operaciones o acciones se comporten como si fueran una simple
unidad (o todo falla o todo es un éxito).
Message Syntax – el formato tiene un
área separada para extensiones que sean
adicionadas.
Data – SOAP puede contener cualquier tipo
de datos. Provee un método
para serialización de datos, pero las aplicaciones pueden
definir sus propias reglas.
Transport – No define como son
transportados los mensajes durante el intercambio. SOAP muestra
como podrían ser intercambiados sobre http, pero cualquier
protocolo o método puede sustituir a http.
Purpose – SOAP no define que es lo que hay
dentro del mensaje. Hay una diferencia entre los datos y su
propósito o finalidad.
5. VENTAJAS DE LA UTILIZACIÓN DE
SOAP
Entre las ventajas de SOAP se tiene que:
- Es sencillo de implementar, probar y usar
- Atraviesa "firewalls" y routers, pues estos "piensan"
que es una comunicación HTTP. - Tanto los datos como las funciones se
describen en XML, lo que permite que el protocolo no
sólo sea más fácil de utilizar sino que
también sea muy sólido. - Es independiente del sistema operativo y procesador.
- Se puede utilizar tanto de forma anónima como
con autenticación (nombre/clave). - Facilidad para utilizar cualquier lenguaje:
Los desarrolladores involucrados en nuevos proyectos
pueden elegir desarrollar con el último y mejor lenguaje
de programación que exista. SOAP no
especifica una API, por lo que la implementación de la
API se deja al lenguaje de programación, como en Java, y
la plataforma como Microsoft .Net. - No se encuentra fuertemente asociado a
ningún protocolo de transporte: La
especificación de SOAP no describe como se
deberían asociar los mensajes de SOAP con HTTP. Un
mensaje de SOAP no es más que un documento XML, por lo
que puede transportarse utilizando cualquier protocolo capaz de
transmitir texto. - No está atado a ninguna infraestructura de
objeto distribuido: La mayoría de los sistemas de
objetos distribuidos se pueden extender, y alguno de ellos
admiten SOAP. - Aprovecha los estándares existentes en la
industria: Los principales contribuyentes a la
especificación SOAP evitaron, intencionalmente,
reinventar las cosas. Optaron por extender los
estándares existentes para que coincidieran con sus
necesidades. Por ejemplo, SOAP aprovecha XML para la
codificación de los mensajes, en lugar de utilizar su
propio sistema de tipo que ya están definidas en la
especificación esquema de XML. Y como ya se ha
mencionado SOAP no define un medio de trasporte de los
mensajes, los mensajes de SOAP se pueden asociar a los
protocolos de transporte existentes como HTTP y
SMTP. - Permite la interoperabilidad entre
múltiples entornos: SOAP se desarrolló sobre
los estándares existentes de la industria, por lo que
las aplicaciones que se ejecuten en plataformas con dichos
estándares pueden comunicarse mediante mensaje SOAP con
aplicaciones que se ejecuten en otras plataformas. Por ejemplo,
una aplicación de escritorio que se ejecute en un PC
puede comunicarse con una aplicación del back-end
ejecutándose en un mainframe capaz de enviar y recibir
XML sobre HTTP.
6. DESVENTAJAS DE UTILIZACION DE
SOAP
Entre las desventajas de SOAP se tiene que:
- Las desventajas de la utilización de SOAP
recaen en la dificultad para entender las especificaciones del
protocolo, puesto que es un complejo esquema de
codificación en el cual es necesario precisar que todos
los mensajes se incluyan en un sobre, con el contenido del
mensaje dentro de un elemento de cuerpo para que puedan ser
entendidos por cada una de las aplicaciones Web que procesan el
mensaje. - SOAP convierte en opcionales elementos como
encabezados y ofrece un amplio margen con respecto a lo que se
puede incluir en el elemento de cuerpo y además cambia
los nombres de métodos en etiquetas secundarias del
cuerpo y los argumentos en etiquetas secundarias del nombre del
método, lo que puede generar ciertos problemas de
interoperabilidad. - Las especificaciones SOAP indican que si recibe un
encabezado SOAP con un atributo mustUnderstand establecido como
"1", deberá entenderlo o generar un error. Numerosas
implementaciones no lo hicieron al principio lo que
implicó problemas de interoperabilidad.
7.
¿POR QUÉ UTILIZAR WEB SERVICES Y SOAP EN LAS
EMPRESAS?
Actualmente, los WS están siendo ampliamente
aceptados por las empresas para el desarrollo de software de uso
interno. Debido a la tecnología que es
usada por los WS, y en concreto al
uso de SOAP, que permite la cooperación y la
interoperabilidad entre empresas que estén desarrollando
proyectos en común y en las cuales no estén
trabajando sobre la misma plataforma, lenguaje de
programación o hardware
compatibles.
Para realización de dichos proyectos hay que
tener en cuenta los siguientes aspectos:
Los servicios pueden implementar toda su funcionalidad y
permanecer seguros tras el
Cortafuegos de la compañía. Las técnicas
de seguridad convencionales que se han venido usando en Internet,
ya no son suficientes. Con SOAP, cada mensaje simple que se
intercambia realiza múltiples saltos y es rutado a
través de numerosos puntos antes de que alcance su destino
final.
Es por ello que los WS necesitan tecnologías que
protejan los mensajes desde el principio hasta el final y
así permitir que SOAP realice su trabajo de
interoperabilidad entre aplicaciones de manera
eficiente.
Para ello existen un conjunto de técnicas que se
pueden usar para garantizar la seguridad a nivel de mensaje.
Estas son:
- Encriptación XML: Evita que los datos
se vean expuestos a lo largo de su recorrido. - Firma Digital XML: Asocia los datos del
mensaje al usuario que emite la firma, de modo que este usuario
es el único que puede modificar dichos
datos. - XKMS y los Certificados: XKMS (XML Key
Management Specification) define WS que se pueden usar para
chequear la confianza de un certificado de usuario. - SAML y la Autorización: SAML (Security
Assertion Mark-up Language) hace posible que los WS
intercambien información de autentificación y
autorización entre ellos, de modo que un WS
confíe en un usuario autentificado por otro
WS. - Validación de datos: Permite que los WS
reciban datos dentro de los rangos esperados.
Los WS proporcionan conectividad con cualquier software
de un modo transparente por el paso de mensaje SOAP, cada
proveedor de servicios puede adoptar soluciones diferentes que
resultan más o menos adecuadas para el consumidor.
Analizando la escalabilidad se comprobará el grado de
modularidad y flexibilidad del servicio.
Por último, también sería
interesante analizar las características que ofrece el
proveedor de WS. Actualmente no hay estándares definidos
sobre este tema, pero la mayoría de las empresas ya
está demandando algún tipo de acuerdo o contrato con los
proveedores, de modo que se pueda garantizar la interoperabilidad
entre las diferentes tecnologías, la calidad y la
fiabilidad de los servicios por los que se paga.
Los WS están basados en el estándar XML,
que ha sido universalmente aceptado. SOAP es el único
protocolo que ha sido aceptado en este momento por el World Wide Web
Consortium y se encuentra estandarizado. SOAP y WSDL están
siendo ampliamente usados.
Algunas de las empresas más importantes en el
desarrollo de Negocio Electrónico como IBM, Intel,
Microsoft u Oracle, han
creado el WS-I: organización para la Interoperabilidad de
los Web Services. El objetivo de
dicha organización es la promoción de la estandarización de
los WS de modo que se fomente la cooperación e
interoperabilidad entre las compañías y mercados
utilizando este protocolo.
Las principales compañías del mundo han
empezado a desarrollar soluciones mediante la tecnología
de los WS bajo el paso de mensajes SOAP. Algunos ejemplos
son:
- Microsoft: Recientemente ha anunciado la
disponibilidad de su primer WS, llamado MapPoint.Net. mediante
este servicio, el usuario podrá conocer su
localización exacta y otros datos adicionales
relacionados con su posición actual, como
información de tráfico, rutas posibles o puntos
comerciales cercanos. - IBM: Ha implementado una solución
basada en los WS llamada e-Business
on Demand. Esta solución permite la construcción
de Extranets que ayuden a las empresas a ver los
catálogos de productos,
realizar y localizar pedidos o chequear el estado
del inventario en
tiempo
real. - Líneas Aéreas Escandinavas:
Estas líneas aéreas han desarrollado un WS que
permite a los usuarios comprar tiquetes y chequear el estado de
los vuelos, mediante el uso del teléfono móvil.
- La primera versión de SOAP (Protocolo simple
de acceso a objetos), se dio a conocer en 1999 y fue
desarrollada por Microsoft Corp., DevelopMentor Inc. y Userland
Software Inc. SOAP 1.1 fue liberada el 8 de Mayo del 2000 hasta
llegar hoy en día a versiones adaptadas a paquetes tales
como SOAP: Lite for Perl, Apache SOAP Ver. 2.2, Apache Axis,
etc. - Es un protocolo de mensajes entre computadoras. SOAP
especifica el formato de mensaje que accede e invoca a los
objetos, mas que un objeto en particular y permite solucionar
los problemas de las tecnologías que desarrollan
aplicaciones que trabajen sobre Internet (CORBA, COM, EJB entre
otras), estos problemas son la falta de interoperabilidad, la
dependencia a la arquitectura de trabajo, así como al
lenguaje de programación. - SOAP es un protocolo ligero para el intercambio de
información en un entorno distribuido y descentralizado.
Esta basado en el protocolo XML y consiste en tres partes: una
envoltura que define una estructura para describir que contiene
el mensaje y como procesarlo, un conjunto de reglas de
codificación para expresar instancias de tipos de datos
definidos para la aplicación y un convenio para
representar las llamadas a procedimientos remotos y las
respuestas. - Web Services y SOAP hoy en día están
siendo altamente utilizados en las grandes empresas del mundo
pues le permiten a estas la cooperación e integridad
entre ellas cuando trabajan en un proyecto en
común, debido a que permite la interoperabilidad entre
sus tecnologías.
http://www.revista.unam.mx/vol.3/num1/art3
http://www.microsoft.com/spanish/msdn/articulos/archivo/280901/voices/soapinteropbkgnd.asp
http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art51.asp
http://www.desarrolloweb.com/articulos/1557.php?manual=54
http://es.wikipedia.org/wiki/SOAP
http://pegaso.ls.fi.upm.es/sistemas_dist/temario_sistemas0304.html
DILIA ROSA DUARTE MORENO
ANA LUCIA MENDOZA TAMARA
KERY PAOLA TORRES SOLIS
JOHN FERNANDO VERGARA ARROYO
JHON MENDEZ
INGENIERO DE SISTEMAS
CORPORACIÓN UNIVERSITARIA DEL CARIBE
CECAR
FACULTAD DE INGENIERÍAS
PROGRAMA DE INGENIERÍA DE SISTEMAS
SISTEMAS DISTRIBUIDOS
SINCELEJO
2005