CI6202 – Internet Programming

Technology Paper - Report

Team Members:
Name Matriculation Number

Baskaran Subashini G1801280L

Gupta Shreya G1801135D

Kumaresan Gomathi Jamuna G1801370D

Purushothaman Sowmiya G1801552F

Suresh Kumar Mahalakshmi G1801214B

EXTENDING WEB APPLICATION CAPABILITIES – WEB SERVICES

A web service is an open standardized medium to generate communication between client and server
applications over network for exchanging information between two devices.

Example: Ordering food in restaurant

The customer act as the service customer, the Kitchen acts like a service provider and the waiter acts like
an API (Application Programming Interface). Here the customer order the food items from menu and the
waiter makes the note of it and send the request to the kitchen so the required item will be processed and
send back the response back to the customer. Thus, the food will be delivered to the customer. The waiter
as API will understand the language and act as the communication medium between two services.

BENEFITS OF WEB SERVICES

1. Exposing Business Functionality on the network

A web service is a unit of managed code which provides some sort of functionality to client
applications that can be invoked over the internet through HTTP protocol. All applications are
mostly run over internet which makes the purpose of Web services more useful. That means the
web service provide the necessary functionality as required across anywhere on the internet.
2. Interoperability amongst Applications
The web services allow platform and Language independent communication which means that it
allows communication between one or more applications in sharing data and services among
them. Thus, the generic code can be written which can be understood by all the applications
instead of writing specific code for each application.
3. Use of Standardized Protocols
 Web services use standardized industry protocol for the communication which ensures business
an increase in quality and reduction in cost. The well-defined protocols is used by all the four
layers (XML Messaging, Service Transport, Service Discovery layers and Service Description) of
web service protocol stack.
4. Reduction in Cost of Communication
Use SOAP over HTTP protocol, so existing low-cost internet can be used to implement Web
Services.

WEB SERVICES SECURITY

As web applications are exposed to internet, a secured exchange of information is required and thus uses
the HTTPS protocol for communication.

There are three major security issues with web services,

1. Confidentiality
When a client sends request to the server it should ensure that the communication will remains
confidential. There should be a secured way of communication between the client and the server
over the web and this can be achieved by using secure sockets layer or SSL. Both the client and
the server will have a digital certificate to identify themselves as genuine.
2. Authentication
When a client connects to a web service it must allow only the authorized user to access the
service. For this the HTTP support for basic and digest authentication. Thus, like HTML
documents the services are protected from unauthorized users. SOAP Digital signature which
provides public key cryptography for the SOAP messages. This will validate the correct user and
will provide access only to the authorized users. SAML which is Security Assertion Markup
Language was used in Organization for the Advancement of Structured Information Standards
(OASIS).
3. Network Security
The firewall is required to protect the unauthorized user from accessing the application. The
process requires filtering out SOAP or XML-RPC messages and one possible way is to filter out
all HTTP POST requests which set the content type to text or xml. The alternative method is to
filter the SOAP Action HTTP header attribute. Thus, firewall helps as a tools which is designed
to filter the web service traffic.

COMPONENTS OF WEB SERVICES

There are two major web service components.

 WSDL
 UDDI
WSDL (Web Services Description Language):
WSDL is an XML pattern for depicting system administrations and how to utilize them. It portrays tasks
and messages are theoretically.
WSDL components:
  Definitions: Definitions are the central component of all WSDL reports. It is made reference to in
XML composition and includes both message definitions and information type definitions that
access the information type definitions
 Operations: Operations is the applied definition for the messages help by a Web benefit.
 Service binding: It depicts the substance in document and convention points of interest for a web
benefit.
 Data Types: Messages are utilized as XML patterns in information types.
 Message: It is an applied meaning of the information, the whole archive is exhibited as a message
and technique conjuring to be mapped.
 Port type: characterizing the gathering of activities for an authoritative and it's a unique
arrangement of tasks mapped to at least one end-focuses and it tends to be mapped to different
transports through different ties.
 Binding − It contains information organizations and convention for the arrangement of activities
and substance characterized for a specific port sort.
 Port – port is a mix of system address and official, giving administration correspondence of the
objective location.

WSDL document Structure:

A WSDL record can likewise contain different components, similar to augmentation components and an
administration component that makes it conceivable to gather together the meanings of a few web
benefits in a single WSDL report.

