19 respuestas

Definición simple: un servicio web es una función a la que otros programas pueden acceder a través de Internet (Http). Para aclarar un poco, cuando creas un sitio web en PHP que genera HTML, su objetivo es el navegador y, además, la persona que lee la página en el navegador. El servicio web no está destinado a personas, sino a otros programas.

Entonces, su sitio PHP que genera un número entero aleatorio puede ser un servicio web si genera el número entero en un formato que pueda ser utilizado por otro programa. Esto puede estar en XML u otro formato siempre que otros programas puedan entender el resultado.

La definición completa es obviamente más compleja, pero usted pidió un inglés sencillo.

Explicación simplificada y no técnica: un servlet web permite que PROGRAM se comunique con una página web, en lugar de tener que usar su navegador para abrir la página web.

Ejemplo: puedo ir a maps.google.com, ingresar la dirección de mi casa y ver dónde vivo en mi navegador.

Pero, ¿qué pasa si estás escribiendo un programa de computadora en el que quieres tomar una dirección y mostrarle un bonito mapa, como Google Maps?

Bueno, podrías escribir un programa de mapas completamente nuevo desde cero, o podrías llamar al servicio web que proporciona Google Maps, enviarle una dirección y te devolverá un mapa gráfico de la ubicación que puedes mostrar en tu programa.

Hay mucho más en esto a medida que llegan algunos de los otros mensajes, pero el resultado es que permite que su aplicación recupere información DE o pase información a algún recurso. Algunos otros ejemplos:

Sí, es un servicio web sencillo.

Los servicios web no son más que un mecanismo de solicitud/respuesta que permite a un cliente acceder/modificar datos de forma remota. Existen estándares oficiales para servicios web (SOAP, SOA, etc.), pero tu página simple también es un servicio.

La principal desventaja de imprimir en una página es que su servicio devolverá HTML. Los formatos de datos preferidos son JSON y XML, ya que la mayoría de los marcos del lado del cliente (y del lado del servidor) se desarrollan utilizando JSON y XML.

Entonces, si cambiaste tu servicio de devolución:

algún número aleatorio

... algún número aleatorio

Entonces esto sería más útil para la mayoría de los clientes.

En términos más simplificados, un servicio web es algo que proporciona datos como servicio a través del protocolo http. Por supuesto que no es cierto... pero está cerca.

Los servicios web estándar utilizan el protocolo SOAP, que define la comunicación y la estructura de los mensajes, y XML es el formato de datos.

Los servicios web están diseñados para permitir que las aplicaciones creadas con diferentes tecnologías se comuniquen entre sí sin problemas.

Ejemplos de servicios web son cosas como Weather.com, que proporciona información meteorológica que puede utilizar en su sitio, o UPS, que proporciona un método para solicitar cotizaciones o rastrear paquetes.

Se cambió la redacción con respecto a SOAP ya que no siempre es SOAP como mencioné, pero quería dejarlo más claro. La clave expone los datos como un servicio en lugar de un elemento de la interfaz de usuario.

Un servicio web se diferencia de un sitio web en que proporciona información que es consumida por software en lugar de por personas. Por ello, solemos hablar de servicios JSON, XML o SOAP expuestos.

Los servicios web son un componente clave en los mashups. Los mashups ocurren cuando la información de muchos sitios se agrega automáticamente en un servicio nuevo y útil. Por ejemplo, hay sitios que combinan Google Maps con información de informes policiales para brindarle una vista gráfica de la delincuencia en su área. Otro tipo de combinación sería tomar datos bursátiles reales proporcionados por otro sitio y combinarlos con una aplicación comercial falsa para crear un "juego de mercado" en el mercado de valores.

Los servicios web también se utilizan para proporcionar noticias (ver RSS), los últimos elementos agregados al sitio, información sobre nuevos productos, podcasts y otras características excelentes que le dan un giro a la web moderna.

¡Espero que esto ayude!

Para la mayoría de los sitios web, tiene páginas HTML que visita cuando usa su navegador. Estas son páginas legibles por humanos (después de renderizarlas en su navegador) donde se pueden acumular una gran cantidad de datos porque tienen sentido para los humanos.

Ahora imagine que alguien quiere utilizar algunos de estos datos. Pueden cargar su página y comenzar a filtrar todo el "ruido" para obtener los datos que necesitan, pero la mayoría de los sitios web no están diseñados de tal manera que sea 100% seguro que los datos se colocarán en el mismo lugar para todos los elementos. por lo que además de ser voluminoso, también se vuelve poco confiable.

Ingrese a los servicios web.

Un servicio web es lo que un sitio web ofrece a quienes desean leer, actualizar y/o eliminar datos de su sitio. Puede llamarlo "puerta trasera" a sus datos. En lugar de presentar los datos como parte de la página web, se presentan de una forma predefinida, donde algunas de las más populares son XML y JSON. Hay varias formas de comunicarse con un servicio web, algunas usan SOAP, otras usan servicios web REST, etc.

Lo que es común a todos los servicios web es que son el equivalente legible por máquina de las páginas web que el sitio ofrece a otros. Esto significa que otras personas que quieran utilizar los datos pueden enviar una solicitud de datos específicos que sean fáciles de analizar y usar. Algunos sitios pueden solicitarle que proporcione un nombre de usuario/contraseña en la solicitud de datos confidenciales, mientras que otros sitios permiten que cualquiera recupere los datos que pueda necesitar.

La mejor explicación en inglés se explica mediante una analogía:

• Las páginas web permiten a las personas comunicarse y colaborar entre sí.
• Los servicios web permiten que los programas se comuniquen y colaboren entre sí.

Su ejemplo de PHP es un servicio web según esta definición porque la salida puede ser utilizada por otro programa. Pero, en realidad, el raspador de pantalla HTML no es una forma confiable ni compatible de crear servicios web.

