Web Service Delivery 2.0

Introduction

The current web applications are no longer enough. The present Electronic business does not integrate the Internet applications with the rest of the companies’ software. If the companies want to get the maximum benefit from the Internet, websites must evolve. This is the context in which web services emerge.

That is the reason why the concept of web services has strongly come up in the last years, and it was even confirmed that it would change the way of programming the Internet-oriented applications to a service-oriented architecture.
We could say that a web service is an application that can be descripted, published, localized and invoked through a network, generally the Internet. It combines the best aspects of the development based on components and the Web.
Like the components, the web services are functions that are inside a black box, that can be reused without worrying about how they were implemented. Unlike the current technology of components, instead of being accessed through specific protocols of objects’ model, like RMI, DCOM or IIOP; they are accessed by using web protocols, like HTTP and XML.
The web services’ interface is defined in terms of the messages it accepts and returns, therefore the web services consumers can be implemented in any platform and in any programming language, it just has to be able to create and consume the messages defined by the web services’ interface.

The Web Services’ Model

The basic architecture of the web services’ model describes a consumer, a supplier (the one implements) and occasionally a broker (broker UDDI). The publishing, finding and connecting operations are related to these agents.
The basic idea is that a supplier publishes their services to a broker, then a consumer connects to the broker to find the required services and once this is done, a connection between the consumer and supplier is made.
Each entity can play one or all of the roles.

For all the above, there are certain requirements when developing or consuming the web services:

A standard way of representing the data.

XML is the obvious option for this requirement.

A common and extensible message format.

SOAP is the chosen one in this case; SOAP is a lightweight protocol for information exchange. We will see this in more detail later on this document.

A common and extensible language to describe the services.

In this case the option is WSDL. It is a language based on XML and developed by IBM and Microsoft.

A way of discovering Internet’s services.

UDDI is used for this purpose; it specifies a system to publish and localize the services of the suppliers and consumers, respectively. We will see this in more detail later on this document.

Web Servicio Descripyion to Visualize Notices from Oca Delivery 2.0

OCA’s service description is available through the WebServices SigmaService methods and is published in the following URL :

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

The Public Methods of this Web Services that is going to be used in theory is:

GetURLAcuse

This method is used to visualize the images of the Digital Notices of the items that were processed and delivered by OCA, where the items and statemen letters can be visualized.

It has 5 parameters: clienteLogueo (client’s Loguin), usuario (username), password, numeroPieza (Item’s ID), Lado a Visualizar (side to be visualized).

In which the first three parameters are the same that are used for an item’s enquiry by the other Web Services.

ClienteLogueo = The client’s acronym registered at OCA’s
Usuario = the client’s username code (e.g. UserCLI)
Password = the client’s username’s password (e.g. XXXX)
NumeroPieza = The item’s tracking number or Statement Letter that is wanted to be visualized on the image.
Lado = The Notice’s side that is wanted to be visualized. The possible values are “F” (Front) or “D” (Back).

If the item is found, it returns the URL with the PDF that corresponds to the required image. For example: http://www1.oca.com.ar/SigmaWebService/Images/Acuses/lvc0qjj.gto.pdf

The error handling will return the errors as an Exception directly from the Web Services, that is to say, if the module where you are going to implement this is created in Java or .Net, you will be able to catch that exception directly. See a more detailed explanation below:

If there is an error, either functional, for instance: “the item does not exist”, or if the image is not technically available, e.g., “The connection is no available”, the URL will be blank and it will be possible to catch the exception using the "SoapException" Exception, whose statement must be done including in its project the "System.Web.Services.Protocols" NameSpaces.

A sample of a code would be:

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
    }
}

In which you can clearly notice if the exception was generated by the client or by the server, that is to say that just showing the exception that is returned in this example in the "soapEx" variable is more than enough.

By the time the item exists, more than one coincidence with the same item’s number (it should not be your case) will return the following message: "There is more than one Item with the number XXXX".

An image of a Notice recovered from this Web Service is attached.

Credentials

To get the credentials and access to the webservices, you should get in contact with our IT area. You can make the request to the following e-mail address: integraciones@oca.com.ar