Servicios web - Guía rápida

Diferentes libros y diferentes organizaciones proporcionan diferentes definiciones a los servicios web. Algunos de ellos se enumeran aquí.

Un servicio web es cualquier software que esté disponible en Internet y utilice un sistema de mensajería XML estandarizado. XML se utiliza para codificar todas las comunicaciones a un servicio web. Por ejemplo, un cliente invoca un servicio web enviando un mensaje XML y luego espera la respuesta XML correspondiente. Como toda la comunicación se realiza en XML, los servicios web no están vinculados a ningún sistema operativo o lenguaje de programación: Java puede hablar con Perl; Las aplicaciones de Windows pueden comunicarse con las aplicaciones de Unix.
Los servicios web son aplicaciones autónomas, modulares, distribuidas y dinámicas que se pueden describir, publicar, ubicar o invocar a través de la red para crear productos, procesos y cadenas de suministro. Estas aplicaciones pueden ser locales, distribuidas o basadas en la web. Los servicios web se basan en estándares abiertos como TCP / IP, HTTP, Java, HTML y XML.
Los servicios web son sistemas de intercambio de información basados en XML que utilizan Internet para la interacción directa de aplicación a aplicación. Estos sistemas pueden incluir programas, objetos, mensajes o documentos.
Un servicio web es una colección de protocolos y estándares abiertos que se utilizan para intercambiar datos entre aplicaciones o sistemas. Las aplicaciones de software escritas en varios lenguajes de programación y que se ejecutan en varias plataformas pueden utilizar servicios web para intercambiar datos a través de redes informáticas como Internet de manera similar a la comunicación entre procesos en una sola computadora. Esta interoperabilidad (por ejemplo, entre Java y Python, o aplicaciones de Windows y Linux) se debe al uso de estándares abiertos.

En resumen, un servicio web completo es, por tanto, cualquier servicio que:

Está disponible a través de Internet o redes privadas (intranet).
Utiliza un sistema de mensajería XML estandarizado
No está vinculado a ningún sistema operativo o lenguaje de programación.
Se autodescribe mediante una gramática XML común.
Es detectable mediante un sencillo mecanismo de búsqueda.

Componentes de los servicios web

La plataforma de servicios web básica es XML + HTTP. Todos los servicios web estándar funcionan con los siguientes componentes:

SOAP (Protocolo simple de acceso a objetos)
UDDI (Descripción, descubrimiento e integración universal)
WSDL (lenguaje de descripción de servicios web)

Todos estos componentes se han analizado en el capítulo Arquitectura de servicios web .

¿Cómo funciona un servicio web?

Un servicio web permite la comunicación entre varias aplicaciones mediante el uso de estándares abiertos como HTML, XML, WSDL y SOAP. Un servicio web necesita la ayuda de:

XML para etiquetar los datos
SOAP para transferir un mensaje
WSDL para describir la disponibilidad del servicio.

Puede crear un servicio web basado en Java en Solaris al que se pueda acceder desde su programa Visual Basic que se ejecuta en Windows.

También puede utilizar C # para crear nuevos servicios web en Windows que se pueden invocar desde su aplicación web que se basa en JavaServer Pages (JSP) y se ejecuta en Linux.

Ejemplo

Considere un sistema simple de gestión de cuentas y procesamiento de pedidos. El personal de contabilidad usa una aplicación cliente construida con Visual Basic o JSP para crear nuevas cuentas e ingresar nuevos pedidos de clientes.

La lógica de procesamiento de este sistema está escrita en Java y reside en una máquina Solaris, que también interactúa con una base de datos para almacenar información.

Los pasos para realizar esta operación son los siguientes:

El programa cliente agrupa la información de registro de la cuenta en un mensaje SOAP.
Este mensaje SOAP se envía al servicio web como el cuerpo de una solicitud HTTP POST.
El servicio web descomprime la solicitud SOAP y la convierte en un comando que la aplicación puede comprender.
La aplicación procesa la información según sea necesario y responde con un nuevo número de cuenta único para ese cliente.
A continuación, el servicio web empaqueta la respuesta en otro mensaje SOAP, que envía de vuelta al programa cliente en respuesta a su solicitud HTTP.
El programa cliente descomprime el mensaje SOAP para obtener los resultados del proceso de registro de la cuenta.

Estos son los beneficios de utilizar los servicios web:

Exposición de la función existente en la red

