Alexander Kachanov
La idea de los servicios web fue desarrollada por gigantes de la industria informática como Sun, Oracle, HP, Microsoft e IBM. Esta idea no es nada nuevo, pero es un gran paso adelante hacia un acceso más fácil a los programas a través de la web. Basados en formatos de comunicación estándar, los servicios web podrían cambiar completamente nuestra forma de pensar sobre cómo deberíamos crear sitios web.
¿Qué es un servicio web?
Gracias a los servicios web, las funciones de cualquier programa pueden estar disponibles a través de Internet. Por lo tanto, programas como PHP, ASP, scripts JSP, JavaBeans, objetos COM y todas nuestras otras herramientas de programación favoritas ahora pueden acceder a algún programa que se ejecuta en otro servidor (es decir, un servicio web) y utilizar la respuesta recibida de ella en su sitio web, o solicitud.
Digamos que si necesito realizar alguna tarea de programación y estoy demasiado ocupado (o loco para reinventar la rueda nuevamente), puedo usar los servicios de un servicio web al que mi sitio accederá a través de Internet. Al pasar una solicitud con parámetros al servicio web, espero recibir una respuesta que contenga el resultado de ejecutar mi solicitud.
Cualquiera que haya trabajado alguna vez en Últimamente Con hotmail, ya se ha encontrado parcialmente con servicios web: el sistema de autenticación de usuarios Passport es uno de los servicios incluidos en la iniciativa Microsoft .NET. Actualmente está disponible de forma gratuita, por lo que los creadores de sitios web pueden implementar fácilmente la autenticación de usuario en su sitio.
Lo esencial
Los principios detrás de los servicios web son sorprendentemente simples. Y no añaden nada nuevo al mundo de la informática distribuida e Internet:
- el responsable del servicio web determina el formato de las solicitudes a su servicio web y sus respuestas
- cualquier computadora en la red realiza una solicitud a un servicio web
- Un servicio web procesa una solicitud, realiza alguna acción y luego envía una respuesta.
Esta acción podría ser, por ejemplo, mostrar una cotización de bolsa, mostrar el precio de un producto en particular, guardar una entrada en un calendario de citas, traducir texto de un idioma a otro o verificar un número de tarjeta de crédito.
Estándares en el centro
La razón por la que de repente todos nos interesamos por los servicios web es que se basan en estándares, protocolos abiertos para el intercambio y la transferencia de datos.
Antes de esto, muchas empresas desarrollaron sus propios estándares y formatos propietarios. Y ahora, para trabajar, solo necesitamos conocer XML (lenguaje de marcado extensible), que se transmite a través del antiguo y familiar protocolo HTTP. Esto significa que la información sobre cómo funcionan los servicios web está disponible para todos, y los desarrolladores web que estén familiarizados con estas tecnologías de profesión pueden empezar a jugar con los servicios web hoy mismo.
La diferencia entre los servicios web y otras tecnologías que los desarrolladores han encontrado (por ejemplo, DCOM, canalizaciones con nombre, RMI) es que los servicios web se basan en estándares abiertos, son fáciles de aprender y estos estándares cuentan con un amplio respaldo en todo el mundo. y plataformas Windows.
El Protocolo simple de acceso a objetos (SOAP) es un protocolo estándar desarrollado por el W3C. Define el formato de las solicitudes a los servicios web.
Los mensajes entre un servicio web y su usuario se empaquetan en sobres SOAP. Los mensajes contienen una solicitud para realizar alguna acción o una respuesta, el resultado de realizar esta acción. El sobre y su contenido están codificados en XML y son bastante fáciles de entender. Así es como se ve una solicitud SOAP simple cuando se envía vía HTPP a un servicio web:
xmlns:m="http://www.somesite.com/Postcode">
Los elementos clave de un sobre SOAP son bastante fáciles de descubrir: estos son dos parámetros (
Y la respuesta se verá así:
xmlns:m="http://www.somesite.com/Postcode">
Este mensaje es aún más fácil de descifrar. Elemento
Ahora sobre UDDI
Aunque el protocolo SOAP es sencillo, los servicios web serían de poca utilidad si no tuviéramos forma de encontrarlos. Afortunadamente, IBM, Microsoft y Ariba dieron un paso adelante y crearon el proyecto Universal Descripción, Descubrimiento e Integración (UDDI), que esperan se convierta en un catálogo común de todos los servicios web en la Web.
El sistema UDDI permite a las empresas exponer su servicio web al público. Este directorio funciona como una guía telefónica para todos los servicios web. El registro en el directorio UDDI es gratuito, y los fundadores del proyecto esperan que este directorio contenga descripciones de todos, todos, todos los servicios en la Web, de modo que para encontrar el servicio web deseado, solo necesitará recurrir a un UDDI. directorio.
¿Cómo funciona todo?
Entonces, ¿cómo encuentro el servicio web adecuado?
Imaginemos que soy desarrollador de un sitio web y mi cliente me pidió que lo agregara al sitio. nueva caracteristica: Debe agregar una verificación de código postal a su formulario de registro.
Para realizar esta verificación, necesitaría crear una base de datos de todos los códigos postales en los 30 países donde nuestra empresa opera y luego verificar que el código postal corresponda a la ciudad especificada en el registro al registrarme. Pero no tengo estos datos y creo que para recopilarlos habrá que gastar una cantidad importante de dinero.
En lugar de desembolsar dinero para comprar una base de datos, escribir el código yo mismo, asegurar la integridad y corrección de todos los datos y depurar los scripts, simplemente voy al directorio UDDI y veo si hay un servicio web que pueda hacer el trabajo. a mí . Al llegar al sitio http://www.uddi.org/, lanzo una búsqueda y encuentro un excelente servicio de XYZ Corp.
Reviso cuidadosamente la definición del formato del servicio web (la definición está escrita en WSDL (lenguaje de descripción de servicios web), asegurándome de que el servicio haga exactamente lo que necesito. Luego verifico con mis colegas la reputación de XYZ Corp. y averiguo que es sólido y luego me comunico con XYZ Corp. para consultar el precio. Si el precio para acceder al servicio está dentro de mi presupuesto, escribo una página JSP simple para mi sitio que llama al servicio web de XYZ Corp. y he aquí, La verificación instantánea aparece en el código postal del sitio.
Vale la pena tu tiempo
Incluso si no tiene nada que ver con la programación o las tecnologías de desarrollo de sitios web, vale la pena aprender más sobre los servicios web. Imagine una imagen de cómo está discutiendo un nuevo sitio web con un cliente, discutiendo todas las funciones del nuevo proyecto. Todo va muy bien: el presupuesto cumple con las expectativas del cliente, le gustó el boceto del plano del sitio y le gustaron los ejemplos de la interfaz. Todo parece estar funcionando.
Y de repente recuerdan alguna función muy compleja. Con solo mencionarlo, la cara de su desarrollador web se pone verde y comienza a ahogarse y toser. Este es el desarrollador que le da una señal de que desarrollar esta función requerirá mucho dinero y tiempo o simplemente no es factible con ese presupuesto.
¡Deja tu miedo! Estoy dispuesto a garantizar que ya existe un servicio web en Internet que está listo para brindarle la función requerida, y el costo de utilizar este servicio web será mucho menor que el costo de desarrollar su análogo de forma independiente. De esta manera usted evita que su desarrollador sufra dolores de cabeza innecesarios y que su cliente sufra desperdicio innecesario dinero simplemente dedicando un par de minutos a navegar por el directorio UDDI.
Desarrollo de servicios
Por supuesto, los desarrolladores no tienen que contentarse sólo con servicios web creados por otros. Con uno de los siguientes kits de herramientas, puede crear su propio servicio web y proporcionar sus servicios a otros usuarios de Internet.
La elección de herramientas para desarrollar servicios web es amplia. Incluye herramientas de empresas como Sun (Open Net), Microsoft (.NET), (servicios electrónicos) e IBM (servicios web). También existen marcos de código abierto. Por ejemplo, el Proyecto Mono pretende reemplazar el conjunto de herramientas .NET de Microsoft proporcionando compiladores, tiempo de ejecución y bibliotecas para ejecutar los mismos servicios web en todas las plataformas, incluido Unix.
A pesar de la variedad de servidores y herramientas de desarrollo de servicios web, todos admiten el mismo protocolo SOAP, lenguaje XML y sistema UDDI.
Desventajas
Antes de abandonar por completo mi carrera como programador y dedicarme a utilizar servicios web, tengo que hacerme la pregunta: "Es un panorama demasiado halagüeño. ¿Qué tiene de malo?". Desafortunadamente, el gran potencial de los servicios web tiene un precio:
- El uso de XML como formato de transferencia de datos significa que sus mensajes tendrán un tamaño muy grande: las etiquetas XML en sí mismas ocupan mucho espacio, y esto nos impone una cierta carga a la hora de crear, transmitir e interpretar mensajes.
- ya que usamos computadoras remotas Dependemos completamente de Internet para realizar ciertas funciones, lo que crea demasiados vínculos poco confiables en la cadena entre nuestro servidor web y el servicio web.
- Hoy en día, pocas empresas crean servicios web y pocas empresas los utilizan. Depurar y mejorar el sistema de servicios web todavía lleva mucho tiempo.
- Los desarrolladores aún no han aceptado el sistema de concesión de licencias y cobro por el uso de servicios web. Debido a que todavía hay muy pocos servicios web, la mayoría de las empresas intentan dar una buena impresión a sus clientes potenciales reduciendo deliberadamente el coste de los servicios y ofreciendo condiciones de licencia favorables. Aún pasará algún tiempo antes de que quede claro el coste real de los servicios web.
Cuando los servicios web ocupen su lugar y estén disponibles para todos, se convertirán en una ayuda invaluable para los desarrolladores web. Nos darán acceso flexible a toda la potencia de todos los ordenadores de la Red. Es hora de que los creadores de sitios web se interesen por los servicios web y aprendan más sobre lo que pueden obtener de ellos.
Anotación: Áreas de uso. Ventajas. Características del desarrollo de servicios web para la plataforma .NET. Descripción y descubrimiento de un servicio web.
¿Qué es el servicio web XML?
A medida que se desarrolló la tecnología de la información, surgieron diferentes enfoques para escribir programas: modular programación, evento conducido programación, orientado a componentes programación y diseño. La continuación lógica de estos enfoques estaba orientada al servicio. desarrollo de software.
El uso de enfoques orientados a servicios nos permite hablar de reutilización a nivel macro (nivel de servicio), en contraposición al nivel micro (nivel de objeto). El enfoque orientado a servicios utiliza estándares simples y generalmente aceptados, lo que permite que una amplia variedad de aplicaciones compartan la funcionalidad de las demás. Los servicios se pueden escribir utilizando una variedad de lenguajes de programación, en varias plataformas. Además, los servicios se pueden implementar por separado o como parte de un paquete de software en cualquier parte del mundo y, por lo tanto, brindarán acceso a su funcionalidad a través de la red.
Llamemos servicio recurso que implementa una función empresarial y tiene las siguientes propiedades:
- es reutilizable;
- definido por una o más interfaces explícitas independientes de la tecnología;
- está débilmente acoplado a otros recursos similares y puede invocarse a través de protocolos de comunicación que permiten que los recursos interactúen entre sí.
Un caso especial de servicio es un servicio web XML.
Servicio web XML es un tipo especial de aplicación web que:
- implementado en un servidor web;
- publica métodos web que pueden ser invocados por clientes externos;
- espera la recepción de solicitudes HTTP, que son comandos para llamar a métodos web;
- ejecuta métodos web y devuelve resultados.
A diferencia de una aplicación web tradicional, un servicio web no tiene una interfaz de usuario. En cambio, tiene una interfaz de programación, es decir, el servicio web expone funciones (métodos web) que se pueden llamar de forma remota (por ejemplo, a través de Internet). El servicio web no está destinado a servir a los usuarios finales. Su trabajo es proporcionar servicios a otras aplicaciones, ya sean aplicaciones web, aplicaciones GUI o aplicaciones de consola.
Un servicio web puede proporcionar información en tiempo real sobre los precios de las acciones, consultar tarjetas de crédito o informar el pronóstico del tiempo. Los servicios web son tan diversos como las aplicaciones normales.
Los servicios web no son propiedad de una empresa específica. Es un estándar de la industria basado en protocolos abiertos (SOAP, HTTP, etc.). Los servicios web se implementan en varias plataformas (incluidos servidores que ejecutan Windows o UNIX). Los servicios web se pueden desarrollar utilizando muchas herramientas de desarrollo (desde un editor de texto hasta la familia Microsoft Visual Studio).
Los métodos de la mayoría de los servicios web son llamados mediante solicitudes HTTP que contienen mensajes SOAP. SOAP es un lenguaje XML (vocabulario XML) para llamar a procedimientos remotos a través de HTTP y otros protocolos (descripción completa de SOAP http://www.w3.org/TR/SOAP) .
El lugar de los servicios web entre otras tecnologías de llamadas remotas
Existen bastantes protocolos y tecnologías de invocación remota: el modelo de objetos componentes distribuidos (DCOM) de Microsoft, la arquitectura de agente de solicitud de objetos común (CORBA) del grupo de gestión de objetos, la invocación de método remoto (RMI) de Sun, . NET Remoting, Servicios Web XML.
Todas estas tecnologías basadas en componentes (DCOM, CORBA y RMI) se han utilizado con éxito en aplicaciones de Intranet durante muchos años. Proporcionan una arquitectura confiable y escalable. Sin embargo, existen dos problemas graves con el uso de estas tecnologías en Internet. En primer lugar, no interactúan bien entre sí. Todas las tecnologías operan sobre objetos, pero difieren significativamente en detalles: gestión del ciclo de vida, soporte de constructores y grado de soporte de herencia. El segundo aspecto, más importante, es que centrarse en las interacciones RPC conduce a la construcción de sistemas estrechamente acoplados basados en llamadas explícitas a métodos de objetos.
A diferencia de estas tecnologías, los servicios web XML y. NET Remoting están completamente implementados enfoque orientado a objetos para programación web.
Servicio web XML- un componente que proporciona a los clientes de Internet un conjunto de funciones API o métodos web. XML está incluido en el nombre porque los servicios web y sus clientes lo utilizan para intercambiar datos. Los servicios web se basan en estándares abiertos como HTTP, XML (lenguaje de marcado extensible), SOAP (Protocolo simple de acceso a objetos, un estándar de Internet que describe cómo las aplicaciones pueden interactuar, es decir, llamarse entre sí, utilizando HTTP y otros protocolos). La tarea principal de los servicios web es garantizar la interacción entre programas. Muchos funcionan en servidores UNIX y a ellos acceden clientes Windows. Los datos enviados a los servicios web se serializan en XML y se envían en paquetes SOAP. Los metadatos sobre el contenido de dichos mensajes se almacenan en el contrato WSDL del servicio web y en los esquemas XSD. La principal ventaja de este enfoque es la legibilidad de los metadatos. El desarrollador puede ver fácilmente la descripción completa del servicio web e incluso crear su propio módulo que analiza paquetes SOAP.
.NET remoto Proporciona infraestructura para objetos distribuidos. Es mucho más complejo que una simple arquitectura de servicios web de paso de mensajes. . NET Remoting incluye paso de parámetros por referencia y valor, devoluciones de llamadas, activación de múltiples objetos y políticas de administración del ciclo de vida. Para utilizar estas funciones, la aplicación cliente debe dominar todas las tecnologías. Datos c. NET Remoting se transmiten en formato binario o SOAP. Sin embargo, en cualquier caso, los metadatos sobre la estructura de la información transmitida están contenidos en el entorno de ejecución del lenguaje común. Sin un Common Language Runtime (CLR), la aplicación cliente no podrá analizar lenguajes específicos. NET encabezados SOAP remotos. Eso es. NET Remoting impone requisitos significativamente mayores en comparación con los servicios web.
Desarrollo de servicios web sobre la plataforma .NET.
Hay muchas formas de escribir servicios web. Se pueden desarrollar manualmente o utilizando herramientas SOAP proporcionadas por Microsoft, IBM, etc. Redacción de servicios web utilizando Microsoft. NET tiene dos ventajas:
- .NET Framework simplifica enormemente el proceso de desarrollo al proporcionar una biblioteca de clases y automatizar etapas de desarrollo individuales;
- Los servicios web escritos con .NET Framework son aplicaciones administradas. Es decir, dichas aplicaciones no tienen problemas con pérdidas de memoria, punteros inicializados incorrectamente y otros problemas típicos de programación.
Creación
Desarrollemos un servicio web AdditionService simple que suma dos números. Tendrá solo un método Add, que toma dos números enteros como parámetro y también devuelve un número entero. AdditionService demuestra varios principios importantes de programación de servicios web utilizando Microsoft .NET Framework.
- Los servicios web se implementan como archivos ASMX. ASMX es una extensión de nombre de archivo especial registrada en ASP .NET (más específicamente, el controlador HTTP de ASP.NET) en el archivo de configuración principal de ASP .NET Machine.config.
- Los archivos ASMX comienzan con la directiva @WebService. Esta directiva debe contener al menos el atributo Class, que especifica la clase en la que consiste el servicio web.
- Las clases de servicios web pueden tener atributos de servicio web opcionales. EN en este ejemplo Este atributo especifica el nombre y la descripción del servicio web que se muestra en la página HTML cuando el usuario llama a AdditionService.asmx en el navegador.
- Los métodos web se declaran asignando el atributo WebMethod a los métodos públicos de la clase de servicio web. Para los métodos auxiliares que se utilizan internamente pero que no están disponibles para clientes externos, este atributo simplemente no se especifica.
- HTTP, XML y SOAP son "invisibles". .NET Framework maneja datos XML y mensajes SOAP.
AdditionService.asmx<%@ WebService language="C#" Class="AddService" %>usando System usando System.Web.Services clase AddService (public int Add (int a, int b) (return a + b))
A pesar de su pequeño tamaño, AdditionService.asmx es un servicio web completo si se instala en un servidor web con ASP.NET. Sus métodos se llaman mediante SOAP, HTTP GET y HTTP POST, y puede devolver resultados como respuestas SOAP o como simples contenedores XML.
Usando código en segundo plano, las clases de servicios web se pueden mover de archivos asmx a archivos separados.
Los servicios web apoyan el uso tipos de datos complejos como parámetros de entrada o salida. Se admiten tipos de datos complejos porque XML permite serializar fácilmente la mayoría de los tipos de datos. Sin embargo, cuando se prueba automáticamente un servicio web, ASP .NET no genera páginas de prueba para los métodos que aceptan tipos complejos datos. Esto sucede porque no se pueden pasar tipos de datos complejos a un método web mediante HTTP GET y POST.
Los servicios web le permiten llamar a sus métodos. asincrónicamente. Una llamada asincrónica devuelve el control inmediatamente, independientemente de cuánto tiempo le lleve al servicio web procesar la llamada. Las llamadas asincrónicas son útiles cuando procesar una llamada lleva mucho tiempo. La aplicación realiza la llamada, luego continúa ejecutándose sin esperar el resultado de la llamada y luego recibe los resultados de la llamada asincrónica. El resultado se obtiene llamando nuevamente al método web en un momento conveniente para la aplicación o suscribiéndose a una notificación sobre el final del procesamiento de la llamada por parte del servicio web (mecanismo de delegado).
Los servicios web se pueden crear utilizando herramientas como Microsoft Visual Studio 2005. Para crear servicios web que proporciona. tipo separado Proyecto de servicio web ASP .NET. Visual Studio genera un archivo asmx, un archivo con código de fondo para describir las clases de servicios web, un archivo de configuración de servicios web, etc. Cuando el proyecto se inicia para su ejecución, las clases de servicios se compilan y el archivo asmx se abre en la ventana del navegador. .
Descripción de servicios web mediante contratos.
Para que otros desarrolladores utilicen AdditionService, necesitan saber qué métodos proporciona, qué protocolos admite, firmas de métodos y la dirección del servicio web (URL). Toda esta y otra información se puede describir en WSDL (lenguaje de descripción de servicios web).
descubrimiento de servicios web
¿Cómo saben otros desarrolladores sobre la existencia de AdditionService?
En primer lugar, utilizar DISCO (abreviatura de la palabra descubrimiento), un mecanismo basado en archivos para buscar servicios web locales, es decir, un mecanismo para obtener una lista de servicios web disponibles a partir de archivos DISCO ubicados en servidores web. Además, los archivos DISCO contienen registros de la ubicación de los contratos WSDL de servicios disponibles. Un archivo DISCO es un archivo XML con registros.
También es posible utilizar archivos VSDISCO, que son similares a los archivos DISCO, pero su contenido es el resultado de una búsqueda dinámica de servicios web en los directorios especificados y en todos los subdirectorios. ASP .NET asigna la extensión de nombre de archivo .vsdisco a un controlador HTTP, que busca asmx y disco en el directorio dado y sus subdirectorios y devuelve un documento DISCO generado dinámicamente. Por razones de seguridad, la búsqueda dinámica está deshabilitada en algunas versiones de .NET Framework, pero puede habilitarla editando las entradas en el archivo Machine.config.
¿Cómo se buscan servicios web en la red global? Para buscar servicios web en la red global, Microsoft, IBM y Ariba desarrollaron conjuntamente UDDI (Universal Description Discovery and Integration), una especificación para crear bases de datos distribuidas que permite buscar servicios web. UDDI cuenta con el respaldo de cientos de empresas. Los sitios UDDI son en sí mismos servicios web. Cualquiera puede publicar su registro basado en UDDI. La mayoría de los desarrolladores nunca utilizan la API UDDI directamente. En cambio, las herramientas de desarrollo acceden a los registros UDDI. También generan clases contenedoras para servicios web descubiertos y seleccionados.
Resultados
Un servicio web XML es un componente de software que proporciona una funcionalidad que puede ser utilizada por la mayoría diferentes sistemas, compatible con estándares como XML y HTTP. Los clientes de servicios web pueden ser aplicaciones tanto locales como remotas. Los servicios web permiten crear estructuras que facilitan la integración de diferentes sistemas basados en estándares simples y generalmente aceptados.
Hemos revisado conceptos generales uso del mecanismo « Web-servicios". Refresquemos algunos conocimientos.
Los servicios web se utilizan para intercambiar datos entre un servidor y un cliente; El formato XML se utiliza para "empaquetar" datos con el fin de lograr un entendimiento mutuo entre ambos participantes en la comunicación.
CAPÍTULOI
EJEMPLO DE IMPLEMENTACIÓNWEB- SERVICIO EN EL SISTEMA 1C:ENTERPRISE
TAREA: Es necesario crear un servicio web al que los clientes puedan acceder para obtener toda la información necesaria sobre sus aplicaciones.
La tarea es una demostración y sirve sólo como ejemplo para comprender y enseñar el mecanismo.web-servicios.
SOLUCIÓN:
Paso 1. Creemos una nueva base de información sin configuración para desarrollar una nueva configuración.
Paso 2. Agreguemos varios objetos nuevos a la configuración.
Directorio "Clientes";
Documento "Solicitud";
Enumeración "Estados de Solicitud".
Paso 3. Creemos un nuevo paquete XDTO.
¿Por qué y con qué propósito creamos un paquete XDTO? Puede encontrar más información sobre el uso del mecanismo XDTO en el “Capítulo 16. Guía del desarrollador” y .
Observemos brevemente que el mecanismo XDTO es una forma universal de presentar datos para interactuar con diversas fuentes de datos externas y sistemas de software.
En nuestro caso, se crea un paquete XDTO para describir el valor de retorno del servicio web.
Expandamos la rama “General” → “Paquetes XDTO” → Agregar…
Especifiquemos el nombre del paquete XDTO " DocumentosDatos"y su espacio de nombres http://localhost/request o http://192.168.1.76/request (para facilitar el proceso de comprensión y aprendizaje, indicamos la dirección IP local del ordenador donde está instalado el servidor web (servidores web soportados: IIS o apache)). Cada servicio web puede identificarse de forma única por su nombre y el URI del espacio de nombres al que pertenece.
Nuestro paquete contiene dos tipos de objetos XDTO:
1) Cliente- transferir datos desde el elemento del directorio “Clientes”.
- Nombre ;
2) Documento- transferir datos del documento "Solicitud"
Este tipo de objeto XDTO contendrá las siguientes propiedades:
- Cliente- Tipo de cliente del espacio de nombres http://192.168.1.76/request; representa una referencia al objeto XDTO que definimos anteriormente;
- Estado- tipo de cadena del espacio de nombres http://www.w3.org/2001/XMLSchema;
- numerar- tipo de cadena del espacio de nombres http://www.w3.org/2001/XMLSchema.
Etapa 4. Agreguemos un nuevo servicio web a la configuración.
Expandamos la rama “General” → “Servicios web” → Agregar…
Para el servicio web, especificamos los siguientes valores de propiedad:
Nombre - DocumentosDatos
URI del espacio de nombres - http://192.168.1.76/solicitud
Paquetes XDTO - DocumentosDatosohttp://192.168.1.76/solicitud
Nombre del archivo de publicación - solicitud.1cws
Paso 5. Para el servicio Web creado definiremos la operación “ Obtener datos»
Valores de propiedad de operación:
Tipo de devolución - Documento (http://192.168.1.76/request)
Posiblemente valor vacío - Verdadero
Nombre del procedimiento - Obtener datos.
Paso 6. en la operacion Obtener datos definamos el parámetro Cliente con con los siguientes valores propiedades:
Tipo de valor - tipo cadena del espacio de nombres http://www.w3.org/2001/XMLSchema;
Dirección de transmisión - aporte.
Paso 7 Abramos el módulo del servicio web creado y coloquemos en él la función Get(), que se ejecutará cuando se llame a este servicio web.
Función GetData(Cliente) // Obtener los tipos de objetos XDTO ClientType = FactoryXDTO.Type("http://192.168.1.76/request", "Cliente"); RequestType = FactoryXDTO.Type("http://192.168.1.76/request", "Documento"); // Obtener el cliente ClientLink = Directories.Clients.FindByName(Customer); Si no es ValueFilled (ClientRef), devuelve Indefinido; terminara si; Solicitud = Nueva Solicitud; Request.Text = "SELECCIONAR TOP 1 | Aplicación.Enlace, | REPRESENTACIÓN(Aplicación.Estado) AS Estado, | Aplicación.Número |DESDE | Documento.Request AS Aplicación |DONDE | Aplicación.Cliente = &Cliente"; Request.SetParameter("Cliente", ClientLink); SolicitudResultado = Solicitud.Execute(); Si QueryResult.Empty() Entonces devuelve Indefinido; terminara si; Selección = QueryResult.Select(); Selección.Siguiente(); Documento = Selección.Enlace.GetObject(); // Crea un objeto XDTO de un pedido Order = FactoryXDTO.Create(OrderType); Número.de.aplicación = Número.de.muestra; Cliente = FactoryXDTO.Create(ClientType); Cliente.Nombre = ClientLink.Nombre; Aplicación.Cliente = Cliente; Aplicación.Estado = Selección.Estado; // Devuelve la solicitud Devuelve la solicitud; Función final
Paso 8 Publiquemos el servicio web creado en el servidor web.
Elemento de menú Configurador: “Administración” → “Publicación en un servidor web”.
En la pestaña "Servicios web", configure la casilla de verificación "Publicar servicios web" y también marque la casilla junto a nuestro nuevo servicio web.
CAPÍTULOII
EJEMPLO DE LLAMAMIENTO AWEB-AL SERVICIO DEL SISTEMA 1C:ENTERPRISE DESDE UNA APLICACIÓN DE TERCEROS
El objetivo principal del mecanismo de servicios web en el sistema 1C:Enterprise es transferir los datos necesarios a aplicaciones de terceros.
Consideremos un ejemplo de desarrollo de una aplicación en Delphi llamando a nuestro servicio web de la primera sección de este artículo.
Paso 1. Vamos a crear nuevo proyecto y colocar varios controles en el formulario
Campo de texto: se utiliza para mostrar información recibida del servicio web;
Dos botones: borrar el campo de texto y acceder al servicio web;
Un campo de entrada es un parámetro pasado al servicio web.
Paso 2. Importar un archivo WSDL
Como resultado, obtenemos un nuevo módulo. pedido(definimos este nombre directamente en 1C). Este módulo contiene toda la información necesaria sobre el servicio web.
Paso 3. Escribamos un controlador de llamadas de servicio web.
La variable DocumentDataPortType ya está definida en el módulo. pedido
Etapa 4. Inicie la aplicación y ejecute la prueba.
CAPÍTULOIII
EJEMPLO DE LLAMAMIENTO AWEB-SERVICIO EN EL SISTEMA 1C:EMPRESA
Paso 1. Creemos un nuevo procesamiento externo con el nombre "WEB_Service"
Paso 2. Definamos un nuevo formulario para procesar.
Paso 3. Te indicaremos varios detalles en el formulario.
Cliente: escriba "Cadena"
ClientReturn: escriba "Cadena"
NumberReturn - escriba "Cadena"
StatusReturn: escriba "Cadena".
Mostraremos los detalles en el formulario.
Etapa 4. Agreguemos un comando de formulario " para obtener datos»
Especifiquemos el controlador de comandos.
&Procedimiento OnClient GetData(Comando) GetDataOnServer(Cliente); Fin del procedimiento Procedimiento GetDataOnServer(Client) // Cree un proxy WS basado en el enlace y realice la operación Get() Definición = New WSDefinitions("http://192.168.1.76/WEB_Service/ws/request.1cws?wsdl") ; Proxy = Nuevo WSProxy(Definición, "http://192.168.1.76/request", "DocumentsData", "DocumentsDataSoap"); Datos de la aplicación = Proxy.GetData(Cliente); Si Datos de la aplicación = Indefinido Entonces ClientReturn = "Indefinido"; StatusReturn = "Indefinido"; Número de retorno = "Indefinido"; Devolver; terminara si; CustomerReturn = Datos de la aplicación.Cliente.Nombre; StatusReturn = Datos de la aplicación.Estado; Número de retorno = Datos de la aplicación.Número; Fin del Procedimiento
El sistema 1C:Enterprise puede utilizar servicios web proporcionados por otros proveedores de dos formas:
Mediante el uso estático enlaces creados en el árbol de configuración;
"más": alta velocidad;
"menos": volver a importar la descripción WSDL utilizando el configurador y guardar la configuración modificada.
Mediante el uso dinámica enlaces creados por herramientas de lenguaje integradas
(en consecuencia, los "desventajas" de los estáticos frente a los dinámicos son "ventajas")
CAPÍTULOIV
DEPURACIÓN DE SERVICIOS WEB EN EL SISTEMA 1C:ENTERPRISE
Para un servicio web local necesita:
Paso 1. Coloque el archivo en el cliente donde se ejecuta el sistema 1C. webservicecfg.xml con el siguiente contenido
Paso 2. Archivar por defecto. vrd publicar configuración agregar línea
Paso 3. En el configurador, seleccione el elemento del menú.
“Depurar” → “Conexión” → “Conexión automática” → “Servicios web en el servidor”
Etapa 4. Haga clic en el botón "Aceptar"
Para la opción del servidor, también necesita ejecutar el servidor 1c en modo de depuración con la clave /depurar
La idea de los servicios web fue desarrollada por gigantes de la industria informática como Sun, Oracle, HP, Microsoft e IBM. Esta idea no es nada nuevo, pero es un gran paso adelante hacia un acceso más fácil a los programas a través de la web. Basados en formatos de comunicación estándar, los servicios web podrían cambiar completamente nuestra forma de pensar sobre cómo deberíamos crear sitios web.
¿Qué es un servicio web?
Gracias a los servicios web, las funciones de cualquier programa pueden estar disponibles a través de Internet. Por lo tanto, programas como PHP, ASP, scripts JSP, JavaBeans, objetos COM y todas nuestras otras herramientas de programación favoritas ahora pueden acceder a algún programa que se ejecuta en otro servidor (es decir, un servicio web) y utilizar la respuesta recibida de ella en su sitio web, o solicitud.
Digamos que si necesito realizar alguna tarea de programación y estoy demasiado ocupado (o loco para reinventar la rueda nuevamente), puedo usar los servicios de un servicio web al que mi sitio accederá a través de Internet. Al pasar una solicitud con parámetros al servicio web, espero recibir una respuesta que contenga el resultado de ejecutar mi solicitud.
Cualquiera que haya trabajado recientemente con hotmail, ya se ha encontrado parcialmente con servicios web: el sistema de autenticación de usuarios Passport es uno de los servicios incluidos en la iniciativa Microsoft .NET. Actualmente está disponible de forma gratuita, por lo que los creadores de sitios web pueden implementar fácilmente la autenticación de usuario en su sitio.
Lo esencial
Los principios detrás de los servicios web son sorprendentemente simples. Y no añaden nada nuevo al mundo de la informática distribuida e Internet:
- el responsable del servicio web determina el formato de las solicitudes a su servicio web y sus respuestas
- cualquier computadora en la red realiza una solicitud a un servicio web
- Un servicio web procesa una solicitud, realiza alguna acción y luego envía una respuesta.
Esta acción podría ser, por ejemplo, mostrar una cotización de bolsa, mostrar el precio de un producto en particular, guardar una entrada en un calendario de citas, traducir texto de un idioma a otro o verificar un número de tarjeta de crédito.
Estándares en el centro
La razón por la que de repente todos nos interesamos por los servicios web es que se basan en estándares, protocolos abiertos para el intercambio y la transferencia de datos.
Antes de esto, muchas empresas desarrollaron sus propios estándares y formatos propietarios. Y ahora, para trabajar, solo necesitamos conocer XML (lenguaje de marcado extensible), que se transmite a través del antiguo y familiar protocolo HTTP. Esto significa que la información sobre cómo funcionan los servicios web está disponible para todos, y los desarrolladores web que estén familiarizados con estas tecnologías de profesión pueden empezar a jugar con los servicios web hoy mismo.
La diferencia entre los servicios web y otras tecnologías que los desarrolladores han encontrado (por ejemplo, DCOM, canalizaciones con nombre, RMI) es que los servicios web se basan en estándares abiertos, son fáciles de aprender y estos estándares cuentan con un amplio respaldo en todo el mundo. y plataformas Windows.
El Protocolo simple de acceso a objetos (SOAP) es un protocolo estándar desarrollado por el W3C. Define el formato de las solicitudes a los servicios web.
Los mensajes entre un servicio web y su usuario se empaquetan en sobres SOAP. Los mensajes contienen una solicitud para realizar alguna acción o una respuesta, el resultado de realizar esta acción. El sobre y su contenido están codificados en XML y son bastante fáciles de entender. Así es como se ve una solicitud SOAP simple cuando se envía vía HTPP a un servicio web:
xmlns:m="http://www.somesite.com/Postcode">
Los elementos clave de un sobre SOAP son bastante fáciles de descubrir: estos son dos parámetros (
Y la respuesta se verá así:
xmlns:m="http://www.somesite.com/Postcode">
Este mensaje es aún más fácil de descifrar. Elemento
Ahora sobre UDDI
Aunque el protocolo SOAP es sencillo, los servicios web serían de poca utilidad si no tuviéramos forma de encontrarlos. Afortunadamente, IBM, Microsoft y Ariba dieron un paso adelante y crearon el proyecto Universal Descripción, Descubrimiento e Integración (UDDI), que esperan se convierta en un catálogo común de todos los servicios web en la Web.
El sistema UDDI permite a las empresas exponer su servicio web al público. Este directorio actúa como una guía telefónica para todos los servicios web. El registro en el directorio UDDI es gratuito, y los fundadores del proyecto esperan que este directorio contenga descripciones de todos, todos, todos los servicios en la Web, de modo que para encontrar el servicio web deseado, solo necesitará recurrir a un UDDI. directorio.
¿Cómo funciona todo?
Entonces, ¿cómo encuentro el servicio web adecuado?
Imaginemos que soy desarrollador de sitios web y mi cliente me pide que agregue una nueva característica al sitio: necesito agregar una verificación de código postal en el formulario de registro.
Para realizar esta verificación, necesitaría crear una base de datos de todos los códigos postales en los 30 países donde nuestra empresa opera y luego verificar que el código postal corresponda a la ciudad especificada en el registro al registrarme. Pero no tengo estos datos y creo que para recopilarlos habrá que gastar una cantidad importante de dinero.
En lugar de desembolsar dinero para comprar una base de datos, escribir el código yo mismo, asegurar la integridad y corrección de todos los datos y depurar los scripts, simplemente voy al directorio UDDI y veo si hay un servicio web que pueda hacer el trabajo. a mí . Al llegar a www.uddi.org, realizo una búsqueda y encuentro un excelente servicio de XYZ Corp.
Reviso cuidadosamente la definición del formato del servicio web (la definición está escrita en WSDL (lenguaje de descripción de servicios web), asegurándome de que el servicio haga exactamente lo que necesito. Luego verifico con mis colegas la reputación de XYZ Corp. y averiguo que es sólido y luego me comunico con XYZ Corp. para consultar el precio. Si el precio para acceder al servicio está dentro de mi presupuesto, escribo una página JSP simple para mi sitio que llama al servicio web de XYZ Corp. y he aquí, La verificación instantánea aparece en el código postal del sitio.
Vale la pena tu tiempo
Incluso si no tiene nada que ver con la programación o las tecnologías de desarrollo de sitios web, vale la pena aprender más sobre los servicios web. Imagine una imagen de cómo está discutiendo un nuevo sitio web con un cliente, discutiendo todas las funciones del nuevo proyecto. Todo va muy bien: el presupuesto cumple con las expectativas del cliente, le gustó el boceto del plano del sitio y le gustaron los ejemplos de la interfaz. Todo parece estar funcionando.
Y de repente recuerdan alguna función muy compleja. Con solo mencionarlo, la cara de su desarrollador web se pone verde y comienza a ahogarse y toser. Este es el desarrollador que le da una señal de que desarrollar esta función requerirá mucho dinero y tiempo o simplemente no es factible con ese presupuesto.
¡Deja tu miedo! Estoy dispuesto a garantizar que ya existe un servicio web en Internet que está listo para brindarle la función requerida, y el costo de utilizar este servicio web será mucho menor que el costo de desarrollar su análogo de forma independiente. De esta manera, evita que su desarrollador sufra dolores de cabeza innecesarios y que su cliente pierda dinero con solo pasar un par de minutos navegando por el catálogo UDDI.
Desarrollo de servicios
Por supuesto, los desarrolladores no tienen que contentarse sólo con servicios web creados por otros. Con uno de los siguientes kits de herramientas, puede crear su propio servicio web y proporcionar sus servicios a otros usuarios de Internet.
La elección de herramientas para desarrollar servicios web es amplia. Incluye herramientas de empresas como Sun (Open Net), Microsoft (.NET), (servicios electrónicos) e IBM ( Servicios web). También existen marcos de código abierto. Por ejemplo, el Proyecto Mono pretende reemplazar el conjunto de herramientas .NET de Microsoft proporcionando compiladores, tiempo de ejecución y bibliotecas para ejecutar los mismos servicios web en todas las plataformas, incluido Unix.
A pesar de la variedad de servidores y herramientas de desarrollo de servicios web, todos admiten el mismo protocolo SOAP, lenguaje XML y sistema UDDI.
Desventajas
Antes de abandonar por completo mi carrera como programador y dedicarme a utilizar servicios web, tengo que hacerme la pregunta: "Es un panorama demasiado halagüeño. ¿Qué tiene de malo?". Desafortunadamente, el gran potencial de los servicios web tiene un precio:
- El uso de XML como formato de transferencia de datos significa que sus mensajes tendrán un tamaño muy grande: las etiquetas XML en sí mismas ocupan mucho espacio, y esto nos impone una cierta carga a la hora de crear, transmitir e interpretar mensajes.
- Dado que utilizamos computadoras remotas para realizar ciertas funciones, dependemos completamente de Internet, lo que crea demasiados vínculos poco confiables en la cadena entre nuestro servidor web y el servicio web.
- Hoy en día, pocas empresas crean servicios web y pocas empresas los utilizan. Depurar y mejorar el sistema de servicios web todavía lleva mucho tiempo.
- Los desarrolladores aún no han aceptado el sistema de concesión de licencias y cobro por el uso de servicios web. Debido a que todavía hay muy pocos servicios web, la mayoría de las empresas intentan dar una buena impresión a sus clientes potenciales reduciendo deliberadamente el coste de los servicios y ofreciendo condiciones de licencia favorables. Aún pasará algún tiempo antes de que quede claro el coste real de los servicios web.
Cuando los servicios web ocupen su lugar y estén disponibles para todos, se convertirán en una ayuda invaluable para los desarrolladores web. Nos darán acceso flexible a toda la potencia de todos los ordenadores de la Red. Es hora de que los creadores de sitios web se interesen por los servicios web y aprendan más sobre lo que pueden obtener de ellos.
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 encontrado referencias a servicios web en artículos técnicos, descripciones productos de software o incluso en diálogos con colegas. 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 suficiente información útil, y será útil para cualquiera que quiera entender 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 ha Estructura compleja y puede tener lugar de diferentes maneras, dependiendo de la cantidad de personas que se comunican, el idioma de comunicación utilizado para la comunicación y 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
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 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.
- El mensaje XML se almacena en un archivo de texto plano y por lo tanto toma más espacio que su equivalente en otro formato (como un formato despojado, binario o "casero").
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í:
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. Descripciones de las partes del archivo WSDL y sus colaboración no se incluirá en este artículo.
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 de alguna manera se ponen de acuerdo (en persona, por teléfono, a través de 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. Comer varios esquemas, que puedes utilizar dependiendo de 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 de 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. Una vez que tengamos remedio 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.
