Web Services 2.0

Introducción

Las aplicaciones web actuales ya no son suficientes. El modelo actual de negocio electrónico no facilita la integración de las aplicaciones de Internet con el resto de software de las empresas. Si las compañías quieren extraer el máximo beneficio de Internet, los sitios web deben evolucionar. Este es el contexto en el que surgen los web services.

Por eso es que en los últimos tiempos ha surgido con mucha fuerza el concepto de web services , incluso afirmándose que el mismo cambiaría la forma de programar las aplicaciones orientadas a Internet hacia una arquitectura orientada a servicios.
Podemos decir que un web service es una aplicación que puede ser descripta, publicada, localizada e invocada a través de una red, generalmente Internet. Combinan los mejores aspectos del desarrollo basado en componentes y la Web.
Al igual que los componentes, los web services son funcionalidades que se encuentran dentro de una caja negra, que pueden ser reutilizados sin preocuparse de cómo fueron implementados. A diferencia de la actual tecnología de componentes, no son accedidos por medio de protocolos específicos del modelo de objetos como ser RMI, DCOM o IIOP; sino que son accedidos utilizando protocolos web como ser HTTP y XML.
La interface de los web services está definida en términos de los mensajes que el mismo acepta y retorna, por lo cual los consumidores de los web services pueden ser implementados en cualquier plataforma y en cualquier lenguaje de programación, solo tiene que poder crear y consumir los mensajes definidos por la interface de los web services.

El Modelo Web Services

La arquitectura básica del modelo de web services describe a un consumidor, un proveedor (Implementador) y ocasionalmente un corredor (bróker UDDI). Relacionados con estos agentes están las operaciones de publicar, encontrar y enlazar.
La idea básica consiste en que un proveedor publica su servicios en un corredor, luego un consumidor se conecta el corredor para buscar los servicios deseados y una vez que lo hace se realiza un lazo entre el consumidor y el proveedor ó implementador.
Cada entidad puede jugar alguno o todos los roles.

1

Por todo lo anterior hay ciertos requerimientos a la hora de desarrollar o consumir un web services:

  • Una forma estándar de representar los datos.

    • XML es la opción obvia para este requerimiento.

  • Un formato común y extensible de mensajes

    • SOAP es el elegido en este caso; SOAP es un protocolo liviano para el intercambio de información. Más adelante en este documento lo veremos con más detalle.

  • Un lenguaje común y extensible para describir los servicios.

    • La opción en este caso es WSDL. Es un lenguaje basado en XML desarrollado en forma conjunta por IBM y Microsoft. Lo veremos con más detalle más adelante en este documento.

  • Una forma de descubrir los servicios en Internet.

    • UDDI se utiliza en este caso; el mismo especifica un mecanismo para publicar y localizar los servicios por parte de los proveedores y consumidores respectivamente. Se verá con más detalle más adelante en este documento.

Descripción del Servicio Web para Visualizar Acuses por Oca Delivery 2.0

La descripción del Servicio de Oca está disponible a través de los métodos del WebServices SigmaService y están publicados en la URL :

http://www1.oca.com.ar/SigmaWebService/OCASigmaService.asmx

El Método Público de este Web Service que utilizarían en principio es :

  1. GetURLAcuse

    2. Este método se utiliza para poder visualizar las imágenes de los Acuses Digitalizados de las Piezas tramitadas y entregadas por OCA. Donde se pueden visualizar tanto piezas como cartas de rendición.

    Tiene 5 parámetros: clienteLogueo, usuario, password, numeroPieza, Lado a Visualizar.

    Donde los 3 primeros parámetros son los mismos utilizados por el otro Web Services para la consulta de piezas.

    1. ClienteLogueo = Es la sigla del cliente en OCA
    2. Usuario = código de usuario del cliente (UserCLI por ej.)
    3. Password = contraseña del usuario del cliente (XXXX por ej.)
    4. NumeroPieza = Es el nro. De pieza de seguimiento o Carta de Rendición que se quiere visualizar la imagen
    5. Lado = Es el lado del Acuse que se quiere visualizar. Los valores posibles son “F” (Frente) ó “D” (Dorso).

En caso de encontrar la pieza Devuelve la URL con el PDF correspondiente a la imagen solicitada. Por ej.

http://www1.oca.com.ar/SigmaWebService/Images/Acuses/lvc0qjj.gto.pdf

El manejo de errores les devolverá a los errores como una Excepción directamente desde el Web Services, es decir si su módulo donde van a implementar esto está hecho en Java o .Net van a poder atrapar dicha excepción directamente, que te paso a explicar con más detalle:

  • En Caso de algún error tanto funcional, por ej. La Pieza no Existe o que la imagen no está disponible como técnico por ej. La conexión no está disponible, la URL vendrá en blanco y la excepción podrá ser atrapada utilizando la Excepción "SoapException", cuya declaración se debe hacer incorporando en su proyecto el NameSpaces "System.Web.Services.Protocols".

Un código de ejemplo sería :

AcusesService.Service acuseService = new AcusesService.Service();
String url = "";
try
{
    url = acuseService.GetURLAcuse(txtcliente.Text, txtusuario.Text, txtpass.Text, txtnropieza.Text, txtlado.Text);
}
catch (SoapException soapEx) // Excepción disparada desde el Webservice
{
    if(SoapException.ClientFaultCode.Equals(soapEx.Code))
    {
        // Excepción causada por el cliente
    }
    if(SoapException.ServerFaultCode.Equals(soapEx.Code))
    {
        // Excepción causada por el servidor
    }
}
  • Donde se puede apreciar claramente que se puede saber si la excepción es causada del lado cliente o del lado servidor, es decir que con sólo mostrar la excepción que se devuelve en éste ejemplo en la variable "soapEx" es más que suficiente.

    • Para cuando la pieza exista más de una coincidencia con el mismo nro. De Pieza (no debería pasar en vuestro caso), devolverá "Existe más de una Pieza con número XXXX".

    Se adjunta una imagen de un Acuse recuperado desde este Web Service.

    1

Credenciales

Para obtener las credenciales y acceder a los webservices debes ponerte en contacto con nuestra area de sistemas. Lo podes solicitar en la siguiente casilla de correo: integraciones@oca.com.ar