Palabras Clave: SOAP, HTML, XML, interoperabilidad, computación distribuida, .

[English]

Existe una tendencia muy marcada en las empresas por el desarrollo de aplicaciones que puedan trabajar 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 (OMG, Object Management Group), COM (Microsoft) y EJB (Sun Microsistems). Cada una 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 (es posible, pero complejo, hacer interoperar COM y CORBA), la dependencia a la arquitectura de trabajo (COM está muy ligado a Windows, mientras que CORBA tiene muchas implementaciones de diversos fabricantes), así como el lenguaje de programación (COM usa primordialmente C++ y Visual Basic, mientras que EJB usa Java).

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. Inicialmente Microsoft, Userland Software y DeveloperMentor trabajaron para desarrollar este esquema. Surge entonces el primer borrador de la especificación SOAP en 1999 ^[1]. La versión 1.1 es la actualmente empleada por las compañías para sus desarrollos. Es apoyada abiertamente por SUN, IBM y Apache Org., entre otras empresas y desarrolladores independientes.

El protocolo SOAP

Los objetivos primordiales de SOAP, son:

a) Establecer un protocolo estándar de invocación de servicios remotos, basado en protocolos estándares de Internet: HTTP (Hiper Text Transport Protocol) para la transmisión y XML (eXtensible Markup Language) 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 (serializa) con XML, que se ha convertido en el "parteaguas" 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 los tipos CORBA, COM o EJB.

Un esquema del funcionamiento de SOAP se muestra en la figura 1.

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 ejemplo, una petición de servicio con HTTP sería:

POST /soap/services.asp HTTP/1.1

Host:148.204.20.10

Content-Type: text/plain

Content-Length: 11

Hola mundo!

La primera línea indica el método HTTP usado, el URI (Uniform Resource Identifier, Identificador Uniforme de Recursos) y la versión del protocolo. Para este ejemplo el método empleado es POST, la ruta de ejecución del servicio es /soap/services.asp y la versión de HTTP usada es la 1.1.

En las líneas siguientes se indica la dirección Internet de la máquina de servidor Web donde se enviará la petición, el tipo de contenido del mensaje (texto plano) y su longitud. Para indicar la terminación de la cabecera, se agrega un retorno de carro/línea siguiente. Finalmente, la última línea (Hola mundo!) es el contenido de la petición, que bajo SOAP, debe ser un texto XML.

La respuesta tendría un formato similar al siguiente:

HTTP/1.1 200 OK

Content-Type: text/plain

Content-Length: 11

!odnum aloH

En este caso la primera línea indica el protocolo de HTTP, un código de retorno (definido por el HTTP RFC 2616) y un mensaje sobre el estado regresado. Un valor de retorno de 200 indica que la petición fue satisfactoria, y el mensaje OK indica el éxito de la transmisión. Otros valores como 400 Bad Request ó 300 Temporarily Moved indicarían errores en el resultado, estableciendo el valor de cero en Content-Length.

La especificación SOAP establece que los mensajes están compuestos de tres secciones: la envoltura (Envelope), el encabezado (Header) y el cuerpo (Body). Mientras que el encabezado es opcional (pueden no tener, tener uno o tener varios), la envoltura y el cuerpo son obligatorios y únicos. La sección Envelope contiene a las otras dos secciones como elementos. En el siguiente ejemplo se analiza el contenido de un mensaje SOAP (se numeran las líneas como referencia para la explicación):

1 POST /soap/StockQuote HTTP/1.1

2 Host: www.stockquoteserver.com

3 Content-Type: text/xml; charset="utf-8"

4 Content-Length: nnnn

5 SOAPAction: ""

6

ENV="http://schemas.xmlsoap.org/soap/envelope/">

SOAP-ENV:mustUnderstand="1">

11 5

12</ t:Transaction>

13 </ SOAP-ENV:Header>

14 <SOAP-ENV:Body>

15 <m:GetLastTradePrice xmlns:m="http://www.stockquoteserver.com/soap">

16 <symbol>DEF</symbol>

17 </m:GetLastTradePrice>

18 </SOAP-ENV:Body>

19 </SOAP-ENV:Envelope>

En el encabezado (líneas 1 a 5) se debe especificar el tipo de mensaje en Content-Type como text/xml, para que sea correctamente interpretado, así como el conjunto de caracteres a usar (utf-8). Como una extensión SOAP al encabezado se incluye SOAPAction, que define un URI desde donde se localizará el servicio, que en este caso es un cadena vacía, ya que se ha establecido como www.stockquoteserver.com/soap/StockQuote (líneas 1 y 2). Es importante remarcar que el encabezado y el cuerpo del mensaje están delimitados por dos retornos de carro/nueva línea (línea 6 en blanco).

El contenido del mensaje se describe a partir de la línea 7. Con xmlns:identificador="URI" se define un espacio de nombre (namespace), que es un identificador de ámbito para evitar ambigüedades. Se observa que el encabezado contiene un elemento Transaction, con atributo mustUndestand="1" (tiene que ser interpretado) y con un valor de 5, mientras que el cuerpo contiene un elemento GetLastTradePrice (el nombre del servicio) con el elemento symbol (el parámetro del servicio) y el valor DEF (el valor a buscar).

La respuesta obtenida será algo similar a lo siguiente:

1 HTTP/1.1 200 OK

2 Content-Type: text/xml; charset="utf-8"

3 Content-Length: nnnn

4

5 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

6<SOAP-ENV:Header>

7 <t:Transaction xmlns:t="http://www.stockquoteserver.com/soap" mustUnderstand="1">

8 5

</t:Transaction>

9 </SOAP-ENV:Header>

10 <SOAP-ENV:Body>

11 <m:GetLastTradePriceResponse xmlns:m="http://www.stockquoteserver.com/soap">

12 <Price>34.5

13 </m:GetLastTradePriceResponse>

14 </SOAP-ENV:Body>

15 </SOAP-ENV:Envelope>

El cuerpo del mensaje tiene un similar esquema, sólo diferenciado en que el cuerpo contiene al elemento GetLastTradePriceResponse (que es el nombre del servicio, añadiendo el sufijo Response), que a su vez contiene al elemento Price (el parámetro de retorno) con un valor de 34.5, el cual es el resultado del servicio.

SOAP define al elemento Fault en el caso de error en la ejecución del servicio. En el elemento fautlcode se describe el código del error, mientras que el elemento faultstring contendría un mensaje explicativo del error ocurrido. Como ejemplo, si hubiera una falla en el servidor, dentro del cuerpo se tendría algo como:

.....

<SOAP-ENV:Fault>

<faultcode>SOAP-ENV:Server</faultcode>

<faultstring>Error en el servidor</faultstring>

</SOAP-ENV:Fault>

.....

Desarrollo de un servicio Web

Con los conceptos básicos definidos, se pretende implementar un par de servicios simples como ejercicio de creación de servicios Web. Dichos servicios serán información acerca del usuario que actualmente está conectado en la computadora anfitriona, así como el nombre de dicho servidor.

Aunque SOAP no recae en un software de desarrollo específico, las empresas participantes en su propuesta han lanzado sus paquetes de desarrollo, que incluyen asistentes, código de ejemplo y manuales del programador. Existen varias implementaciones, como la de Microsoft (usando su tecnología de componentes basados en el modelo COM), IBM (que permite usar componentes COM, EJB y clases de Java sobre servlets), DevelopMentor (usando clases de Java o scripts de Perl) y algunas otras usando el lenguaje C++.

Para el presente ejercicio se usó el SOAP ToolKit 2.0 de Microsoft ^[3] , que contiene un asistente de generación de definiciones, documentación y algunos ejemplos. Se puede obtener en forma gratuita de la dirección http://msdn.microsoft.com/downloads/default.asp?URL=/code/sample.asp?url=/msdn-files/027/001/580/msdncompositedoc.xml. Para el ejemplo, será necesario instalarlo, lo cual no es complicado, ya que se distribuye como una aplicación de autoinstalación (SoapToolkit20.exe).

Tal como se hace en CORBA o en COM, el SOAP de Microsoft (MSSOAP) usa un lenguaje de definición de servicios para Web (WSDL), en donde se definen los servicios a publicar, los tipos de datos a retornar, así como otras características de los servicios. El WSDL es un borrador (no está completamente aprobado por el W3C), por lo que su explicación está fuera del presente artículo. Para mayor referencia, se puede consultar en ^[11]

El asistente de generación de WSDL del MSSOAP necesita que los servicios estén implementados en COM, por lo que será necesario contar con alguna herramienta de desarrollo que genere dichos componentes, tal como Visual Basic 6.0, Visual C++ 6.0 o Visual Interdev. Por su simplicidad se usó Visual Basic 6.0, siguiendo los siguientes pasos:

1. Inicialmente se elige la creación de un proyecto Active X dll. Esto generará un archivo .cls que contendrá las funciones de los servicios. El nombre del módulo, proyecto y dll generada será InfoServices.

2. Los servicios usarán funciones de la API WIN32, por lo que será necesario añadir un módulo. Seleccionando el proyecto se elige añadir módulo, para posteriormente abrir el archivo definiciones.bas, que contiene la siguientes líneas:

Public Declare Function GetUserName Lib "advapi32.dll" Alias "GetUserNameA" (ByVal lpBuffer As String, nSize As Long) As Long Public Declare Function GetComputerName Lib "kernel32" Alias "GetComputerNameA" (ByVal lpBuffer As String, nSize As Long) As Long

Se observa que las funciones a usar son GetUserName y GetComputerName

3. En el módulo de clase contendrá los servicios, con las siguientes líneas de código:

Option Explicit

Public Function UserName() As String

Dim nombre As String * 128, longitud As Long

nombre = String(128, " ")

If GetUserName(nombre, Len(nombre)) Then

longitud = InStr(nombre, vbNullChar) - 1

nombre = Left(nombre, longitud)

UserName = nombre

Else

UserName = "La funcion ha fallado"

End If

End Function

Public Function ComputerName() As String

Dim buffer As String * 128, longitud As Long

buffer = String(128, " ")

If GetComputerName(buffer, Len(buffer)) Then

longitud = InStr(buffer, vbNullChar) - 1

buffer = Left(buffer, longitud)

ComputerName = buffer

Else

ComputerName = "La funcion ha fallado"

End If

End Function

Estas funciones no tienen parámetros de entrada, y devuelven la información del nombre de usuario y del servidor como una cadena de caracteres. La figura 2 muestra cómo es el ambiente para este proyecto.

4. En el menú Archivo se elige la opción Generar InfoServices.dll..., y se escribe el nombre de InforServices como el nombre de la librería. Esto genera los archivos InforServices.dll, InforServices.lib y InforServices.exp.

5. Si todo va bien hasta ahora, se inicia el WSDL Generator, instalado en el menú Programas/Microsoft SOAP Toolkit/WSDL Generator. Después de la pantalla de bienvenida, el asistente pregunta por el nombre del servicio a configurar, así como la ruta donde se encuentra nuestro componente COM creado en el punto anterior. Se muestra dicha pantalla en la figura 3

Figura 3. El generador de WSDL.

En este caso, el nombre elegido para el ejemplo será InfoServices y la ruta será en donde se encuentre el archivo InfoServices.dll.

6. A continuación, el asistente muestra los métodos que pueden ser ejecutados por el componente. Marcando el cuadro con un asterisco, indica que el método estará disponible para el usuario. Se marcan ambos (figura 4).

Figura 4. Elección de los servicios a ser publicados.

7. En la siguiente pantalla se determina el punto de ejecución (endpoint) de los servicios; esto es, la dirección HTTP del servidor Web que atenderá las peticiones. También se elige la forma de ejecución del servicio, ya sea como una pagina ASP o como un agregado ISAPI. Se elige el uso de una página ASP (figura 5).

Figura 5. Configuración del servidor y del tipo de ejecución de los servicios.

8. Finalmente se pregunta por el tipo de codificación a ser soportado (utf.8 o utf-16), así como el directorio donde se almacenará la salida, como se muestra en la figura 6.

Figura 6. Configuración del tipo de codificación y de la ubicación del resultado.

9. Finalizado el asistente, se tendrán a la salida tres archivos: un archivo .wsdl, que contiene las definiciones de los servicios; un archivo .wsml, que contiene las definiciones del componente, y un archivo .asp, que se encarga de instanciar a la clase del componente y ejecutar los servicios. El archivo InfoServices.wsdl contiene los nombres de los métodos, los parámetros de entrada, sus tipos y los resultados, como se muestra a continuación:

<?xml version='1.0' encoding='UTF-8' ?>

<!-- Generated 12/13/01 by Microsoft SOAP Toolkit WSDL File Generator, Version 1.02.813.0 -->

<definitions name ='InfoServices' targetNamespace = 'http://tempuri.org/wsdl/' xmlns:wsdlns='http://tempuri.org/wsdl/' xmlns:typens='http://tempuri.org/type' xmlns:soap='http://schemas.xmlsoap.org/wsdl/soap/' xmlns:xsd='http://www.w3.org/2001/XMLSchema' xmlns:stk='http://schemas.microsoft.com/soap-toolkit/wsdl-extension' xmlns='http://schemas.xmlsoap.org/wsdl/'>