Un servicio web es una unidad de código administrado que se puede invocar de forma remota mediante HTTP. Es decir, se puede activar mediante solicitudes HTTP. Los servicios web le permiten exponer la funcionalidad de su código existente a través de la red. Una vez que se expone en la red, otras aplicaciones pueden utilizar la funcionalidad de su programa.

Interoperabilidad

Los servicios web permiten que varias aplicaciones se comuniquen entre sí y compartan datos y servicios entre ellas. Otras aplicaciones también pueden utilizar los servicios web. Por ejemplo, una aplicación VB o .NET puede comunicarse con los servicios web Java y viceversa. Los servicios web se utilizan para hacer que la plataforma de aplicaciones y la tecnología sean independientes.

Protocolo estandarizado

Los servicios web utilizan un protocolo estándar industrial estandarizado para la comunicación. Las cuatro capas (transporte de servicio, mensajería XML, descripción de servicio y capa de descubrimiento de servicio) utilizan protocolos bien definidos en la pila de protocolos de servicios web. Esta estandarización de la pila de protocolos brinda a la empresa muchas ventajas, como una amplia gama de opciones, reducción del costo debido a la competencia y aumento de la calidad.

Comunicación de bajo costo

Los servicios web utilizan SOAP sobre el protocolo HTTP, por lo que puede utilizar su Internet de bajo costo existente para implementar servicios web. Esta solución es mucho menos costosa en comparación con soluciones propietarias como EDI / B2B. Además de SOAP sobre HTTP, los servicios web también se pueden implementar en otros mecanismos de transporte confiables como FTP.

Los servicios web tienen las siguientes características especiales de comportamiento:

Basado en XML

Los servicios web utilizan XML en las capas de representación y transporte de datos. El uso de XML elimina cualquier enlace de red, sistema operativo o plataforma. Las aplicaciones basadas en servicios web son altamente interoperables en su nivel central.

Débilmente acoplado

Un consumidor de un servicio web no está vinculado directamente a ese servicio web. La interfaz del servicio web puede cambiar con el tiempo sin comprometer la capacidad del cliente para interactuar con el servicio. Un sistema estrechamente acoplado implica que la lógica del cliente y del servidor están estrechamente vinculadas entre sí, lo que implica que si una interfaz cambia, la otra debe actualizarse. La adopción de una arquitectura poco acoplada tiende a hacer que los sistemas de software sean más manejables y permite una integración más simple entre diferentes sistemas.

De grano grueso

Las tecnologías orientadas a objetos como Java exponen sus servicios a través de métodos individuales. Un método individual es una operación demasiado fina para proporcionar alguna capacidad útil a nivel corporativo. La construcción de un programa Java desde cero requiere la creación de varios métodos detallados que luego se componen en un servicio detallado que es consumido por un cliente u otro servicio.

Las empresas y las interfaces que exponen deben ser generales. La tecnología de servicios web proporciona una forma natural de definir servicios generales que acceden a la cantidad adecuada de lógica empresarial.

Capacidad para ser sincrónico o asincrónico

La sincronicidad se refiere a la vinculación del cliente a la ejecución del servicio. En las invocaciones sincrónicas, el cliente bloquea y espera que el servicio complete su operación antes de continuar. Las operaciones asincrónicas permiten que un cliente invoque un servicio y luego ejecute otras funciones.

Los clientes asíncronos recuperan su resultado en un momento posterior, mientras que los clientes síncronos reciben su resultado cuando el servicio se ha completado. La capacidad asincrónica es un factor clave para habilitar sistemas con acoplamiento flexible.

Admite llamadas a procedimiento remoto (RPC)

Los servicios web permiten a los clientes invocar procedimientos, funciones y métodos en objetos remotos utilizando un protocolo basado en XML. Los procedimientos remotos exponen parámetros de entrada y salida que un servicio web debe admitir.

El desarrollo de componentes a través de Enterprise JavaBeans (EJB) y .NET Components se ha convertido cada vez más en una parte de las arquitecturas y las implementaciones empresariales en los últimos años. Ambas tecnologías se distribuyen y son accesibles a través de una variedad de mecanismos RPC.

Un servicio web es compatible con RPC proporcionando servicios propios, equivalentes a los de un componente tradicional, o traduciendo las invocaciones entrantes en una invocación de un componente EJB o .NET.

Admite intercambio de documentos

