Web Application
A web application is a computer program that utilizes web browsers and web technology to perform tasks over the Internet.
Web applications use a combination of server-side scripts (PHP and ASP) to handle the storage and retrieval of the information, and client-side scripts (JavaScript and HTML) to present information to users.
Benefits
• Web applications run on multiple platforms regardless of OS or device as long as the browser is compatible
• All users access the same version, eliminating any compatibility issues
• They are not installed on the hard drive, thus eliminating space limitations
• They reduce software piracy in subscription-based web applications (i.e. SaaS)
• They reduce costs for both the business and end user as there is less support and maintenance required by the business and lower requirements for the end user’s computer
Web Service
Web service is a standardized medium to propagate communication between the client and server applications on the World Wide Web.
A web service is a software module which is designed to perform a certain set of tasks.
Need of Web Service
Modern day business applications use variety of programming platforms to develop web-based applications. Some applications may be developed in Java, others in .Net, while some other in Angular JS, Node.js, etc.
Web Application VS Web Service
|
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)
|
WSDL Document - WSDL stands for Web Services Description Language.
It is used to describe web services and is a xml document.
A WSDL document has a definitions element that contains the other five elements, types, message, portType, binding and service. The following sections describe the features of the generated client code.
WSDL supports the XML Schemas specification (XSD) as its type system.
specifies three fundamental properties:
· What a service does - operations (methods) provided by the service
· How a service is accessed - data format and protocol details
· Where a service is located - Address (URL) details
Definitions
Contains the definition of one or more services. JDeveloper generates the following attribute declarations for this section:
· name is optional.
· targetNamespace is the logical namespace for information about this service. WSDL documents can import other WSDL documents, and setting targetNamespace to a unique value ensures that the namespaces do not clash.
· xmlns is the default namespace of the WSDL document, and it is set to http://schemas.xmlsoap.org/wsdl/.
· All the WSDL elements, such as <definitions>, <types> and <message> reside in this namespace.
· xmlns:xsd and xmlns:soap are standard namespace definitions that are used for specifying SOAP-specific information as well as data types.
· xmlns:tns stands for this namespace.
· xmlns:ns1 is set to the value of the schema targetNamespace, in the <types> section.
Element
|
Description
|
<types>
|
Provides information about any complex data types used in the WSDL document. When simple types are used the document does not need to have a types section.
|
<message>
|
Provides information about any complex data types used in the WSDL document. When simple types are used the document does not need to have a types section.
|
<portType>
|
An abstract set of operations supported by one or more endpoints
|
<binding>
|
Describes how the operation is invoked by specifying concrete protocol and data format specifications for the operations and messages.
|
<Operation>
|
An abstract description of the action supported by the service.
|
<port>
|
Specifies a single endpoint as an address for the binding, thus defining a single communication endpoint.
|
<service>
|
Specifies the port address(es) of the binding. The service is a collection of network endpoints or ports.
|
Features of WSDL
· WSDL is an XML-based protocol for information exchange in decentralized and distributed environments.
· WSDL definitions describe how to access a web service and what operations it will perform.
· WSDL is a language for describing how to interface with XML-based services.
· WSDL is an integral part of Universal Description, Discovery, and Integration (UDDI), an XML-based worldwide business registry.
· WSDL is the language that UDDI uses.
· WSDL is pronounced as 'wiz-dull' and spelled out as 'W-S-D-L'.
WSDL Usage
WSDL is often used in combination with SOAP and XML Schema to provide web services over the Internet. A client program connecting to a web service can read the WSDL to determine what functions are available on the server. Any special datatypes 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 functions listed in the WSDL.
Port Type and operation elements in WDSL vs Java equivalences
Operation − It is the abstract definition of the operation for a message, such as naming a method, message queue, or business process, that will accept and process the message.
Port − It is a combination of a binding and a network address, providing the target address of the service communication.
Port type − It is an abstract set of operations mapped to one or more end-points, defining the collection of operations for a binding; the collection of operations, as it is abstract, can be mapped to multiple transports through various bindings. Contain a set of operations that incorporates input, output and fault messages and parameter order port. Type element may have one or more operation elements, each of which defines an RPC- or document style Web service method
Java equivalence:
port Type -> java interface
operation -> method name
The <portType> element combines multiple message elements to form a complete one-way or round-trip operation.
For example, a <portType> can combine one request and one response message into a single request/response operation. This is most commonly used in SOAP services. A portType can define multiple operations.
<service name = "Hello_Service"> <documentation>WSDL File for HelloService</documentation> <port binding = "tns:Hello_Binding" name = "Hello_Port"> <soap:address location = "http://www.examples.com/SayHello/"> </port> </service>
Patterns of Operation
WSDL supports four basic patterns of operation −
One-way
The service receives a message. The operation therefore has a single input element. The grammar for a one-way operation is −
<wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name = "nmtoken"> <wsdl:input name = "nmtoken"? message = "qname"/> </wsdl:operation> </wsdl:portType > </wsdl:definitions>
Request-response
The service receives a message and sends a response. The operation therefore has one input element, followed by one output element. To encapsulate errors, an optional fault element can also be specified.
<wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> <wsdl:input name = "nmtoken"? message = "qname"/> <wsdl:output name = "nmtoken"? message = "qname"/> <wsdl:fault name = "nmtoken" message = "qname"/>* </wsdl:operation> </wsdl:portType> </wsdl:definitions>
Solicit-response
The service sends a message and receives a response. The operation therefore has one output element, followed by one input element. To encapsulate errors, an optional fault element can also be specified.
<wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> <wsdl:output name = "nmtoken"? message = "qname"/> <wsdl:input name = "nmtoken"? message = "qname"/> <wsdl:fault name = "nmtoken" message = "qname"/>* </wsdl:operation> </wsdl:portType > </wsdl:definitions>
Notification
The service sends a message. The operation therefore has a single output element.
<wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name = "nmtoken"> <wsdl:output name = "nmtoken"? message = "qname"/> </wsdl:operation> </wsdl:portType> </wsdl:definitions>
Binding vs service elements in WSDL
The <service> element defines the ports supported by the web service. For each of the supported protocols, there is one port element. The service element is a collection of ports.
Web service clients can learn the following from the service element −
where to access the service,
through which port to access the web service, and
how the communication messages are defined.
The service element includes a documentation element to provide human-readable documentation.
The binding attributes of port element associate the address of the service with a binding element defined in the web service.
How SOAP is used with HTTP
HOW SOAP is used for functional oriented communication
Structure of SOAP message in message-oriented communication
SOAP is a simple XML-based protocol that allows applications to exchange information over HTTP.SOAP supports both functional oriented and message oriented communication SOAP messages are carried as the payload of some other network protocol, for example via HTTP or SMTP (Simple Mail Transfer Protocol) or FTP (File Transfer Protocol) or TCP/IP (Transmission Control Protocol/Internet Protocol).SOAP provides the Messaging Protocol layer of a web services protocol stack for web services.
It is an XML-based protocol consisting of three parts:
An envelope, which defines the message structure and how to process it
A set of encoding rules for expressing instances of application-defined datatypes
A convention for representing procedure calls and responses.
SOAP has three major characteristics:
Extensibility (security and WS-Addressing are among the extensions under development)
Neutrality (SOAP can operate over any protocol such as HTTP, SMTP, TCP, UDP, or JMS)
Independence (SOAP allows for any programming model)
As an example of what SOAP procedures can do, an application can send a SOAP request to a server that has web services enabled with the parameters for a search. The server then returns a SOAP response. Since the generated data comes in a standardized machine-parsable format, the requesting application can then integrate it directly.
The SOAP architecture consists of several layers of specifications for:
message format
Message Exchange Patterns (MEP)
underlying transport protocol bindings
message processing models
protocol extensibility
SOAP evolved as a successor of XML-RPC, though it borrows its transport and interaction neutrality from Web Service Addressing and the envelope mainly from WDDX.
SOAP suggests the use of a specific message format in Extensible Markup Language (XML) and a message transport protocol such as Hypertext Transfer Protocol (HTTP). Using SOAP, different systems communicate with each other by passing text messages encoded as XML, that are then communicated over a transport protocol such as HTTP.
Station1 executes a command which creates an action on the associated application server. This command generates a process within the application and the result arrives in the application interface. The message is translated into XML format by the implementation and is then sent to the Web server. The XML parser checks the coherence of the XML document and sends the SOAP message via HTTP. The XML parser checks the validity of the message using the HTTP and XML headers and accepts or rejects it. The message is then routed to the relevant application server and translated by the implementation so that the task is meaningful for the application.
The SOAP application which receives the SOAP message must proceed as follows to translate the message:
Identify the parts of the SOAP message which correspond to the application
Check that all the mandatory parts of are supported by the application or discard the message
Remove all the parts before transferring he message if the application is not the endpoint
The application then executes the task. A result is produced. The return is done in the same way: implementation and then sending by HTTP. The result of the action may be different: display in a browser, actions, access to a database, and so.
Importance of SOAP attachments
A SOAP message may need to be transmitted together with attachments of various sorts, ranging from facsimile images of legal documents to engineering drawings. Such data are often in some binary format. For example, most images on the Internet are transmitted using either GIF or JPEG data formats. In this document we describe a standard way to associate a SOAP message with one or more attachments in their native format in a multipart MIME structure for transport. The specification combines specific usage of the Multipart/Related MIME media type (RFC 2387) and the URI schemes discussed in RFC 2111 and RFC2557 for referencing MIME parts.
The methods described here treat the multipart MIME structure as essentially a part of the transfer protocol binding, i.e., on par with the transfer protocol headers as far as the SOAP message is concerned. The multipart structure, though given a name (SOAP message package) is not an entity that can be unambiguously identified as such because there is no token explicitly expressing the intent to make it such an entity. A conscious choice in this document was to avoid adding a new entity type based on a recognizable token. The purpose of this document is to show how to use existing facilities in SOAP and standard MIME mechanisms to carry and reference attachments. In other words, we take a minimalist approach to show what is already possible with existing standards without inventing anything. More rigorous semantics for message packages requires a new entity type. Such a type can be built by extending the approach described here with a new SOAP header entry which, for instance, may be used to provide a manifest of the complete contents of the message package. Most Internet communication protocols are capable of transporting MIME encoded content, although some special considerations are required for HTTP.
different set of frameworks/libraries for SOAP web service development, in different
environments
While comparing SOAP with other commonly used distributed technologies one must keep in mind that SOAP is a protocol rather than a complete distributed architecture. This technology is still in its infancy and as a result most of the systems that implement this technology do not explore the full potential it has to offer. SOAP is compatible with most of the aspects of distributed computing, but the implementation of some of these aspects is outside the scope of a wire protocol. There are several considerations that go into selecting a distributed architecture. Some of the important ones are scalability, performance, state management, garbage collection and security. Table 1 shows how SOAP compares with the common distributed architectures based on these criteria.
Annotations in JAX-WS
JAX-WS (Java API for XML Web Services) is a java package/library for developing web services
It supports both Functional oriented and message-oriented communication via SOAP.JAX-WS API hides the complexity of SOAP from the application developer. AX-WS uses the javax.jws package. It uses annotations such as,
•@WebService
•@WebMethod
•@OneWay
•@WebParam
•@WebResult
How a web service can be tested using different approaches
A Web Service is a kind of Internet application framework based on SOAP and XML technology. Two significant attributes of Web Services are standards-based architecture and XML-based messaging. Web Service relies on a family of protocols to describe, deliver, and interact with each other, such as the Web Service Description Language (WSDL), the Universal Description, Discovery and Integration (UDDI) protocol or the Web Service Inspection Language (WSIL), and the Simple Object Access Protocol (SOAP). WSDL, UDDI, WSIL, and SOAP are all based on XML.Developers of a Web Service are not able to assume which type of clients will consume the Web Service, and vice versa, developers at the client sides are not aware of which language and platform are used at the server side. A Web Service and its clients can be developed in totally different programming languages and probably on
different platforms.
Web Services Testing Approaches
Web Services’ testing is different from traditional software testing. In addition, current testing process and tools do not work well for testing Web Services, and therefore, testing Web Services is difficult and poses many new challenges due to the above-mentioned reason and mainly because Web Services are distributed applications with numerous runtime behaviors. In a large application, multiple Web Services will be selected, invoked, and executed at runtime, and this feature makes Web Service testing even more challenging.
Web Services Testing Approaches
Regardless of where they come from, no one can ensure that the Web Services components will work as one might expect. Even those that are bought may not fit exactly to the task at hand. The fact that they are not compatible can lead to serious interaction errors. Therefore no matter where the Web Services come from, they should go through an independent testing process, not only individually, but also collectively. Recently, the research in the field of testing Web Services is increasing. Some of the approaches found in the literature are mainly focusing on developing automatic Web Services testing tool or test case generations. Others propose frameworks/ platforms to do stress and authorization tests. A large group focuses on test case generation based on the WSDL description of the Web Service. Some of the methods focus on black-box concepts, behavior testing, and others focus on white-box concepts, fault injection and fault coverage techniques.
The existing approaches can be found in four classes as
1- WSDL-Based Test Case Generation Approaches
2- Mutation-Based Test Case Generation Approaches
3- Test Modeling Approaches
4- XML-Based Approaches
Frameworks widely used in the Web Service testing.
SoapUI tool 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.
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. 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.
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.
References:
No comments:
Post a Comment