<types>

<schema targetNamespace='http://tempuri.org/type' xmlns='http://www.w3.org/2001/XMLSchema' xmlns:SOAP-ENC='http://schemas.xmlsoap.org/soap/encoding/' xmlns:wsdl='http://schemas.xmlsoap.org/wsdl/' elementFormDefault='qualified'>

</schema>

</types>

<message name='Info.UserName'>

</message>

<message name='Info.UserNameResponse'>

<part name='Result' type='xsd:string'/>

</message>

<message name='Info.ComputerName'>

</message>

<message name='Info.ComputerNameResponse'>

<part name='Result' type='xsd:string'/>

</message>

<portType name='InfoSoapPort'>

<operation name='UserName' parameterOrder=''>

<input message='wsdlns:Info.UserName' />

<output message='wsdlns:Info.UserNameResponse' />

</operation>

<operation name='ComputerName' parameterOrder=''>

<input message='wsdlns:Info.ComputerName' />

<output message='wsdlns:Info.ComputerNameResponse' />

</operation>

</portType>

<binding name='InfoSoapBinding' type='wsdlns:InfoSoapPort' >

<stk:binding preferredEncoding='UTF-8'/>

<soap:binding style='rpc' transport='http://schemas.xmlsoap.org/soap/http' />

<operation name='UserName' >

<soap:operation soapAction='http://tempuri.org/action/Info.UserName' />

<input>

<soap:body use='encoded' namespace='http://tempuri.org/message/' encodingStyle='http://schemas.xmlsoap.org/soap/encoding/' />

</input>

<output>

<soap:body use='encoded' namespace='http://tempuri.org/message/' encodingStyle='http://schemas.xmlsoap.org/soap/encoding/' />

</output>

</operation>

<operation name='ComputerName' >

<soap:operation soapAction='http://tempuri.org/action/Info.ComputerName' />

<input>

<soap:body use='encoded' namespace='http://tempuri.org/message/' encodingStyle='http://schemas.xmlsoap.org/soap/encoding/' />

</input>

<output>

<soap:body use='encoded' namespace='http://tempuri.org/message/' encodingStyle='http://schemas.xmlsoap.org/soap/encoding/' />

</output>

</operation>

</binding>

<service name='InfoServices' >

<port name='InfoSoapPort' binding='wsdlns:InfoSoapBinding' >

<soap:address location='http://148.204.20.10/soap/InfoServices.ASP' />

</port>

</service>

</definitions>

Se observa que es básicamente un archivo XML, con información acerca de los métodos que componen a los servicios, los parámetros de entrada, los tipos de datos que regresan, entre otras configuraciones. Se hace énfasis al resultado generado con el código que está en negritas. También se remarca el código subrayado, en donde se tiene que sustituir la cadena tempuri.org/action por la dirección de nuestro servidor Web y la ruta de ejecución del servicio, que en este caso es 148.204.20.10/soap/. Si no se hace así, el servicio no podrá ser encontrado.

Pero, ¿para qué sirve este archivo? El usuario remoto sólo comprende que existe una computadora que proporciona servicios Web, pero no sabe qué servicios ofrece. El archivo WSDL se encarga de suministrar esta información como XML. Cuando dicho usuario se conecta al servidor, éste inicialmente le debe regresar un archivo .wsdl que el usuario debe interpretar. La petición de un servicio estará codificada con base en la especificación de SOAP, ya comentada, y tendrá un aspecto como el siguiente:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsdlns="http:// 148.204.20.10/soap/wsdl/" xmlns:typens="http:// 148.204.20.10/soap//type" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:stk="http://schemas.microsoft.com/soap-toolkit/wsdl-extension" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

<mns:ComputerName>

</mns:ComputerName>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

El texto en negritas marca las características importantes de un mensaje SOAP del ejemplo. Se nota que el cuerpo del mensaje no contiene un encabezado, y que el servicio no tiene parámetros de entrada. El resultado de la ejecución del servicio será el siguiente:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tns="http://148.204.20.10/soap/InfoServices.wsdl" xmlns:xsd1="http:// 148.204.20.10/soap/InfoServices.xsd" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/xml/soap/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

<tns:ComputerNameResponse>

<Return xsi:type="xsd:string">YAOTL</Return>