Una de las ventajas clave de XML es su forma genérica de representar no solo datos, sino también documentos complejos. Estos documentos pueden ser tan simples como representar una dirección actual, o pueden ser tan complejos como representar un libro completo o una Solicitud de Cotización (RFQ). Los servicios web admiten el intercambio transparente de documentos para facilitar la integración empresarial.

Hay dos formas de ver la arquitectura del servicio web:

El primero es examinar los roles individuales de cada actor de servicios web.
El segundo es examinar la pila de protocolos de servicios web emergentes.

Roles de servicios web

Hay tres roles principales dentro de la arquitectura del servicio web:

Proveedor de servicio

Este es el proveedor del servicio web. El proveedor de servicios implementa el servicio y lo pone a disposición en Internet.

Solicitante de servicio

Este es cualquier consumidor del servicio web. El solicitante utiliza un servicio web existente abriendo una conexión de red y enviando una solicitud XML.

Registro de servicios

Este es un directorio de servicios lógicamente centralizado. El registro proporciona un lugar central donde los desarrolladores pueden publicar nuevos servicios o encontrar los existentes. Por lo tanto, sirve como una cámara de compensación centralizada para las empresas y sus servicios.

Pila de protocolo de servicio web

Una segunda opción para ver la arquitectura de servicios web es examinar la pila de protocolos de servicios web emergentes. La pila todavía está evolucionando, pero actualmente tiene cuatro capas principales.

Transporte de servicio

Esta capa es responsable de transportar mensajes entre aplicaciones. Actualmente, esta capa incluye el Protocolo de transporte de hipertexto (HTTP), el Protocolo simple de transferencia de correo (SMTP), el Protocolo de transferencia de archivos (FTP) y protocolos más nuevos como el Protocolo de intercambio extensible de bloques (BEEP).

Mensajería XML

Esta capa es responsable de codificar los mensajes en un formato XML común para que los mensajes se puedan entender en ambos extremos. Actualmente, esta capa incluye XML-RPC y SOAP.

Descripción del servicio

Esta capa es responsable de describir la interfaz pública a un servicio web específico. Actualmente, la descripción del servicio se maneja a través del Lenguaje de descripción de servicios web (WSDL).

Descubrimiento de servicios

Esta capa es responsable de centralizar los servicios en un registro común y proporcionar una funcionalidad de publicación / búsqueda sencilla. Actualmente, el descubrimiento de servicios se maneja a través de la descripción, el descubrimiento y la integración universales (UDDI).

A medida que los servicios web evolucionan, se pueden agregar capas adicionales y se pueden agregar tecnologías adicionales a cada capa.

El siguiente capítulo explica los componentes de los servicios web.

Pocas palabras sobre el transporte de servicios

La parte inferior de la pila de protocolos de servicios web es el transporte de servicios. Esta capa es responsable de transportar mensajes XML entre dos computadoras.

Protocolo de transferencia de hipertexto (HTTP)

Actualmente, HTTP es la opción más popular para el transporte de servicios. HTTP es simple, estable y ampliamente implementado. Además, la mayoría de los cortafuegos permiten el tráfico HTTP. Esto permite que los mensajes XMLRPC o SOAP se hagan pasar por mensajes HTTP. Esto es bueno si desea integrar aplicaciones remotas, pero plantea una serie de problemas de seguridad. Se plantean varios problemas de seguridad.

Bloquea el protocolo de intercambio extensible (BEEP)

Esta es una alternativa prometedora a HTTP. BEEP es un nuevo marco de trabajo del Grupo de trabajo de ingeniería de Internet (IETF) para la creación de nuevos protocolos. BEEP se superpone directamente en TCP e incluye una serie de funciones integradas, incluido un protocolo de reconocimiento inicial, autenticación, seguridad y manejo de errores. Con BEEP, se pueden crear nuevos protocolos para una variedad de aplicaciones, incluida la mensajería instantánea, la transferencia de archivos, la sindicación de contenido y la administración de redes.

SOAP no está vinculado a ningún protocolo de transporte específico. De hecho, puede utilizar SOAP a través de HTTP, SMTP o FTP. Por tanto, una idea prometedora es utilizar SOAP sobre BEEP.

En los últimos años, han surgido tres tecnologías principales como estándares mundiales que constituyen el núcleo de la tecnología de servicios web actual. Estas tecnologías se analizan a continuación.

XML-RPC

Este es el protocolo basado en XML más simple para intercambiar información entre computadoras.

XML-RPC es un protocolo simple que usa mensajes XML para realizar RPC.
Las solicitudes se codifican en XML y se envían mediante HTTP POST.
Las respuestas XML están integradas en el cuerpo de la respuesta HTTP.
XML-RPC es independiente de la plataforma.
XML-RPC permite la comunicación de diversas aplicaciones.
Un cliente Java puede hablar XML-RPC con un servidor Perl.
XML-RPC es la forma más sencilla de comenzar con los servicios web.

Para obtener más información sobre XML-RPC, visite nuestro Tutorial de XML-RPC .

JABÓN

SOAP es un protocolo basado en XML para intercambiar información entre computadoras.

SOAP es un protocolo de comunicación.
SOAP es para la comunicación entre aplicaciones.
SOAP es un formato para enviar mensajes.
SOAP está diseñado para comunicarse a través de Internet.
SOAP es una plataforma independiente.
SOAP es independiente del idioma.
SOAP es simple y extensible.
SOAP le permite sortear los firewalls.
SOAP se desarrollará como un estándar W3C.

Para obtener más información sobre SOAP, visite nuestro tutorial SOAP .

WSDL

WSDL es un lenguaje basado en XML para describir servicios web y cómo acceder a ellos.

WSDL son las siglas de Web Services Description Language.
WSDL fue desarrollado conjuntamente por Microsoft e IBM.
WSDL es un protocolo basado en XML para el intercambio de información en entornos descentralizados y distribuidos.
WSDL es el formato estándar para describir un servicio web.
La definición de WSDL describe cómo acceder a un servicio web y qué operaciones realizará.
WSDL es un lenguaje para describir cómo interactuar con servicios basados en XML.
WSDL es una parte integral de UDDI, un registro de empresas mundial basado en XML.
WSDL es el lenguaje que usa UDDI.
WSDL se pronuncia como 'wiz-dull' y se deletrea como 'WSD-L'.

To learn more about WSDL, visit our WSDL Tutorial.

UDDI

UDDI is an XML-based standard for describing, publishing, and finding web services.

UDDI stands for Universal Description, Discovery, and Integration.
UDDI is a specification for a distributed registry of web services.
UDDI is platform independent, open framework.
UDDI can communicate via SOAP, CORBA, and Java RMI Protocol.
UDDI uses WSDL to describe interfaces to web services.
UDDI is seen with SOAP and WSDL as one of the three foundation standards of web services.
UDDI is an open industry initiative enabling businesses to discover each other and define how they interact over the Internet.

To learn more about UDDI, visit our UDDI Tutorial.

Based on the web service architecture, we create the following two components as a part of web services implementation −

Service Provider or Publisher

This is the provider of the web service. The service provider implements the service and makes it available on the Internet or intranet.

We will write and publish a simple web service using .NET SDK.

Service Requestor or Consumer

This is any consumer of the web service. The requestor utilizes an existing web service by opening a network connection and sending an XML request.

We will also write two web service requestors: one web-based consumer (ASP.NET application) and another Windows application-based consumer.

Given below is our first web service example which works as a service provider and exposes two methods (add and SayHello) as the web services to be used by applications. This is a standard template for a web service. .NET web services use the .asmx extension. Note that a method exposed as a web service has the WebMethod attribute. Save this file as FirstService.asmx in the IIS virtual directory (as explained in configuring IIS; for example, c:\MyWebSerces).

FirstService.asmx
<%@ WebService language = "C#" class = "FirstService" %>

using System;
using System.Web.Services;
using System.Xml.Serialization;

[WebService(Namespace = "http://localhost/MyWebServices/")]
public class FirstService : WebService{
   [WebMethod]
   public int Add(int a, int b) {
      return a + b;
   }

   [WebMethod]
   public String SayHello() {
      return "Hello World";
   }
}

To test a web service, it must be published. A web service can be published either on an intranet or the Internet. We will publish this web service on IIS running on a local machine. Let us start with configuring the IIS.

Open Start → Settings → Control Panel → Administrative tools → Internet Services Manager.
Expand and right-click on the default web site; select New &#rarr; Virtual Directory. The Virtual Directory Creation Wizard opens. Click Next.
The "Virtual Directory Alias" screen opens. Type the virtual directory name. For example, MyWebServices. Click Next.
The "Web Site Content Directory" screen opens.
Enter the directory path name for the virtual directory. For example, c:\MyWebServices. Click Next.
The "Access Permission" screen opens. Change the settings as per your requirements. Let us keep the default settings for this exercise.
Click the Next button. It completes the IIS configuration.
Click Finish to complete the configuration.

