Web
services and SOAP
Applications
that are accessed through browsers are web applications and it is the
collection of multiple web pages. These are basically dependent on client
server architecture where browser acts as a client which sends the request to
server. Afterwards, web pages are rendered as per responses from the server.
Purpose of web services is communications between various programs and
applications.
During
building any web application, order of focus is on:
·
UI
portion[Front end implementation]
·
Functional
portion[Back end implementation]
Web services
Web
services are mainly used to communicate the information between two systems
ignoring UI interaction. Messages are transferred from one application to
another application via JSONS and XMLs etc.
Web
services are mainly dependent on back end implementation, UI doesn't have any
space. Clients can access only exposed methods of any functionality. Majority
of the qa testing
services are focusing on automating the web services to speed
up the testing for integrated applications.
Web
services are constructed basically to hide the implementation of any product
and APIs are exposed to perform specific functions. Web services leads to many
advantages for various software testing companies mentioned below:
·
Re-usability
of any code
·
Reduced
the Complexity
·
Enhanced
the features of any product
·
Impact
on cost
·
Speed
As
communications protocols and message formats are standardized in the web
community, it becomes increasingly possible and important to be able to
describe the communications in some structured way. WSDL addresses this need by
defining an XML grammar for describing network services as collections of
communication endpoints capable of exchanging messages. WSDL service
definitions provide documentation for distributed systems and serve as a recipe
for automating the details involved in applications communication.
A
WSDL document defines services as collections of network
endpoints, or ports. In WSDL, the abstract definition of endpoints
and messages is separated from their concrete network deployment or data format
bindings. This allows the reuse of abstract definitions: messages,
which are abstract descriptions of the data being exchanged, and port
types which are abstract collections of operations. The
concrete protocol and data format specifications for a particular port type
constitutes a reusable binding. A port is defined by associating a
network address with a reusable binding, and a collection of ports define a
service. Hence, a WSDL document uses the following elements in the definition
of network services:
- Types– a container for data type
definitions using some type system (such as XSD).
- Message– an abstract, typed definition
of the data being communicated.
- Operation– an abstract description of an
action supported by the service.
- Port
Type–an
abstract set of operations supported by one or more endpoints.
- Binding– a concrete protocol and data
format specification for a particular port type.
- Port– a single endpoint defined as
a combination of a binding and a network address.
- Service– a collection of related
endpoints.
It
is important to observe that WSDL does not introduce a new type definition language.
WSDL recognizes the need for rich type systems for describing message formats,
and supports the XML Schemas specification (XSD) as its canonical type system.
However, since it is unreasonable to expect a single type system grammar to be
used to describe all message formats present and future, WSDL allows using
other type definition languages via extensibility.
In
addition, WSDL defines a common binding mechanism. This is
used to attach a specific protocol or data format or structure to an abstract
message, operation, or endpoint. It allows the reuse of abstract definitions.
In
addition to the core service definition framework, this specification
introduces specific binding extensions for the following
protocols and message formats:
- SOAP
- HTTP
GET / POST
- MIME
Although
defined within this document, the above language extensions are layered on top
of the core service
definition framework. Nothing precludes the use of other binding
extensions with WSDL.
Compare
and contrast web applications with web services
|
Web application
|
Web
service
|
|
·
User-to-program interaction
|
·
Program-to-program interaction
|
|
·
Static integration of components
|
·
Dynamic integration of components
|
|
·
Monolithic service
|
·
Service aggregation (micro-services)
|
|
·
Ad hoc or proprietary protocol
|
·
Interoperability (RPC/SOAP/REST)
|
Discuss what
WSDL is and the use of it in the context of web services
WSDL
is an XML vocabulary for describing Web services allowing developers to
describe Web Services and their capabilities, in a standard manner. Standard
format to describe a Web Service (description stack).WSDL specifies three
fundamental properties:
01. What a
service does - operations (methods) provided by the service.
02. How a service
is accessed - data format and protocol details.
03. Where a
service is located - Address (URL) details.
The
document written in WSDL is also simple called a WSDL (or WSDL document) .WSDL
is a contract between the XML (SOAP) Web service and the client who wishes to
use this service .The service provides the WSDL document and the Web service
client uses the WSDL document to create the stub (or to dynamically decode
messages).
The
WSDL describes services as collections of network endpoints, or ports. The WSDL
specification provides an XML format for documents for this purpose.
The abstract definitions of ports and messages are separated from their
concrete use or instance, allowing the reuse of these definitions. A port is
defined by associating a network address with a reusable binding, and
a collection of ports defines a service. Messages are abstract descriptions of
the data being exchanged, and port types are abstract collections of supported
operations. The concrete protocol and data format specifications for a
particular port type constitutes a reusable binding, where the operations and
messages are then bound to a concrete network protocol and message format. In
this way, WSDL describes the public interface to the Web service.
WSDL
is often used in combination with SOAP and an XML schema to
provide Web services over the internet. A client program connecting to a
Web service can read the WSDL file to determine what operations are available
on the server. Any special data types used are embedded in the WSDL
file in the form of XML Schema. The client can then use SOAP to actually call
one of the operations listed in the WSDL file using for example XML over HTTP.
The
current version of the specification is 2.0; version 1.1 has not been endorsed
by the W3C but version 2.0 is a W3C recommendation. WSDL 1.2 was
renamed WSDL 2.0 because of its substantial differences from WSDL 1.1. By
accepting binding to all the HTTP request methods (not only GET and
POST as in version 1.1), the WSDL 2.0 specification offers better support
for Restful web service, and is much simpler to implement. However support
for this specification is still poor in software development kits for
Web Services which often offer tools only for WSDL 1.1 For example, the version
2.0 of the Business process execution language only supports WSDL
1.1.
Advantages of SOAP
SOAP
is the protocol used for data interchange between applications. Below are some
of the reasons as to why SOAP is used.
·
When
developing Web services, you need to have some of language which can be used
for web services to talk with client applications. SOAP is the perfect medium
which was developed in order to achieve this purpose. This protocol is also
recommended by the W3C consortium which is the governing body for all web
standards.
·
SOAP
is a light-weight protocol that is used for data interchange between
applications. Note the keyword 'light.' Since SOAP is based on the XML
language, which itself is a light weight data interchange language, hence SOAP
as a protocol that also falls in the same category.
·
SOAP
is designed to be platform independent and is also designed to be operating
system independent. So the SOAP protocol can work any programming language
based applications on both Windows and Linux platform.
·
It
works on the HTTP protocol –SOAP works on the HTTP protocol, which is the
default protocol used by all web applications. Hence, there is no sort of
customization which is required to run the web services built on the SOAP
protocol to work on the World Wide Web.
SOAP Building blocks
The
SOAP specification defines something known as a "SOAP message"
which is what is sent to the web service and the client application.
The
diagram below shows the various building blocks of a SOAP Message.
The
SOAP message is nothing but a mere XML document which has the below components.
·
An
Envelope element that identifies the XML document as a SOAP message – This is
the containing part of the SOAP message and is used to encapsulate all the
details in the SOAP message. This is the root element in the SOAP message.
·
A
Header element that contains header information – The header element can
contain information such as authentication credentials which can be used by the
calling application. It can also contain the definition of complex types which
could be used in the SOAP message. By default, the SOAP message can contain
parameters which could be of simple types such as strings and numbers, but can
also be a complex object type.
Compare the Port Type and operation elements in WSDL with the java
equivalences
|
Port type
|
Operation
|
|
Port Type element may have one or more operation elements
|
All patio in a port type must have different names.
|
|
In java equivalence port type – java interface
|
In java equivalence operation – method name
|
|
WSDL supports at least a single input and output message
|
Each operations may define input, output, fault message.
|
Compare and contrast the binding and service elements in WSDL
|
Binding
|
Service
|
|
one port Type can be bound to several different protocols by using
more than one port
|
Contain one or more port elements.
|
|
Map a Port Type to a specific protocol,
|
It binds the Web service to a specific network-addressable location
|
|
Bindings refer back to port Types by name, just as operations point to
messages.
|
Reference a particular binding, and along with addressing information
is wrapped together into a service element to form the final physical,
network addressable Web service
|
Explain how SOAP is
used with HTTP
SOAP is an XML-based
protocol for accessing web services over HTTP. It has some specification which
could be used across all applications. SOAP is known as the Simple Object
Access Protocol, but in later times was just shortened to SOAP v1.2. SOAP is a
protocol or in other words is a definition of how web services talk to each
other or talk to client applications that invoke them. SOAP was developed as an
intermediate language so that applications built on various programming
languages could talk easily to each other and avoid the extreme development
effort.
SOAP Communication Model.
All
communication by SOAP is done via the HTTP protocol. Prior to SOAP, a lot of
web services used the standard RPC (Remote Procedure Call) style for
communication. This was the simplest type of communication, but it had a lot of
limitations.
Let's
consider the below diagram to see how this communication works. In this
example, let's assume the server hosts a web service which provided 2 methods
as
·
GetEmployee - This would get all Employee
details
·
SetEmployee – This would set the value of the
details like employees dept, salary, etc. accordingly.
In
the normal RPC style communication, the client would just call the methods in
its request and send the required parameters to the server, and the server
would then send the desired response.
The
above communication model has the below serious limitations
- Not Language Independent – The server hosting the
methods would be in a particular programming language and normally the
calls to the server would be in that programming language only.
- Not the standard protocol – When a call is made to the
remote procedure, the call is not carried out via the standard protocol.
This was an issue since mostly all communication over the web had to be
done via the HTTP protocol.
- Firewalls – Since RPC calls do not go via the normal
protocol, separate ports need to be open on the server to allow the client
to communicate with the server. Normally all firewalls would block this
sort of traffic, and a lot of configuration was generally required to
ensure that this sort of communication between the client and the server
would work.
To
overcome all of the limitations cited above, SOAP would then use the below
communication model
- The client would format the information regarding
the procedure call and any arguments into a SOAP message and sends it to
the server as part of an HTTP request. This process of encapsulating the
data into a SOAP message was known as Marshalling.
- The server would then unwrap the message sent by
the client, see what the client requested for and then send the
appropriate response back to the client as a SOAP message. The practice of
unwrapping a request sent by the client is known as Demarshalling.
One
thing to note is that SOAP messages are normally auto-generated by the web
service when it is called. Whenever a client application calls a method in the
web service, the web service will automatically generate a SOAP message which
will have the necessary details of the data which will be sent from the web
service to the client application.
A
simple SOAP Message has the following elements –
· The
Envelope element
· The
header element
· The
body element
· The
Fault element (Optional)
SOAP
Envelope Element
The
first bit of the building block is the SOAP Envelope. The SOAP Envelope is used
to encapsulate all of the necessary details of the SOAP messages, which are
exchanged between the web service and the client application.
The
SOAP envelope element is used to indicate the beginning and end of a SOAP
message. This enables the client application which calls the web service to
know when the SOAP message ends.
The
Fault message
When
a request is made to a SOAP web service, the response returned can be of either
2 forms which are a successful response or an error response. When a success is
generated, the response from the server will always be a SOAP message. But if
SOAP faults are generated, they are returned as "HTTP 500" errors.
The
SOAP Fault message consists of the following elements.
1. <faultCode>-
This is the code that designates the code of the error. The fault code can be
either of any below values
2. <faultString> -
This is the text message which gives a detailed description of the error.
3. <faultActor> (Optional)-
This is a text string which indicates who caused the fault.
4. <detail>(Optional) -
This is the element for application-specific error messages. So the application
could have a specific error message for different business logic scenarios.
JAX-WS
JAX-WS is an abbreviation of “Java API
for XML-Based Web Services”
and is a Java standard API for handling Web service using SOAP etc.
Using JAX-WS, Java object can be sent by converting the same to
XML in conformance with SOAP specifications.
Therefore, although information is exchanged in SOAP Web Service
using XML, the user can handle the data without being aware of XML structure.
Main Java EE servers like Oracle WebLogic Server or JBoss
Enterprise Application Platform use JAX-WS implementation on server side and
can easily publish Web service by using the function without adding a specific
library.
However, since Tomcat does not implement JAX-WS, a separate
JAX-WS implementation library must be added while using Tomcat.
For details, refer “Web service development on Tomcat”.
Spring Framework supports JAX-WS linkage function and
implementation can be easily done for both SOAP server and client using this
function.
Overview of the recommended access flow using this function is
given below. Here, it is assumed that the Web application acting as a SOAP
client (Fig. on the left) access SOAP server (fig. on the right).
Testing
of web services is one of the important type of software testing approach,
which is mainly used to determine the expectations for reliability,
functionality, performance, etc.
As
these days Automated testing is considered as one of the most trending
methodology in the field of software testing, hence testing web apps based on
RESTful APIs through automation will provide effective test results. Some of
the best & popular tools for web services testing are:
1. SoapUI,
2. TestingWhiz,
3. SOATest
4. TestMaker,
5. Postman,
etc.
Below three frameworks are widely used in the Web
Service testing.
i) SoapUI
tool/framework is a popular open source Web Services
Testing tool in use since 2005. SoapUI is one of the initial testing tools for
WS and has an active and vibrant community. This framework supports cross
platform as it is written in Java. SoapUI is a simple and easy to use GUI based
tool to develop test suites across the SOAP and RESTful Web Services. It also
supports command line (CLI) to execute the tests. SoapUI does support other
languages such as Groovy and Javascript.
ii) Jersey client
API is an open source implementation of JAX-RS (Java API for XML REST Services)
that is used for developing RESTful Web Services. It is created by Oracle
(earlier Sun Microsystems). This framework is not a test framework but instead
a simple WS client Java APIs to consume in TestNG/JUnit frameworks while
developing the tests. A wrapper test framework with common functionality can be
created on top of Jersey.
iii) REST Assured framework is a free
and open source Java library to work with REST APIs. This framework specialty
is that it is very easy to send requests and parse the JSON responses.
Explain the
annotations in JAX-WS, providing examples of their use
API
for XML-Based Web Services (JAX-WS) relies on the use of annotations to specify
metadata associated with web services implementations and to simplify the
development of web services. Annotations describe how a server-side service
implementation is accessed as a web service or how a client-side Java class
accesses web services.
The
JAX-WS programming standard introduces support for annotating Java classes with
metadata that is used to define a service endpoint application as a web service
and how a client can access the web service. JAX-WS supports the use of
annotations based on the Metadata Facility for the Java Programming Language
(Java Specification Request (JSR) 175) specification, the Web Services Metadata
for the Java Platform (JSR 181) specification and annotations defined by the
JAX-WS 2.0 and later (JSR 224) specification which includes JAXB annotations.
Using annotations from the JSR 181 standard, you can simply annotate the
service implementation class or the service interface and now the application
is enabled as a web service. Using annotations within the Java source
simplifies development and deployment of web services by defining some of the
additional information that is typically obtained from deployment descriptor
files, WSDL files, or mapping metadata from XML and WSDL into the source
artifacts.
Use
annotations to configure bindings, handler chains, set names of port Type,
service and other WSDL parameters. Annotations are used in mapping Java to WSDL
and schema, and at runtime to control how the JAX-WS runtime processes and
responds to web service invocations.
It
uses annotations,
· @WebService
· @WebMethod
· @OneWay
· @WebParam
· @WebResult
· Etc…
No comments:
Post a Comment