</tns:ComputerNameResponse>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

En el cuerpo del mensaje se nota el elemento ComputerNameResponse, que a su vez incluye al elemento Return, que contiene los resultados de ejecución del servicio, en este caso YAOTL de tipo string.

El archivo .asp generado por el asistente, contiene el código de inicialización, validación y procesamiento de las instancias del componente y de SOAP. Su contenido, para el ejercicio, es el siguiente:

<%@ LANGUAGE=VBScript %>

<% Option Explicit On Error Resume Next Response.ContentType = "text/xml" Dim SoapServer If Not Application("InfoServicesInitialized") Then Application.Lock If Not Application("InfoServicesInitialized") Then Dim WSDLFilePath Dim WSMLFilePath WSDLFilePath = Server.MapPath("InfoServices.wsdl") WSMLFilePath = Server.MapPath("InfoServices.wsml") Set SoapServer = Server.CreateObject("MSSOAP.SoapServer") If Err Then SendFault "Cannot create SoapServer object. " & Err.Description SoapServer.Init WSDLFilePath, WSMLFilePath If Err Then SendFault "SoapServer.Init failed. " & Err.Description Set Application("InfoServicesServer") = SoapServer Application("InfoServicesInitialized") = True End If Application.UnLock End If Set SoapServer = Application("InfoServicesServer") SoapServer.SoapInvoke Request, Response, "" If Err Then SendFault "SoapServer.SoapInvoke failed. " & Err.Description Sub SendFault(ByVal LogMessage) Dim Serializer On Error Resume Next ' "URI Query" logging must be enabled for AppendToLog to work Response.AppendToLog " SOAP ERROR: " & LogMessage Set Serializer = Server.CreateObject("MSSOAP.SoapSerializer") If Err Then Response.AppendToLog "Could not create SoapSerializer object. " & Err.Description Response.Status = "500 Internal Server Error" Else Serializer.Init Response If Err Then Response.AppendToLog "SoapSerializer.Init failed. " & Err.Description Response.Status = "500 Internal Server Error" Else Serializer.startEnvelope Serializer.startBody Serializer.startFault "Server", "The request could not be processed due to a problem in the server. Please contact the system admistrator. " & LogMessage Serializer.endFault Serializer.endBody Serializer.endEnvelope If Err Then Response.AppendToLog "SoapSerializer failed. " & Err.Description Response.Status = "500 Internal Server Error" End If End If End If Response.End End Sub %>

A grandes rasgos, el procesamiento que realiza la pagina ASP, es el siguiente: se obtienen las definiciones de los archivos WSDL y WSML y se inicializa la implementación de manejo de SOAP, mediante CreateObject("MSSOAP.SoapServer"). La información sobre los servicios se obtiene con SoapServer.Init WSDLFilePath, WSMLFilePath, para posteriormente establecer la comunicación del cliente con el servidor a través del método SoapInvoke del objeto SoapServer. Si hay un error, se llama a la función SendFault, la cual se encarga de construir la respuesta con la explicación del error. Está función hace uso de los objetos Response (la respuesta hacia el cliente) y Serializer (que construye un mensaje XML encapsulando los métodos serialización de SOAP).

Este archivo InfoServices.asp se debe copiar en la ruta de un sitio virtual del servidor Web, el cual debe tener la capacidad de ejecutar el tipo de páginas ASP. Para el ejemplo se usó el Internet Information Server (IIS), en el directorio virtual http://148.204.20.10/soap.(La configuración del IIS no es tema de este articulo, por lo que se deberá consultar la ayuda en línea). Al iniciar el IIS, esta página debe estar disponible.

Hasta aquí se han generado los servicios. Como se mencionó anteriormente, un usuario debe tener una página Web que invoque a dichos servicio, descargando su información del archivo WSDL y realizando la petición de determinado servicio. Para efectos de pruebas prácticas, se usó un cliente genérico ^[12] del sitio http://www.soapclient.com/soaptest.html. La figura 7 muestra la página después de obtener el archivo WSDL con los servicios disponibles, y la figura 8 presenta el resultado de la ejecución del servicio UserName.

Figura 7. Petición de un servicio Web con un cliente genérico.

Figura 8. Ejecución del servicio ComputerName.

El resultado obtenido como archivo XML puede ser tratado con técnicas de formato, como las Hojas de Estilo en Cascada (CCS, Cascade Style Sheets), XSL (XML Stylesheets Language, Lenguaje de Estilos de XML) o plantillas de diseño personalizadas. Hay que remarcar que lo importante en el uso de XML, es que los datos son independientes de la presentación, de manera que el desarrollador Web pueda hacer un mejor tratamiento del resultado obtenido.

Pero, ¿por qué es un protocolo de transmisión de objetos? Bueno, la especificación es completa en el aspecto de que el tipo de información a transmitir incluye tipos de datos definidos por el usuario, así como arreglos de datos ^[6]. Cabe recordar que el XML es un metalenguaje; esto es, con base en las especificaciones de los Tipos de Definición de Datos (DTD, Data Type Definition), es posible ajustar el significado de los elementos de un documento para que cumpla con las validaciones definidas. Además, el XML transmite datos en forma semiestructurada, lo que significa que el contenido de un documento se puede mapear hacia cualquier modelo de datos estructurado (jerárquico, de red, relacional, orientado a objetos, etcétera) o semiestructurado (aplicaciones ligadas o hipertexto).

Actualmente ha surgido un gran auge por el desarrollo de las aplicaciones distribuidas sobre Internet, empleando SOAP. La especificación SOAP no pretende crear otro protocolo o ambiente de desarrollo que compita con otras tecnologías vigentes, sino más bien aprovechar las herramientas que ya existen, como HTML y XML. Se puede pensar (erróneamente) que SOAP sea un sustituto viable de COM o CORBA por el grado de interoperabilidad que presenta; sin embargo, tal como lo muestra la solución de Microsoft, es posible hacer convivir distintos ambientes con el uso de SOAP como protocolo de transporte y codificación de datos. Se espera que en poco tiempo se apruebe como un estándar (con pocas modificaciones a su estado actual) y que la mayoría de las empresas comiencen a desarrollar soluciones con esta tecnología. Mientras tanto, poniendo un ejemplo de la expectación que ha surgido, Microsoft ha anunciado que su estrategia de DNA 2000 tiene como fundamentos a SOAP, además de que serán incluidas las librerías en sus herramientas de desarrollo, como Visual Studio .NET. Su herramienta BizTalk, para el intercambio de información entre empresas (B2B, Business to Business, Empresa a Empresa), funciona mediante mensajería SOAP. Si bien existen algunas desventajas en su uso (véase ^[10]), tal parece que será una de las futuras tecnologías para uso de los programadores.

Box, Don, "A brief history of SOAP" [on line]. DevelopMentor Inc.<http://www.develop.com/dbox/postsoap.html>. [31 March.].

"FAQ (Frequently Asked Questions) de SOAP" [on line].<http://www.develop.com/soap/soapfaq.htm>. "Implementacion de SOAP por Microsoft" [on line].<http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28000523>. "Implementacion de SOAP" [on line].DevelopMentor Inc.<http://www.develop.com/soap>. "Implementacion de SOAP" [on line]. Apache/IBM.<http://www.ibm.com/developerworks/webservices/>.

Box, Don, Ehnebuske, David . Kakivaya, Gopal, Layman, Andrew . Mendelsohn, Noah, Frystyk, Nielsen . Henrik, Thatte,Satish,Winer,Dave,"El protocolo SOAP: Protocolo Simple de Acceso de Objetos (Simple Object Access Protocol)" [en línea].<http://www.microsoft.com/Latam/msdn/articulos/2000/10/art01/default.asp#A1>. [(2000)].

Box, Don, "A Young Person's Guide to the Simple Object Access Protocol" [on line].<http://msdn.microsoft.com/msdnmag/issues/0300/soap/soap.asp>.

Strahl, Rick, "Using Microsoft's SOAP Toolkit for remote object access" [on line].<http://www.west-wind.com/presentations/soap/>.

Skonnard, Aaron "SOAP: The Simple Object Access Protocol" [on line].<http://www.microsoft.com/mind/0100/soap/soap.asp>.

Ballinger, Keith, "Web Services Interoperability and SOAP" [on line].<http://msdn.microsoft.com/library/en-us/dnsoap/html/soapinteopbkgnd.asp?frame=true>.

"Web Services Description Language (WSDL) 1.1 W3C Note" [on line].<http://www.w3.org/TR/2001/NOTE-wsdl-20010315>. [(2001)15 March.].

"Sitio de desarrollo basado en SOAP" [en línea].<http://www.soapclient.com/>.

Dirección General de Servicios de Cómputo Académico-UNAM
Ciudad Universitaria, México D.F.