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.
![1](images/1acuse.png)
For all the above, there are certain requirements when developing or consuming the web services:
- A standard way of representing the data.
- A common and extensible message format.
- A common and extensible language to describe the services.
- A way of discovering Internet’s services.
XML is the obvious option for this requirement.
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.
In this case the option is WSDL. It is a language based on XML and developed by IBM and Microsoft.
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.asmxThe Public Methods of this Web Services that is going to be used in theory is:
- GetURLAcuse
- 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).
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.
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.
![1](images/2acuse.png)
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