Web Services in Mobile Applications

Information and communication technologies are designed to support and anticipate the continuing changes of the information society, while outlining new economic, social and cultural dimensions. We see the growth of new business models whose aim is to remove traditional barriers and improve the value of goods and services. Information is a strategic resource and its manipulation raises new problems for all entities involved in the process. Information and communication technologies should be a stable support in managing the flow of data and support the integrity, confidentiality and availability. Concepts such as eBusiness, eCommerce, Software as a Service, Cloud Computing and Social Media are based on web technologies consisting of complex languages, protocols and standards, built around client-server architecture. One of the most used technologies in mobile applications are the Web Services defined as an application model supported by any operating system able to provide certain functionalities using Internet technologies to promote interoperability between various applications and platforms. Web services use HTTP, XML, SSL, SMTP and SOAP, because their stability has proven over the years. Their functionalities are highly variable, with Web services applications exchange type, weather, arithmetic or authentication services. In this article we will talk about SOAP and REST architectures for web services in mobile applications and we will also provide some practical examples based on Android platform.


Introduction
The distributed computing systems become more and more important in the new world dominated by the Information Technologies.This has resulted in recent standardization effort of distributed computing architecture, which is known as Service Oriented Architecture (SOA).The main component of this architecture is the Web Service.Some of the challenges in implementing the SOA architecture are maintainability, reliability, and security [1].
In the specialized literature we can find several articles [2], [3], [4] that address the issue of distributed architectures and web services in areas such as education, health and business.In fact, Web services are a solution for the integration of distributed information systems, autonomous, heterogeneous and selfadaptable to the context.Although there are similarities between Web Services and Web sites, we mention three notable differences between these technologies:  websites have generally a friendly inter-face to communicate with the user and the opposite we have web services that do not require a graphical user interface;  if Web sites are designed to facilitate interaction with their users, web services will only exchange data with other applications;  websites must be accessible using browsers while web services can adapt to several environments or devices.An application built on web services architecture can have several roles; it can be both the consumer and the service provider or just register whose role is to keep the web service description.The Service Provider is the person or organization that provides access to a web service in order to meet certain requirements.The consumer (Service Requester) is the entity that needs this service and meets a register known as the Discovery Service Agency or Broker who will make the connection between the two components [5].In this paper we intend to present a review of the main architectures based on web services 1 DOI: 10.12948/issn14531305/17.2.2013.02and we also provide an application implementation which can be used in the industry of telecommunication.

The Components of the Web Services Eco-System
According to some authors [6], web services were initially mainly intended to engage in dynamic business-to-business (B2B) interactions with services deployed on behalf of other enterprises or business entities.Broad interest in standardization/customization efforts was aimed at reducing the necessary user interaction.However, with the advancement of Web service technology the complexity of possible tasks and the availability of services any time anywhere, e.g. through powerful mobile client devices, will strongly increase.The architecture of calling services is based on its description as shown in Figure 1.The main building blocks of a web service are discussed below, along with a description of each and the function that satisfies thus making up web service stack:  Discovery -the process that determines the location of the Web service that will connect.The discovery will be done using centralized directories or using other ad-hoc methods;  Description -web service discovery once made, the customer must receive a description of how it will achieve interac-tion with the service.Description consists of structured metadata about the interface used and written documentation of details and examples of using the web service;


The format of the messages -this element is necessary for encoding the message between the client and web service.This format allows abstraction of communication protocols for a better focus on the logic of the problem;  Encoding must allow processing by any language; XML is the best choice due to the structural and text;  Transport -how data composing a message is transmitted between partners in conversation.

Fig. 2. The main building blocks of a web service
Some authors [8], [9] consider that SOAP based Web services are the preferred way to implement the SOA initiative in today's complex and heterogeneous computing environment.SOAP-based Web services present greater flexibility at lower integration costs over RESTful Web services that instead offer great performance through lighter messaging system.Instead, we consider that the applications that use REST web services are more robust and the costs are not a problem for the implementation.common registry and provides publishing functionality of the service.The discovery service is currently done by: Universal Description, Discovery, and Integration (UDDI).SOAP is an XML-based protocol that exchanges information between computers in a decentralized and distributed environment.The acronym SOAP originally derived from Simple Object Access Protocol, and then from Service Oriented Architecture Protocol.The initial name was abandoned from version 1.2 when it was considered misleading.The protocol consists of three elements:  an envelope that defines the content of a message and how to process it;