UDDI (Universal Description, Discovery, and Integration):

 UDDI is a determination for a circulated registry of web organizes.

 UDDI is an open system, stage autonomous.
 UDDI can impart by means of Java RMI Protocol, SOAP, and CORBA.
 UDDI utilizes Web Service Definition Language (WSDL) to portray specialized interfaces to web
administrations.
 UDDI is seen with WSDL and SOAP as major imperative principles of web administrations.
 UDDI is data about business benefits and characterizes how they associate over the Internet.
 It gives the meaning of a few administrations helping the portrayal and disclosure of associations,
organizations, and other Web Services suppliers make accessible.
 UDDI is utilized to convey by means of SOAP.

TYPES OF WEB SERVICES

1. SOAP (Simple Object Access Protocol)

It is crucial to exchange data among applications in today’s networked world. These applications could
be heterogeneous or hybrid which makes the data exchange complex. Since every programming language
can understand XML, it is used as an underlying medium for exchanging wide variety of data on Web.
But we need standard specifications on use of XML across all programming languages. That is where
SOAP comes in. SOAP works with XML over HTTP and provides a standard which could be used
across applications in a decentralized and distributed environment. Developers need not worry about
creating a custom XML message format for every service they want to make available.
Features of SOAP:
 Protocol independence
 Language independence
 Platform and operating system independence

Working of SOAP:
The SOAP specification exposes a standard, XML-based way to encode requests and responses,
including:
 Requests to invoke a method on a service, including in parameters
 Responses from a service method, including return value and out parameters
 Errors from a service

A SOAP message contains the following elements,

 Envelope: Envelope is the root element and defines the start and the end of the message. It is a
mandatory element.
 Header: Header is an optional sub element and contains attributes like credentials, API keys,
security information. This application related information is used in processing the message,
either at an intermediary point or at the ultimate end-point.
 Body: This element is mandatory. It contains XML data comprising the message intended for the
receiver.
 Fault: This element is optional and is the sub element of SOAP body. It is used for reporting
errors that occur while processing the message.
2. RESTful
REST stands for REpresentational State Transfer and was coined by Roy Fielding in 2000 as part of his
doctoral dissertation. REST is a software architecture style in contrast to a set of standards. It does not
impose any restriction on the format of a resource representation. Web services complying REST
architecture are called RESTful web services.

REST architecture describes Text Files, Html Pages, Images or any object that you may need to share to
other services as a resource. Each resource is identified by Uniform Resource Identifier (URI).

REST has the following features:

 State and functionality are divided into distributed resources

 Every resource is uniquely addressable using a uniform and minimal set of commands (typically
using HTTP commands of GET, POST, PUT, or DELETE over the Internet)
 The protocol is client/server, stateless, layered, and supports caching.

Key principles of REST API design:

1. Client-Server
Client and server are separated from each other. User can make changes to the client and server
application independently without impacting each other. This improves scalability of the
application.
2. Stateless
REST API is stateless i.e. requests can be made independently of each other. Each request
contains all the necessary information such as access token, user ID, API key, etc to complete
itself successfully. REST APIs do not take advantage of data stored on the server to determine
what to do with a call. This reduces memory requirements and keep the application scalable
because sessions are stored on the client and not on the server.
 3. Cache
Stateless APIs can increase request overhead by handling loads of incoming and outbound call.
Hence, REST encourages the storage of cacheable data. Response indicates that the data is
cacheable and can be stored up to a certain time or data needs to be real-time and response should
not be cached by the client (non-cacheable). This reduces the number of interactions with API
and internal server usage.
4. Uniform Interface
REST does not have application’s services, models, or actions tightly coupled to the API layer
but a uniform interface that allows independent evolution of the application. The uniform
interface simplifies the system architecture and lets the client interact with the server in a single
language, independent of the architectural backend of either.
5. Layered System
REST has a layered system where each layer has a specific functionality and responsibility. This
style allows an architecture of hierarchical layers that helps to create a more scalable and modular
application.
6. Code on Demand:
REST creates a smart application by allowing code to be transmitted via the API in the form of
applets and scripts. This reduces the number of features to be pre - implemented. The application
is no longer completely dependent on its own code structure.