Un servicio web es un conjunto de protocolos y estándares abiertos que se utilizan para intercambiar datos entre aplicaciones o sistemas. Las aplicaciones de software escritas en diferentes lenguajes de programación y que se ejecutan en diferentes plataformas pueden utilizar servicios web para intercambiar datos a través de redes informáticas como Internet de una manera similar a la comunicación entre procesadores en una sola computadora. Esta interoperabilidad (por ejemplo, entre Java y Python, o aplicaciones de Windows y Linux) implica el uso de estándares abiertos (XML, SOAP, HTTP).

Todos los servicios web estándar funcionan utilizando los siguientes componentes:

• SOAP (Protocolo simple de acceso a objetos)
• UDDI (Descripción Universal, Descubrimiento e Integración)
• WSDL (lenguaje de descripción de servicios web)

Funciona algo como esto:

El servicio web es una tecnología mediante la cual dos o más aplicaciones web remotas se comunican entre sí a través de una red/Internet. Se puede implementar utilizando Java, .net, PHP, etc.

Características del servicio web: -

El sistema operativo proporciona una interfaz GUI (y CLI) con la que puede interactuar. También proporciona una API con la que puede interactuar con el software.

Del mismo modo, un sitio web proporciona páginas HTML con las que puede interactuar y también puede proporcionar una API que ofrece la misma información y operaciones mediante programación. O bien, es posible que solo se pueda acceder a estos servicios a través de una API sin una interfaz de usuario correspondiente.

Un servicio web, utilizado por los desarrolladores de software, normalmente se refiere a una operación realizada en un servidor remoto e invocada mediante la especificación XML/SOAP. Como ocurre con todas las definiciones, existen matices, pero este es el uso más común del término.

Una forma sencilla de explicar el servicio web es:

• Un servicio web es un método de comunicación entre dos dispositivos electrónicos a través de la World Wide Web.
• Se le puede llamar un proceso que el programador utiliza para comunicarse con el servidor.
• El programador puede utilizar SOAP, etc. para llamar a este proceso.
• Los servicios web se basan en estándares abiertos como TCP/IP, HTTP

La ventaja de un servicio web es que digamos que está desarrollando un fragmento de código en .net y desea utilizar JAVA para consumir ese código. Puede interactuar directamente con la capa de abstracción y no saber que la tecnología fue desarrollada para desarrollar el código.

Como dijo @Vincent Ramdhanie, el servicio web no está destinado a ser visto/consumido por el usuario final sino por otro programa. Entonces la lógica técnica en su programa sería:

En caso de ejecución de un programa normal.

Usuario en el sitio web -> HTML/JS/JQuery, etc. -> dame un número aleatorio -> tu programa

su programa -> generar un número aleatorio -> generar HTML y encapsular o/p -> volver al usuario

Valentin Kolesov
desarrollador de la sucursal de Krasnoyarsk de la empresa Astrosoft de San Petersburgo, especialista certificado en Microsoft (MCSD, MCSE, MCDBA)
[correo electrónico protegido]

Demostración de cómo funciona SOAP utilizando el ejemplo de escritura de un servidor web

¿Qué es el jabón?

Las tecnologías actualmente extendidas para la llamada a métodos remotos (DCOM, CORBA/IIOP y RMI) son bastante difíciles de configurar y organizar la interacción. Esto conlleva dificultades en el funcionamiento y funcionamiento de los sistemas distribuidos (problemas de seguridad, molestias de transporte a través de cortafuegos, etc.). Muchos problemas se resolvieron mediante la creación de SOAP (Protocolo simple de acceso a objetos), un protocolo simple basado en XML para intercambiar mensajes en entornos distribuidos (WWW). El protocolo está diseñado para crear servicios web y llamar a métodos de forma remota. SOAP se puede utilizar en combinación con varios protocolos de transporte, incluidos HTTP, SMTP y otros.

¿Qué son los servicios web?

Llamamos servicios web activos al contenido que implementa alguna funcionalidad y a los datos ubicados en servidores web y puestos a disposición para su uso por aplicaciones externas. Los servicios web son completamente independientes del lenguaje y la plataforma de implementación. Las aplicaciones externas interactúan con los servicios utilizando protocolos y formatos de datos estándar. La tecnología de servicios web es la piedra angular del modelo de programación .NET de Microsoft.

Para demostrar las capacidades de SOAP, este artículo utiliza la implementación recientemente publicada de SOAP Toolkit versión 2.0 de Microsoft. Cabe señalar que la versión actual de Toolkit es notablemente diferente de la anterior (Microsoft SOAP Toolkit para Visual Studio 6.0) y de la versión beta de SOAP Toolkit 2.0.

El modelo de objetos SOAP Toolkit proporciona interfaces de bajo y alto nivel (SOAPClient, SOAPServer), que ocultan al programador toda la "cocina interna": análisis y generación de paquetes, llamadas a métodos, etc. Herramientas basadas en web de una forma muy elegante Servicios en aplicaciones desarrolladas. El objeto SOAPClient actúa como un proxy, proporcionando una interfaz de servicio web y permitiéndole trabajar con él como con un objeto COM normal (Fig. 1).

1. La aplicación cliente crea una instancia del objeto SOAPClient.
2. SOAPClient lee archivos de descripción de métodos de servicios web (en WSDL y metalenguaje de servicios web, WSML). Estos archivos también se pueden almacenar en el lado del cliente.
3. La aplicación cliente, utilizando las capacidades de enlace tardío del objeto SOAPClient, llama a un método de servicio. SOAPClient genera un paquete de solicitud (sobre SOAP) y lo envía al servidor. Se puede utilizar cualquier protocolo de transporte, pero normalmente se utiliza HTTP.
4. La aplicación del servidor de escucha (puede ser una aplicación ISAPI o una página ASP) recibe el paquete, crea un objeto SOAPServer y le pasa el paquete de solicitud. Además, el Listener procesa paquetes HTTP del cliente, envía paquetes con el resultado del servicio al cliente, maneja errores y utiliza la funcionalidad de los objetos SOAP.
5. SOAPServer lee la descripción del servicio web, carga la descripción y solicita el paquete en árboles DOM XML.
6. SOAPServer llama a un método en el objeto o aplicación que implementa el servicio.
7. El objeto SOAPServer convierte los resultados de la ejecución del método o la descripción del error en un paquete de respuesta y lo envía al cliente.
8. El objeto SOAPClient analiza el paquete recibido y devuelve a la aplicación cliente los resultados del servicio o una descripción del error ocurrido.

Un archivo WSDL es un documento XML que describe los métodos expuestos por un servicio web, así como los parámetros del método, sus tipos, nombres y ubicación del servicio de escucha. El asistente del kit de herramientas SOAP genera automáticamente este documento, un extracto del cual se muestra a continuación:

La etiqueta del sobre debe ser el elemento raíz del paquete. El elemento Encabezado es opcional, pero el elemento Cuerpo debe estar presente y ser un hijo directo del elemento Sobre. Si se produce un error de ejecución del método, el servidor genera un paquete que contiene un elemento Fault en la etiqueta Body, que contiene una descripción detallada del error.

Si utiliza las interfaces de alto nivel SOAPClient, SOAPServer, entonces no tiene que entrar en las complejidades del formato del paquete, pero si lo desea, puede utilizar interfaces de bajo nivel o incluso crear un paquete "manualmente" utilizando cualquier programación. idioma.

El modelo de objetos SOAP Toolkit permite trabajar con objetos API de bajo nivel:

• SoapConnector: proporciona trabajo con el protocolo de transporte para el intercambio de paquetes SOAP.
• SoapConnectorFactory: proporciona un método para crear un conector para el protocolo de transporte especificado en el archivo WSDL (etiqueta).
• SoapReader: lee mensajes SOAP y crea árboles DOM XML.
• SoapSerializer: contiene métodos para crear un mensaje SOAP.·
• IsoapTypeMapper, SoapTypeMapperFactory: interfaces que le permiten trabajar con tipos de datos complejos.

Al utilizar objetos API de alto nivel, solo puede transferir datos de tipos simples (int, string, float, etc.), pero la especificación SOAP 1.1 le permite trabajar con tipos de datos más complejos, como matrices, estructuras, listas y combinaciones de los mismos. Para trabajar con estos tipos, debe utilizar las interfaces IsoapTypeMapper y SoapTypeMapperFactory.

Ejemplo

Para demostrar cómo funciona SOAP, escribamos un servicio web simple que pueda sumar y restar números. Para ejecutar la aplicación del servidor, necesitará IIS 5 en Windows 2000 o IIS4 en Windows NT 4.0 Service Pack 6, así como SOAP Toolkit 2.0 instalado.

Requisitos de la aplicación cliente: Microsoft Windows 98/Me o Windows NT 4.0 Service Pack 6/2000 Service Pack 1 y SOAP Toolkit 2.0 instalado.

Creando un servidor

Abra un nuevo proyecto DLL ActiveX en VB. Cambie el nombre de la clase a SOAPClass y el nombre del proyecto a SOAPProj.

En la clase, cree los siguientes métodos:

En la siguiente ventana del Asistente, puede seleccionar los métodos que se incluirán en el servicio web. En este caso, seleccione todos los métodos. Luego especifique dónde se ubicará la aplicación web (por ejemplo, http://wsd010/soap/), configure el tipo de aplicación de escucha (ASP o ISAPI), seleccione ASP, formato de esquema (predeterminado). Especifique la ruta donde se ubicarán los archivos de descripción del servicio web y la codificación. Una vez finalizado el asistente, los archivos ASP, WSDL y WSML aparecerán en el directorio web; este es el escucha de ASP y la descripción del servicio (consulte los Listados 1-3).

Todo lo que queda es configurar los derechos de acceso a la aplicación web; es recomendable instalar la autenticación NT Challenge/Response. Esto completa el trabajo de creación del servidor.

Creando un cliente

Abra un nuevo proyecto EXE estándar en VB. En el menú Proyecto/Referencias, cree un vínculo a la biblioteca de tipos SOAP de Microsoft. Cree un botón en el formulario, escriba el siguiente código en el controlador de clic del botón:

Atenuar SoapClient como nuevo SoapClient SoapClient.mssoapinit "http://wsd010/soap/SOAPService.wsdl" MsgBox SoapClient.AddNumbers(4, 3) MsgBox SoapClient.SubtractNumbers(3, 2)

No olvide cambiar la dirección del servidor web y la ruta del archivo WSDL en la segunda línea por la dirección y la ruta de su servicio web.

Después de crear el objeto SOAPClient, se debe inicializar: especifique la ruta al documento de descripción del servicio web. Después de la inicialización, el objeto tendrá métodos de servicio web. Puede trabajar con ellos como con un objeto COM normal.

Utilizando el excelente MsSoapT.exe (Utilidad de seguimiento) incluido en el kit de herramientas, puede ver los paquetes que van del cliente al servidor y viceversa en tiempo real. Para hacer esto, necesita encontrar una etiqueta en el archivo WSDL y en lugar de una línea como http://wsd010/soap/SOAPService.ASP escriba http://wsd010:8080/soap/SOAPService.ASP, es decir, especifique puerto 8080. Después de esto, debe ejecutar la utilidad de seguimiento y aceptar la configuración predeterminada, luego crear un nuevo objeto de seguimiento formateado. Ahora todos los paquetes SOAP para trabajar con el servicio web están disponibles para una visualización rápida. Si el rastreador no está cargado, entonces debe eliminar la indicación del puerto 8080. En la Fig. La Figura 4 muestra el contenido del paquete de solicitud para ejecutar el método SubstractNumbers.

Y el paquete de respuesta se ve así:

1

Así es como se ve el paquete del servidor cuando llegó en respuesta a una solicitud con un formato incorrecto:

SOAP-ENV: Servidor Conector: solicitud incorrecta al servidor. -2146823238 800a13ba

Información adicional sobre el tema.

http://msdn.microsoft.com/webservices/ y http://msdn.microsoft.com/soap/: las últimas noticias sobre SOAP y servicios web de Microsoft. También puede encontrar las últimas versiones de software allí.

http://www.vbxml.com/soap/: mucha información útil para desarrolladores. Hay presentaciones y tutoriales sobre SOAP.

http://www.w3.org/TR/SOAP/ - Especificación SOAP del W3C.

http://www.w3.org/TR/wsdl - información sobre el estándar WSDL 1.1 del lenguaje de definición de servicios web/

http://microsoft.public.xml.soap: en esta conferencia, los expertos ayudarán a resolver problemas complejos de programación SOAP.

Listado 1. Código de escucha para ASP <%@ LANGUAGE=VBScript %> <% Option Explicit On Error Resume Next Response.ContentType = "text/xml" Dim SoapServer If Not Application("SoapServerInitialized") Then Application.Lock If Not Application("SoapServerInitialized") Then Dim WSDLFilePath Dim WSMLFilePath WSDLFilePath = Server.MapPath("SOAPService.wsdl") WSMLFilePath = Server.MapPath("SOAPService.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("SOAPServiceServer") = SoapServer Application("SoapServerInitialized") = True End If Application.UnLock End If Set SoapServer = Application("SOAPServiceServer") 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 administrator. " & 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 %>

Listado 2. Código de archivo WSDL

Listado 3. Código de archivo WSDL

Uso práctico de los servicios web en IBM Lotus Domino 7

¿Qué son los servicios web y por qué son importantes?

Serie de contenido:

Este contenido es parte # de una serie de # artículos: Uso práctico de los servicios web en IBM Lotus Domino 7

https://www..jsp?series_title_by=Uso+práctico+de+servicios-web+en+ibm+lotus+domino+7

Estén atentos a los nuevos artículos de esta serie.

Es posible que haya visto referencias a servicios web en artículos técnicos, descripciones de productos de software o incluso en conversaciones con compañeros de trabajo. Aparentemente, los servicios web son necesarios e importantes para algunas personas; sin embargo, cuando se encontró con definiciones como "gramática XML para definir conjuntos de puntos finales para mensajería", decidió que no valía la pena tocar cosas tan complejas.

Afortunadamente, los servicios web se pueden explicar de una manera que todos puedan entender sin entrar en detalles de cómo funciona. Debería intentar comprender qué son los servicios web, ya que el alcance de su aplicación (y la arquitectura orientada a servicios relacionada, SOA) en el mundo de TI está en constante expansión.

Los servicios web pueden percibirse como un automóvil: no es necesario saber a nivel técnico cómo funcionan los pistones, los árboles de levas y los inyectores de combustible; puede comprar un automóvil, conducirlo y hablar sobre automóviles con amigos (a menos, por supuesto, que ellos son mecánicos). Lo mismo ocurre con los servicios web; como especialista en TI, sólo necesita comprender qué son y cómo funcionan para comprender por qué los necesita.

Ahora es mucho más fácil trabajar con servicios web sin tocar las tecnologías ocultas de bajo nivel, ya que los proveedores de software y la comunidad de código abierto han hecho mucho en los últimos años para separar la interfaz de los servicios web de las tareas de bajo nivel. Esto le permitirá trabajar simplemente conectando componentes entre sí, sin tener que profundizar en una extensa documentación sobre el formato de mensajes XML.

Esta serie de artículos ayudará a los desarrolladores de Domino a comprender y utilizar los servicios web en IBM Lotus Domino V7.0. Este artículo introductorio contiene mucha información útil que será útil para cualquiera que quiera comprender qué son los servicios web. Las tecnologías de Lotus Domino V7.0 facilitan a los desarrolladores la creación y el uso de servicios web, y entraremos en más detalles sobre esto más adelante.

Primero, comprendamos qué es un servicio web.

¿Qué es un servicio web?

En pocas palabras, un servicio web permite que los programas informáticos se comuniquen entre sí de forma estandarizada.

Comunicación entre tres o más máquinas.

Aunque en los ejemplos consideramos transacciones dentro de una o dos máquinas, los servicios web también se pueden utilizar para comunicaciones entre una gran cantidad de computadoras. Por ejemplo, el reenvío o almacenamiento de transacciones puede realizarse mediante un dispositivo intermedio, o una llamada a un servicio web en un servidor puede resultar en una llamada a un servicio en otro.

Al final de este artículo, cuando analicemos la verdadera SOA, hablaremos de los servicios web que se comunican entre múltiples máquinas, ya que eso es lo que siempre hace SOA.

Un servicio web es un componente abstracto, del mismo modo que lo es el concepto de diálogo entre personas. Un diálogo involucra a dos o más personas que hablan un idioma que conocen. Su lenguaje define las palabras que usan y cómo se usan esas palabras para formar oraciones. Normalmente, un diálogo tiene una estructura de pregunta-respuesta, cuando alguien hace una pregunta o hace una declaración y el interlocutor la responde. Las personas pueden estar cerca, comunicarse por teléfono, enviarse mensajes por correo o chatear.

En cualquier caso, el diálogo tiene una estructura compleja y puede desarrollarse de diferentes formas, dependiendo del número de personas que se comunican, el idioma de comunicación, las tecnologías utilizadas para la comunicación, por supuesto, si se utilizan alguna.

La estructura de las comunicaciones mediante servicios web incluye muchos de los elementos que abordaremos en este artículo. Sin embargo, la idea sigue siendo la misma que la del diálogo normal: los programas se comunican utilizando un lenguaje con el que están familiarizados, a veces a través de una red. Los programas pueden ubicarse en una computadora o en diferentes máquinas en diferentes partes del mundo, conectadas a través de Internet mediante enrutadores y servidores. Lo bueno es que los programas y las computadoras no tienen por qué ser iguales. Gracias a los servicios web, dos programas Microsoft .NET en una computadora portátil pueden comunicarse, al igual que un programa Java en un servidor iSeries canadiense con un programa C++ en una computadora Linux de China.

En las comunicaciones a través de servicios web se utilizan las siguientes tecnologías estándar:

• XML. El idioma (formato de datos) utilizado por los componentes del servicio web.
• Protocolo SOAP. Mensajes XML intercambiados entre programas.
• Biblioteca de descripción de servicios web (WSDL). Archivo XML que define el formato de los mensajes SOAP y cómo enviarlos.

También se puede utilizar una tecnología estándar conocida como Descripción, Descubrimiento e Integración Universal (UDDI) para comunicarse entre servicios web. Veremos esto más adelante en el artículo, pero como no es necesario usar UDDI, muchos servicios web no lo usan.

Algo de terminología: publicación y uso de servicios web

Antes de comenzar a explicar nuestros términos, veamos parte de la terminología asociada con los servicios web.

Cuando hablamos de publicar un servicio web, hablamos de un programa que publica un archivo WSDL y permite que otros programas utilicen el servicio correspondiente. Los programas que publican servicios web se denominan proveedores.

Cuando hablamos de utilizar un servicio web, nos referimos a un programa que realiza una llamada a un servicio web en otra máquina. Los usuarios de servicios web se denominan clientes.

XML: idioma nativo

XML se utiliza para comunicarse entre componentes de servicios web. Los mensajes enviados entre aplicaciones, así como los archivos que definen el servicio web, están en formato XML. La Figura 1 muestra la estructura de un archivo XML simple.

Figura 1. Estructura XML básica

Como puede ver, parte de la información del archivo (como el nombre y el apellido) está rodeada de etiquetas entre corchetes triangulares. El nombre John se muestra como John. También hay elementos en los que se anidan otros elementos, por ejemplo en el elemento Elementos anidados , Y .

Existen muchos beneficios al escribir servicios web en XML, entre ellos:

• La estructura y gramática de XML es similar a la de otros lenguajes de programación, por lo que los programas que interactúan con servicios web no necesitan realizar análisis estructurales de archivos XML directamente.
• Los archivos XML son texto y legibles por humanos (en otras palabras, si conoce XML, puede abrir un archivo XML en un editor de texto y comprender su contenido). Esto puede ayudar con la depuración.
• XML le permite utilizar cualquier codificación estándar en los mensajes, por lo que puede escribir mensajes en inglés, ruso o japonés.
• XML le permite aprovechar lo que se llama un espacio de nombres, en el que puede predefinir la estructura deseada de un elemento de archivo con un nombre específico. Por ejemplo, podría definir un elemento Precio, que siempre debe ser un flotante, o un elemento NombrePersona, que incluye dos subelementos de cadena, Nombre y Apellido.

  Además, si es necesario, los espacios de nombres permiten que varios elementos con el mismo nombre tengan definiciones diferentes. Por ejemplo, un elemento StockPrice en un espacio de nombres puede incluir un símbolo de cotización y un precio, mientras que en otro espacio de nombres puede consistir en un símbolo de cotización, un precio, un máximo y mínimo diario y un máximo de 12 meses.

Las únicas desventajas de XML, si es que realmente lo son, son:

• XML es un lenguaje rígido, por lo que cualquier formato incorrecto de un mensaje XML hará que falle el análisis del mensaje completo (incluso si el problema es fácil de interpretar o se pasa por alto). Sin embargo, si utiliza la biblioteca estándar para generar archivos XML (que es lo que hace al crear servicios web), la propia biblioteca comprueba el formato correcto.
• Un mensaje XML se almacena en un archivo de texto sin formato y, por lo tanto, ocupa más espacio que su equivalente en otro formato (como un formato simplificado, binario o "hecho en casa").

Pero estos problemas son insignificantes en comparación con los beneficios del formato XML.

SOAP: mensajes enviados

Usted sabe que los servicios web se comunican en formato XML, pero esto sólo resuelve la mitad del problema. Las aplicaciones pueden analizar el mensaje, pero ¿cómo saben qué hacer con el resultado obtenido tras el análisis?

La instrucción que describe las reglas para formatear mensajes XML para servicios web se conoce como SOAP. Define una estructura de mensaje para que los programas sepan cómo enviar e interpretar datos. La estructura básica de un mensaje SOAP se muestra en la Figura 2.

Figura 2. Estructura básica de mensajes SOAP

En XML se vería así:

FOO

En el caso base, tiene un paquete SOAP que incluye un cuerpo SOAP y un cuerpo que contiene los datos que se van a transferir. A veces también hay un encabezado SOAP opcional (dentro del paquete antes del cuerpo) que contiene información adicional.

instrucciones de jabón

Aunque el formato SOAP es estándar y tiene las mismas instrucciones, hay que recordar que diferentes fabricantes pueden implementar estas instrucciones de forma ligeramente diferente. Por ejemplo, la estructura de espacios de nombres y XML en un mensaje SOAP generado por Apache Axis puede ser muy diferente de la estructura generada por Microsoft .NET. Sin embargo, un cliente o servidor escrito correctamente puede procesar cualquier mensaje que esté escrito correctamente según las instrucciones SOAP.

Además, existen algunas diferencias importantes entre las declaraciones WSDL 1.1 y WSDL 2.0. Aunque la instrucción 2.0 aún se encuentra en sus etapas finales al momento de escribir este artículo, pronto comenzará a reemplazar a la versión 1.1.

Si nunca antes ha encontrado un archivo WSDL e intenta abrir uno y leerlo, le resultará difícil obtener toda la información, ya que la estructura de dicho archivo puede ser bastante compleja. Toda la información sobre el método (nombre, parámetros, protocolo, etc.) se encuentra dispersa en diferentes secciones del archivo y, para construir un mensaje SOAP, la aplicación cliente debe recopilarlo. Este artículo no describirá las partes del archivo WSDL y cómo funcionan juntas.

Aquí es donde la tecnología vuelve a venir en nuestra ayuda. Como desarrollador, no es necesario leer, analizar ni comprender el contenido del archivo WSDL. Las herramientas obtendrán esta información por usted, por lo que solo necesita decidir qué enviar al servicio y dónde colocar los resultados. tu no eres solo puede utilizar bibliotecas y herramientas, pero también con seguridad Vas a. Hay bastantes excepciones, peculiaridades y complejidades en todos los componentes de los servicios web que usted debe considerar. usando Servicio web, en lugar de desmontarlo seguido de un estudio detallado de cada componente.

Protocolos: cómo se envían los mensajes

Todavía no hemos abordado la cuestión de cómo se transmiten todos estos mensajes a través de SOAP.

Y normalmente se transmiten a través de la red (y/o Internet) utilizando el protocolo HTTP, casi de la misma manera que las páginas se transmiten desde el servidor a su navegador. No siempre se utiliza HTTP (su principal competidor es SMTP, pero está muy por detrás). El protocolo utilizado por el servicio web se define en el archivo WSDL.

Normalmente, el archivo WSDL define el protocolo utilizado para transportar el mensaje SOAP como HTTP. El cliente SOAP envía mensajes según el protocolo especificado.

Otros términos de servicios web que puede encontrar

Ya hemos cubierto los términos básicos, pero es posible que escuche algunos más cuando habla de servicios web.

Lazos débiles

Los programas que utilizan servicios web suelen tener conexiones débiles con los servicios, es decir, los servicios necesarios para que el programa funcione no están directamente vinculados a él, al igual que el programa no está vinculado a los servicios. El programa puede utilizar fácilmente cualquier servicio que necesite y esperan una llamada del programa, de cualquier programa que necesite su respuesta.

Un ejemplo real de vínculos débiles es almorzar con amigos. Varios amigos se ponen de acuerdo de alguna manera (en persona, por teléfono, por correo electrónico, etc.). Cada uno llega al restaurante por su cuenta y, después del almuerzo, cada uno paga su propia comida. No importa cómo haya ido el almuerzo, el resultado final es el mismo: fue un almuerzo amistoso.

Pero conducir un coche es una acción con conexiones más rígidas. Tiene un conjunto fijo de herramientas con las que necesita alcanzar objetivos predefinidos. Al salir del garaje, pones la marcha atrás y pisas el acelerador. Cuando giras a la izquierda, giras el volante hacia la izquierda. No tienes la oportunidad de hacer lo mismo de diferentes maneras, ya que todo el sistema es muy preciso y coherente, y cada uno de sus elementos está conectado con los demás.

UDDI

UDDI es un estándar para crear un catálogo de servicios web entregados por cualquier número de programas. Es algo así como una guía telefónica para proveedores de servicios web. Los clientes pueden buscar la información que necesitan en el registro UDDI y el registro les devuelve los datos necesarios para conectarse al servicio.

Aunque UDDI es un estándar bastante importante para definir los servicios web, su importancia se ve muy disminuida por el hecho de que es un elemento opcional de los servicios web, y cuando se les da la opción de usarlo o no, muchos optan por no usarlo.

La mayoría de los entornos empresariales organizados con una gran cantidad de servicios web internos tienen registros UDDI. Es genial tener un sitio web corporativo UDDI que contenga información sobre los servicios web disponibles en su empresa. Al reunir todos los servicios, UDDI le permite cambiar de proveedor de servicios sin problemas y sin problemas. Si los clientes buscan servicios a través de UDDI, las llamadas SOAP se envían automáticamente al nuevo proveedor.

Sin embargo, este componente no es necesario en una arquitectura de servicios web.

Seguridad de servicios web

Al leer sobre SOAP y WSDL, es posible que observe que el tema de seguridad no está cubierto. ¿Cómo se realiza la autenticación para las llamadas de servicio si el proveedor trabaja con información confidencial? Está claro que no todos los servicios web están disponibles para el público en general, ¿verdad?

Esta es una pregunta importante que no es fácil de responder de manera definitiva. Existen varios esquemas que puedes utilizar, según la situación, por ejemplo:

• ¿Los mensajes SOAP pueden llegar como texto o deben estar cifrados?
• ¿Es suficiente para usted la simple autenticación de inicio de sesión y contraseña, o debería ser segura y basada en tokens?
• Si se utilizan tokens, ¿es necesario firmarlos y cuál es la forma correcta de incluirlos en un mensaje SOAP?
• ¿Qué pasa si el cliente envía mensajes SOAP no directamente, sino a través de alguna estructura intermedia, como una cola de mensajes o algún otro servicio web?

Además, es posible que la mensajería no siempre utilice HTTP, por lo que no podrá utilizar simplemente sistemas de seguridad de servicios web además de los sistemas de seguridad HTTP existentes.

Existen varias pautas que cubren estos y otros aspectos de la seguridad de los servicios web: WS-Security, WS-Policy, WS-Trust y WS-Privacy. Algunos proveedores de software y comités han estado trabajando en estos temas durante varios años. Aunque no todas las implementaciones de servicios web admiten todas las directrices de seguridad, los estándares de seguridad disponibles suelen implementar al menos algunas rutas de seguridad básicas.

Bus de servicios empresariales y middleware

Existe otro conjunto bastante grande de estándares para servicios web, reunidos en un conjunto bastante grande, que generalmente se denominan instrucciones WS-*. Juntos abordan muchas de las consideraciones de diseño que surgen cuando se ensamblan muchos servicios web en un entorno. Los estándares WS-* abordan cuestiones tales como:

• Seguridad
• Fiabilidad
• Intercambio de mensajes
• Actas
• Calidad de servicio

Esta cantidad de estándares es necesaria porque el intercambio de mensajes entre un cliente de servicio web y un servidor en un entorno industrial puede ser mucho más complejo que una simple solicitud/respuesta. Por ejemplo, ¿cómo se asegura que el mensaje llegue al proveedor y regrese al cliente? ¿Qué pasa si una solicitud SOAP tiene varias partes? ¿Cómo se gestionan los procesos que implican que los servicios web accedan a otros servicios web? ¿Qué pasa si el programa envía una secuencia de solicitudes con requisitos de tiempo de respuesta?

Para las grandes empresas de software, trabajar con estos estándares presenta tanto desafíos como oportunidades. Algunos proveedores comercializan paquetes completos de middleware de servicios web, a menudo llamados Enterprise Service Buses o ESB, que pueden manejar todas o al menos algunas de las tareas anteriores. Estos ESB también son valiosos porque pueden unir múltiples servicios web dentro de la misma organización y proporcionar su funcionalidad, registrando sus acciones y almacenando mensajes en colas.

Arquitectura orientada a Servicios

Y finalmente, la arquitectura orientada a servicios. En la mayoría de los casos, es simplemente una combinación de todo lo anterior: servicios web poco acoplados de diferentes proveedores, que interactúan de acuerdo con estándares aceptados (posiblemente con la participación del ESB) y recopilados en conjunto mediante diferentes programas que toman datos de los servicios. y usarlo de diferentes maneras.

Dado que SOA es una arquitectura de software, su construcción conlleva una gran cantidad de trabajo de coordinación y planificación. No se trata sólo de un conjunto de servicios reunidos; es la organización de cómo se crean y publican los servicios, qué herramientas de gestión y middleware se utilizan, y cómo se supervisan y gestionan los servicios y todo el sistema.

Si miramos más globalmente, SOA también es un tipo de pensamiento. Te hace pensar no en grandes programas que se ejecutan de forma independiente, sino en percibir todo como posibles componentes que pueden publicarse y utilizarse en producción. En lugar de aplicaciones ricas en funciones, se piensa en servicios específicos y bien definidos, que es lo que son los servicios web.

¿Por qué es importante?

Ahora ya sabe algo sobre cómo funcionan los servicios web: el cliente lee el archivo WSDL del proveedor, lo formatea y envía un mensaje SOAP de acuerdo con él, y recibe otro mensaje SOAP en respuesta. Entonces, ¿por qué es esto tan importante? ¿Qué pasa?

Parte de la importancia de los servicios es que proporcionan una forma estándar para que los programas se comuniquen, independientemente de los idiomas en los que estén escritos o las plataformas en las que se ejecuten. Anteriormente, teníamos que trabajar con formatos de datos que eran exclusivos de diferentes programas o con funciones de nivel API con las que los programas en otros lenguajes no podían funcionar. El uso de XML en todos los estándares de servicios web significa que todos los servicios son accesibles y están claramente definidos.

De hecho, esto permite que programas completamente diferentes se comuniquen fácilmente entre sí en un idioma que todos comprendan. Uno de los principales desafíos al trabajar con diferentes tecnologías de diferentes fabricantes siempre ha sido la necesidad de lograr que todos estos programas diferentes se comuniquen entre sí e intercambien datos. Ahora que todas sus aplicaciones pueden entregar y/o consumir servicios web, la interoperabilidad entre ellas es increíblemente simple.

Otra ventaja de los servicios web es que los clientes y proveedores pueden estar en diferentes máquinas, utilizando diferente hardware y software, y esto no interferirá con la comunicación. Los programas pueden ser utilizados por otros programas dentro de la misma máquina, o desde otras máquinas, pero usando un formato de transferencia de datos específico. Los servicios web sólo necesitan una conexión de red y un procesador XML.

Si se tienen en cuenta todos estos factores juntos, el resultado es significativo. Dado que tenemos un medio estándar para la comunicación entre aplicaciones a través de la red, podemos construir nuestros programas de manera diferente. En lugar de escribir programas monolíticos que reinventan la rueda cada vez, podemos escribir programas que constan de módulos.

Por ejemplo, en lugar de un programa grande que recopila información sobre varios procesos, la convierte en gráficos y los muestra a los usuarios, podemos crear un panel que muestre los datos recibidos de varios servicios web. Los datos compilados se reciben de uno o más servicios y los gráficos resultantes son creados por otro servicio web que acepta los datos y produce un gráfico.

El tablero se transforma de un programa grande a una interfaz simple. Cuando queremos agregar nuevos componentes, simplemente recurrimos a servicios adicionales. Si necesitamos un gráfico diferente, recurrimos a otro servicio de gráficos. Si necesitamos un panel más interactivo, con capacidades de capacitación o clasificación, entonces el panel puede transmitir mensajes del usuario al servicio apropiado. Incluso podemos cambiar completamente los servicios a los que se llama para que los usuarios no se den cuenta (siempre que el archivo WSDL no cambie), y el panel seguirá siendo el mismo.

Como profesional de TI, puede desarrollar tanto interfaces como servicios, o ambos. Comprender cómo funciona todo en conjunto (o al menos saber qué es) es importante cuando se trabaja en un proyecto como este.

También es bueno que existan muchas herramientas que le ayudarán a ofrecer y utilizar servicios web y que pueden hacer gran parte del trabajo pesado por usted. En las siguientes partes del artículo, comprenderemos cómo utilizar IBM Lotus Domino V7.0 puede entregar fácilmente servicios web a clientes o sistemas.

¿Donde empezamos? Y directamente del contacto cliente-artista: suena el teléfono en el estudio de Internet. El administrador de cuentas levanta el teléfono y lo saluda. Desde ese lado suena algo así como:

- Buenas tardes. Necesito un sitio web, uno simple. ¿Cuál es el precio? (la misma historia con las aplicaciones web).

Esto es realmente un dolor de cabeza para todas las cuentas. Pero no se pone nervioso y explica que los sitios varían en complejidad, funcionalidad, etc. Aclara lo que el cliente necesita y lo que significa "simple" en su comprensión. Por ejemplo, recibe la siguiente respuesta:

- Bueno, verás, tengo un negocio de venta de ventanas. Sería bueno crear un sitio web para poder crear una ventana "virtual" para usted. Elige color, materiales, tallas. Especificar cantidad. Vea cómo se verá. Bueno, entonces nuestros especialistas irían al lugar. ¿Acordado?

Esto ya es interesante. Pero eso no es todo:

- Y sí, tengo otro deseo. Contamos con divisiones en Moscú, San Petersburgo y Novosibirsk. El personal es numeroso, hay papeleo, bueno, ya lo entiendes. Puedes hacer algo como... una pequeña red social dentro del sitio, ¿o qué? Nos resultará más cómodo comunicarnos así, sin “ases”. Y almacene documentos en una "nube". Escuché que hacen esto.

El administrador de cuentas anota todo, hace una estimación aproximada y menciona el costo. El cliente potencial pone los ojos en blanco (esto se puede escuchar incluso por teléfono), dice "sus precios son de otro mundo" y cuelga cortésmente.

Por supuesto, esta es una situación megaexagerada, pero esto sucede todo el tiempo tanto al programar aplicaciones de Internet como al crear sitios web. Nuestro objetivo es descubrir por qué sucede esto.

¿Qué es un servicio web?

El desarrollo de un servicio web es, en general, el mismo desarrollo de un sitio web. Pero hay un gran "PERO": a diferencia de los sitios promocionales y eventos corporativos que todos conocen, el servicio en línea tiene una funcionalidad única. Podría ser un diseñador de producto (como en el ejemplo anterior), alojamiento de fotografías, una red social cerrada para uso corporativo, una red social abierta (danedaiboh), un tablón de anuncios...

En su mayoría, quienes deciden crear un servicio web son aquellos que confían en la innovación, la conveniencia y las tecnologías web modernas. En este caso, la funcionalidad única actúa como la “carta de triunfo” del negocio, con su ayuda debería sofocar a los competidores y aumentar la base de clientes.

Y todo lo que esto significa es que:

• Tomará algún tiempo descubrir todas las posibilidades para el futuro proyecto. Generalmente mucho tiempo.
• Se requerirá una especificación técnica detallada. O mejor aún, un prototipo.
• Necesitará desarrollar el servicio web en sí (inesperadamente, ¿verdad?). Hazlo desde cero o utilizando desarrollos existentes. Pero en cualquier caso será imposible “montarlo” de rodillas, fuera de la caja, según una plantilla y “rápidamente”.
• El producto deberá probarse minuciosamente antes de su lanzamiento.

Como resultado, el precio de creación de un servicio web (junto con su programación) variará. Pero siempre será superior al de un sitio con un conjunto de funciones “típico”.

Para nuestro ejemplo: cuando el cliente mencionó una red social interna, un almacenamiento en la nube para datos y un diseñador de ventanas, todo esto en conjunto se hizo posible llamar un servicio web. Por eso el coste fue calificado de “inesperado” para el cliente.

Los precios “espaciales” en el desarrollo de servicios de Internet son una medida justificada. Se trata de un trabajo objetivamente difícil y largo.

Si una empresa necesita un servicio de este tipo es una tarea para sus especialistas en marketing.

Un tema especial y favorito de todos son las redes sociales.

Aquí pasan cosas bastante curiosas. Además, estas comedias se representan con cara seria. Por ejemplo, un cierto porcentaje activo de escolares, usuarios "avanzados" de VKontakte, quieren constantemente su propio juego. Hasta un éxito vertiginoso. Y para no molestar.

Como resultado, recibimos toneladas de cartas en nuestra bandeja de entrada y en la comunidad con el texto "vender/desarrollar una aplicación comercial/juego/algo más para nosotros". Algo como esto:

Sí, 5.000 rublos por varias semanas de trabajo, está bien. Ahora estamos hablando sólo de copias adecuadas, y no de aquellas que ganan una audiencia de 200 usuarios y desaparecen.

Si todavía lo supera la manía de hacer un clon exitoso, al menos piense en cuánto les costó a los autores del original promover y promover una aplicación o servicio web (generalmente este es el presupuesto de desarrollo multiplicado por diez).

No cometas errores. Calcula tu fuerza. Lanzar proyectos exitosos en Internet. Amén.

Un servicio web es un programa al que otros programas pueden acceder a través de Internet (http). Por ejemplo, digamos que tiene una función que proporciona texto en formato HTML. El propósito de la aplicación es que el navegador web muestre los resultados y una persona pueda leer fácilmente este texto en la página.

Por otro lado, el público objetivo de un servicio web son otros programas u otros servicios web que consumen los datos proporcionados por el servicio web. Normalmente, el resultado está en un lenguaje estándar que otros programas pueden entender. Tomemos el ejemplo anterior: si un servicio web genera texto en formato XML, otros servicios web que puedan leer o comprender XML pueden utilizar esa salida.

La principal ventaja de un servicio web es que las aplicaciones pueden escribirse en cualquier idioma, pero pueden comunicarse e intercambiar datos entre sí a través del servicio web. Las aplicaciones de software escritas en diferentes lenguajes de programación y que se ejecutan en diferentes plataformas pueden utilizar servicios web para comunicarse a través de Internet (HTTP). Esta interacción (por ejemplo, entre Java y Python, o aplicaciones de Windows y Linux) implica el uso de estándares abiertos (XML, SOAP, HTTP).

• SOAP (Protocolo simple de acceso a objetos)
• UDDI (Descripción Universal, Descubrimiento e Integración)
• WSDL (lenguaje de descripción de servicios web)

¿Cuántos tipos diferentes de servicios web existen?

Principalmente, existen dos tipos de servicios web, el Protocolo simple de acceso a objetos (SOAP) y la Transferencia de estado representacional (REST).

• El servicio web SOAP acepta una solicitud en formato XML y genera una salida en formato XML.
• El servicio web REST es más versátil y puede aceptar XML y JSON como solicitud y genera resultados en XML, JSON o incluso HTML.

Este tema se puede estudiar con más detalle en el nuestro.