To test whether the IIS has been configured properly, copy an HTML file (For example, x.html) in the virtual directory (C:\MyWebServices) created above. Now, open Internet Explorer and type http://localhost/MyWebServices/x.html. It should open the x.html file.

Note − If it does not work, try replacing the localhost with the IP address of your machine. If it still does not work, check whether IIS is running; you may need to reconfigure the IIS and the Virtual Directory.

To test this web service, copy FirstService.asmx in the IIS virtual directory created above (C:\MyWebServices). Open the web service in Internet Explorer (http://localhost/MyWebServices/FirstService.asmx). It should open your web service page. The page should have links to two methods exposed as web services by our application. Congratulations! You have written your first web service!

Testing the Web Service

As we have just seen, writing web services is easy in the .NET Framework. Writing web service consumers is also easy in the .NET framework; however, it is a bit more involved. As said earlier, we will write two types of service consumers, one web-based and another Windows application-based consumer. Let us write our first web service consumer.

Web-Based Service Consumer

Write a web-based consumer as given below. Call it WebApp.aspx. Note that it is an ASP.NET application. Save this in the virtual directory of the web service (c:\MyWebServices\WebApp.axpx).

This application has two text fields that are used to get numbers from the user to be added. It has one button, Execute, that when clicked gets the Add and SayHello web services.

WebApp.aspx
<%@ Page Language = "C#" %>
<script runat = "server">
   void runSrvice_Click(Object sender, EventArgs e) {
      FirstService mySvc = new FirstService();
      Label1.Text = mySvc.SayHello();
      Label2.Text = mySvc.Add(Int32.Parse(txtNum1.Text),  Int32.Parse(txtNum2.Text)).ToString();
   }
</script>

<html>
   <head> </head>
   
   <body>
      <form runat = "server">
         <p>
            <em>First Number to Add </em>:
            <asp:TextBox id = "txtNum1" runat = "server" Width = "43px">4<  /asp:TextBox>
         </p>
			
         <p>
            <em>Second Number To Add </em>:
            <asp:TextBox id = "txtNum2" runat = "server" Width = "44px">5</asp:TextBox>
         </p>
			
         <p>
            <strong><u>Web Service Result -</u></strong>
         </p>
			
         <p>
            <em>Hello world Service</em> :
            <asp:Label id = "Label1" runat = "server" Font-Underline = "True">Label< /asp:Label>
         </p>

         <p>
            <em>Add Service</em> :
            & <asp:Label id = "Label2" runat = "server" Font-Underline = "True">Label</asp:Label>
         </p>
			
         <p align = "left">
            <asp:Button id = "runSrvice" onclick = "runSrvice_Click" runat = "server" Text = "Execute"></asp:Button>
         </p>
      </form>
   </body>
</html>

After the consumer is created, we need to create a proxy for the web service to be consumed. This work is done automatically by Visual Studio .NET for us when referencing a web service that has been added. Here are the steps to be followed −

Create a proxy for the Web Service to be consumed. The proxy is created using the WSDL utility supplied with the .NET SDK. This utility extracts information from the Web Service and creates a proxy. The proxy is valid only for a particular Web Service. If you need to consume other Web Services, you need to create a proxy for this service as well. Visual Studio .NET creates a proxy automatically for you when the Web Service reference is added. Create a proxy for the Web Service using the WSDL utility supplied with the .NET SDK. It will create FirstSevice.cs file in the current directory. We need to compile it to create FirstService.dll (proxy) for the Web Service.

c:> WSDL http://localhost/MyWebServices/FirstService.asmx?WSDL
c:> csc /t:library FirstService.cs

Put the compiled proxy in the bin directory of the virtual directory of the Web Service (c:\MyWebServices\bin). Internet Information Services (IIS) looks for the proxy in this directory.
Create the service consumer, in the same way we already did. Note that an object of the Web Service proxy is instantiated in the consumer. This proxy takes care of interacting with the service.
Type the URL of the consumer in IE to test it (for example, http://localhost/MyWebServices/WebApp.aspx).

Windows Application-Based Web Service Consumer

Writing a Windows application-based web service consumer is the same as writing any other Windows application. You only need to create the proxy (which we have already done) and reference this proxy when compiling the application. Following is our Windows application that uses the web service. This application creates a web service object (of course, proxy) and calls the SayHello, and Add methods on it.

WinApp.cs

using System;
using System.IO;

namespace SvcConsumer {
   class SvcEater {
      public static void Main(String[] args) {
         FirstService mySvc = new FirstService();
         Console.WriteLine("Calling Hello World Service: " + mySvc.SayHello());
         Console.WriteLine("Calling Add(2, 3) Service: " + mySvc.Add(2, 3).ToString());
      }
   }
}

Compile it using c:\>csc /r:FirstService.dll WinApp.cs. It will create WinApp.exe. Run it to test the application and the web service.

Now, the question arises: How can you be sure that this application is actually calling the web service?

It is simple to test. Stop your web server so that the web service cannot be contacted. Now, run the WinApp application. It will fire a runtime exception. Now, start the web server again. It should work.

Security is critical to web services. However, neither XML-RPC nor SOAP specifications make any explicit security or authentication requirements.

There are three specific security issues with web services −

Confidentiality
Authentication
Network Security

Confidentiality

If a client sends an XML request to a server, can we ensure that the communication remains confidential?

Answer lies here −

XML-RPC and SOAP run primarily on top of HTTP.
HTTP has support for Secure Sockets Layer (SSL).
Communication can be encrypted via SSL.
SSL is a proven technology and widely deployed.

A single web service may consist of a chain of applications. For example, one large service might tie together the services of three other applications. In this case, SSL is not adequate; the messages need to be encrypted at each node along the service path, and each node represents a potential weak link in the chain. Currently, there is no agreed-upon solution to this issue, but one promising solution is the W3C XML Encryption Standard. This standard provides a framework for encrypting and decrypting entire XML documents or just portions of an XML document. You can check it at www.w3.org/Encryption

Authentication

If a client connects to a web service, how do we identify the user? Is the user authorized to use the service?

The following options can be considered but there is no clear consensus on a strong authentication scheme.

HTTP includes built-in support for Basic and Digest authentication, and services can therefore be protected in much the same manner as HTML documents are currently protected.
SOAP Digital Signature (SOAP-DSIG) leverages public key cryptography to digitally sign SOAP messages. It enables the client or server to validate the identity of the other party. Check it at www.w3.org/TR/SOAP-dsig.
The Organization for the Advancement of Structured Information Standards (OASIS) is working on the Security Assertion Markup Language (SAML).

Network Security

There is currently no easy answer to this problem, and it has been the subject of much debate. For now, if you are truly intent on filtering out SOAP or XML-RPC messages, one possibility is to filter out all HTTP POST requests that set their content type to text/xml.

Another alternative is to filter the SOAPAction HTTP header attribute. Firewall vendors are also currently developing tools explicitly designed to filter web service traffic.

This chapter gives you an idea of all the latest standards related to web services.

Transports

BEEP, the Blocks Extensible Exchange Protocol (formerly referred to as BXXP), is a framework for building application protocols. It has been standardized by IETF and it does for Internet protocols what XML has done for data.

Blocks Extensible Exchange Protocol (BEEP)

Messaging

These messaging standards and specifications are intended to give a framework for exchanging information in a decentralized, distributed environment.

Description and Discovery

Web services are meaningful only if potential users may find information sufficient to permit their execution. The focus of these specifications and standards is the definition of a set of services supporting the description and discovery of businesses, organizations, and other web services providers; the web services they make available; and the technical interfaces which may be used to access those services.

Security

Using these security specifications, applications can engage in secure communication designed to work with the general web services framework.

Management

Web services manageability is defined as a set of capabilities for discovering the existence, availability, health, performance, usage, as well as the control and configuration of a web service within the web services architecture. As web services become pervasive and critical to business operations, the task of managing and implementing them is imperative to the success of business operations.

Web Services Distributed Management

In this tutorial, you have learnt how to use web services. However, a web service also include components such as WSDL, UDDI, and SOAP that contribute to make it active. The next step is to learn WSDL, UDDI, and SOAP.

WSDL

WSDL is an XML-based language for describing web services and how to access them.

WSDL describes a web service, along with the message format and protocol details for the web service.

To learn more about WSDL, visit our WSDL Tutorial.

UDDI

UDDI is an XML-based standard for describing, publishing, and finding web services.

To learn more about UDDI, visit our UDDI Tutorial.

SOAP

SOAP is a simple XML-based protocol that allows applications to exchange information over HTTP.

To learn more about SOAP, visit our SOAP Tutorial.

↰ Previous page