A REST request has the following elements:

● an HTTP verb, which defines what kind of operation to perform

● a header, which allows the client to pass along information about the request
● a path to a resource
● an optional message body containing data

COMPARISON OF SOAP AND REST

SOAP REST

SOAP is a protocol. REST is an architectural style.

SOAP is a standardized protocol for transferring REST is more data driven.

structured information that’s more function-
driven.

SOAP only uses XML. REST permits different data formats like XML,
JSON,

SOAP requires more bandwidth. REST requires fewer resources

 SOAP-based calls cannot be cached. REST calls can be cached.

SOAP defines its own security. RESTful web services inherits security measures
from the underlying transport.

SOAP web services use JAX-WS as the java API. RESTful web services use JAX-WS as the Java
API

Works well in distributed enterprise environments. REST assumes direct point-to-point

communication.

DEMONSTRATION

Producing and consuming web services using JAX-WS:

JAX-WS is a standard XML based Java API to produce and consuming web services. In the following
section, a step by step approach for creating and utilizing Java based web services is demonstrated

SOAP Implementation:

Server application:

1. Create a new project and create a interface with methods that are going to be exposed as web
service

2. Add the logics that the webservice going to perform in the methods of the implementation class
a. The method getAllNotices return a list of notices
b. The method insertNotice takes a notice as input and add it to an existing list.
3. Set up SOAP based web services by creating web services for the implementation class
a. Web Services type – Bottom up approach is used to create the web services as it generates the
WSDL file (The web service contract) from the implementation logic. Another type of webservice,
Top down approach can be used when WSDL is given to generate the implementation logics.

b. Client generation (optional) - For testing the web service logic, a java proxy test client will be
generated depending upon the level of client selected.
4. WSDL file generation - In the next step, the methods to be included in the WSDL file should be
selected.

5. Client Generation by selecting the methods to be tested

 6. Deploy the web service to the Tomcat server

Client application:

a. Testing the service through the generated client proxy

b. Testing the service through SOAP UI – Testing getAllNotices service

Testing insertNotice service:
INTEGRATION WITH THIRD PARTY APPLICATION
Third-party integrations are becoming an essential ingredient in web and mobile applications. This
enables developers to add additional features to their application and improve upon business processes.

This section deals with integrating our application with an SMS service provider which allows the user to
send text messages to mobile numbers via the internet. SMS API allows to send text messages in bulk,
triggers transactional alerts and OTP, receive inbound SMS, pull reports, and manage contacts. Several
third-party SMS service provider gateways are available and we have used Textlocal messaging service.

Textlocal provides REST-based web services with JSON response.

Host: https://api.txtlocal.com/send/

Request type: POST

Content-Type: "application/x-www-form-urlencoded"

Parameters:

PARAMETERS DATA TYPE DESCRIPTION

sender String The sender name for your message. This must be between 3 to 11
alphanumeric characters.
numbers Number Comma-separated list of mobile numbers with country code (i.e.
91123456789).
message String The message content. The maximum length is 765 characters.
apiKey String Authentication key generated for each application. (Link to
generate API key: https://control.txtlocal.co.uk/settings/apikeys/)
Response:

SUCCESS: FAILURE:

Steps to Integrate with Textlocal Messaging Service using JSP and Java Servlets:

1. Create JSP page (smsView.jsp) with a form element that fetches the details (Sender’s name, Mobile
number and Message) from the user and posts the data to a Servlet (SmsServlet.java).
2. Include the JSP Servlet mapping in the web.xml file using servlet-mapping.

3. The doPost method of the Servlet class (SmsServices.java) receives the request and generates an
HTTP POST request to be sent to the third party application. The sender’s name, mobile number,
message and API key are sent in the body of the request. The response received is then parsed and
forwarded to another JSP page (responseView.jsp).

4. Depending on the response received from the POST request, a success or failure message is
displayed using JSP (responseView.jsp).
Result:

1. Web Page:

2. SMS received:

REFERENCES:
http://www.springboottutorial.com/introduction-to-web-services-with-soap-and-rest

https://www.codementor.io/java/tutorial/soap-and-rest-java-web-services

https://www.udemy.com/web-services-api-step-by-step-beginner-tutorial/

https://youtu.be/s7wmiS2mSXY