REST Architecture
Representational State Transfer (REST) is a new architecture for web services that is having a significant impact on the industry.Most of the new public web services from large vendors (Google, Yahoo, Amazon, Microsoft) rely on REST as the technology for sharing and merging information from multiple sources [11].Representational State Transfer involves a set of rules or a resourceoriented architecture that supports the simplicity of web technologies, using standards such as Hypertext Transfer Protocol Uniform Resource Identifier and Extensible Markup Language.Among the most notable features of the REST architecture, we can mention [12]:  the data transmitted from the client to the server is in URI;  the operation performed by the server on the data is described in the HTTP method directly;  resource -anything that can be labeled as object (concrete or abstract) will automatically be a resource;  URI for each resource that contains her name and address.In most cases this URI is identical to the Uniform Resource Locator (a basic form of identifier);  representations -their core resources will not represent data, but only the idea on the structure of the data service.Fig. 3.The layers of SOAP and REST [11] According to some authors [13], the HTTP methods such as GET and POST are the verbs that the developer can use to describe the necessary create, read, update, and delete (CRUD) actions to be performed.Some may see an analogy to operations in SQL, which also relies on a few common verbs (Insert-PUT, Select-GET, Update-POST, Delete-DELETE).However, the REST style and HTTP protocol are mutually exclusive, and REST does not require HTTP.

A Model of Mobile Application Using Web REST Services
In this section we implement an Android mobile client which uses REST services in order to obtain information about the phone calls for a company that has many mobile devices.The mobile application must meet economical ( [14], [15]) and technical requirements:  Because until we get answers from the service on may take some time depending on the internet connection, we posted a message dialog that notifies the user that is running an operation that can last longer.For this we used a ProgressDialog with setIndeterminate property (true), which is displayed when the service is started.It is cleared when the service returns us an answer.Web services provided by web application YourView are presented in JSON format.To interpret them within the mobile application, we chose to use the Jackson library that facilitates the transformation of a string in JSON format in a specified class.For example, a user authentication method returns a response like: { "message": "You logged in successfully", "type": "success", "result": { "user_type": "type", "companyid": "123456", "username": "test" } } To interpret it we created a class like this: It is very important to take into account the response time of the application we create.Displaying a long list that can contain hundreds or even thousands of lines complicates the application's behavior, and whether the list is created by querying a web service then has to take into account the response time of the web service.In the application YourView each report is displayed in a list form and can contain hundreds of lines.To take into account the above mentioned we proceeded as follows: first we need to create the list so that it can handle a large number of lines without hindering navigation list.The list is created custom: each line will display more details when the user clicks on it and for this we created a new class that extends BaseAdapter.Usually every list contains more items than are displayed on the screen and when the user navigates through the list, with rows also disappear the view sites associated with them.Objects that represent these lines can be reused for new rows displayed by convertView parameter of the method getView(), or for each line displayed should build Android layout xml file as:

Fig. 4. The reports generated by the application
As you can see in the above code, we have implemented OnScrollListener, which will indicate which elements of our list are visible.When we reached the last item in the list, the application sends a request to the web service to bring us the next set of data.Once we receive the reply we add new items to the list and update variables.The modern applications must meet a number of requirements [18] and we consider that our proposal is a valid one.

Conclusions
Modern mobile applications need a robust infrastructure and various services in order to obtain data from heterogeneous contexts.As we could see in this paper, REST web services are a valid option because they can be invoked in an elegant manner and they are really useful for the client application.Also, it is very important to synchronize the threads so that the application runs normally, without blocking sequences.We consider that the future of SOAP and REST architectures will depend on the support offered by the industry in the implementation of new series of features according to the technological evolution.


the level of service description: is responsible for describing the public interface of the service.Service description is achieved by Web Service Description Language (WSDL);  the level of service discovery: this is responsible for centralizing services into a


covers many mobile device types, running at least Android 2.3.3; authentication of the same screen of companies, divisions and simple users;  access to available reports for each user, depending on the selected reporting period;  viewing data as graphs;  viewing messages.

Fig. 4 .
Fig. 4. The sections of the application To convert the response received in the created class, we used the following lines of code: