Web services and SOAP

➤Compare and contrast web applications with web services, indicating the need for web services




Web applications are defined by being interactive. You're supposed to use a web application in order to perform a function and use some of the web applications features. Lots of web applications don't even have real informative content or data exactly. People are just supposed to use them in order to perform additional tasks, using their features to accomplish something. You use a web application to check your incoming messages, for instance, or play a game.

The browser capabilities involved with web applications are significantly more high-tech, which is one reason why it's usually harder for people to design a web application than a website. Websites are all about getting more data, and web applications are all about doing things. One of your actions is probably going to be getting more information or learning more information, but the web application helped you perform that action. You got the information from a website.

The user interface of a web application is also usually much more complicated than the user interface of a website. Websites might have tags and categories that you need to understand, but you don't have to go through and learn any potentially complicated tasks in order to use websites. Web applications often require step-by-step guides, or you're not going to be able to complete them.

The setup of websites are completely different from web applications in most cases. The rhythm of typing in the address, loading websites, and going back and forth between websites is often absent with web applications.

Web applications, unsurprisingly, are usually harder to design and create than websites. Lots of people have their own websites today, and this was the case even ten years ago. The people who are able to create their own web applications can more easily make money off of them because it takes more work to learn how to code and create a web application.

Web Services

Web service is a technology by which two or more remote web applications interact with each other over network/internet. It can be implemented using Java, .net, PHP etc. Web pages allow people to communicate and collaborate with each other while web services allow programs to communicate and collaborate with each other.

A web service is essentially a collection of open protocols and standards used for exchanging data between applications or systems. Software applications written in various programming languages and running on various platforms can use web services to exchange data over computer networks like the Internet in a manner similar to inter-process communication on a single computer. This interoperability (e.g., between Java and Python, or Windows and Linux applications) is due to the use of open standards (XML, SOAP, HTTP).

All the standard Web Services works using following components:

• SOAP (Simple Object Access Protocol)
• UDDI (Universal Description, Discovery and Integration)
• WSDL (Web Services Description Language)

It works somewhat like this:

• The client program bundles the account registration information into a SOAP message.
• This SOAP message is sent to the Web Service as the body of an HTTP POST request.
• The Web Service unpacks the SOAP request and converts it into a command that the application can understand.
• The application processes the information as required and responds with a new unique account number for that customer.
• Next, the Web Service packages up the response into another SOAP message, which it sends back to the client program in response to its HTTP request.
• The client program unpacks the SOAP message to obtain the results of the account registration process.

➤Discuss what WSDL is and the use of it in the context of web services 

Definitions are generally expressed in XML and include both data type definitions and message definitions that use the data type definitions. These definitions are usually based upon some agreed upon XML vocabulary. This agreement could be within an organization or between organizations. Vocabularies within an organization could be designed specifically for that organization. They may or may not be based on some industry-wide vocabulary. If data type and message definitions need to be used between organizations, then most likely an industry-wide vocabulary will be used. For more on XML vocabularies, 

XML, however, is not necessary required for definitions. The OMG Interface Definition Language (IDL), for example, could be used instead of XML. If a different definitional format were used, senders and receivers would need to agree on the format as well as the vocabulary. Nevertheless, over time, XML-based vocabularies and messages are likely to dominate. XML Namespaces are used to ensure uniqueness of the XML element names in the definitions, operations, and service bindings.

Operations describe actions for the messages supported by a Web service. There are four types of operations:

• One-way: Messages sent without a reply required
• Request/response: The sender sends a message and the received sends a reply.
• Solicit response: A request for a response. (The specific definition for this action is pending.)
• Notification: Messages sent to multiple receivers. (The specific definition for this action is pending.)

Operations are grouped into port types. Port types define a set of operations supported by the Web service.

Service bindings connect port types to a port. A port is defined by associating a network address with a port type. A collection of ports defines a service. This binding is commonly created using SOAP, but other forms may be used. These other forms could include CORBA Internet Inter-ORB Protocol (IIOP), DCOM, .NET, Java Message Service (JMS), or WebSphere MQ to name a few.

The following figure shows the relationship of the basic parts of WSDL:

➤Explain the fundamental properties of a WSDL document and the use of WSDL document in web services and client development  

WSDL , breaks down web services into three specific, identifiable elements that can be combined or reused once defined.

The three major elements of WSDL that can be defined separately are −

• Types
• Operations
• Binding

A WSDL document has various elements, but they are contained within these three main elements, which can be developed as separate documents and then they can be combined or reused to form complete WSDL files.

WSDL Elements

A WSDL document contains the following elements −

• Definition − It is the root element of all WSDL documents. It defines the name of the web service, declares multiple namespaces used throughout the remainder of the document, and contains all the service elements described here.
• Data types − The data types to be used in the messages are in the form of XML schemas.
• Message − It is an abstract definition of the data, in the form of a message presented either as an entire document or as arguments to be mapped to a method invocation.
• 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 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.
• Binding − It is the concrete protocol and data formats for the operations and messages defined for a particular port type.
• Port − It is a combination of a binding and a network address, providing the target address of the service communication.
• Service − It is a collection of related end-points encompassing the service definitions in the file; the services map the binding to the port and include any extensibility definitions.

In addition to these major elements, the WSDL specification also defines the following utility elements −

• Documentation − This element is used to provide human-readable documentation and can be included inside any other WSDL element.
• Import − This element is used to import other WSDL documents or XML Schemas.

➤Discuss the structure of the WSDL document, explaining the elements in WSDL

You may have seen my previous post on SOAP vs. REST call. Now a day companies are moving to REST service calls but still there are majority of companies still uses SOAP over REST. This tutorial explains basic of WSDL (Web Service Description Language).

If you have any of below question then you are at right place:

• What is Web Services Description Language (WSDL)?
• WSDL Tutorial
• Web Services Description Language (WSDL) Explained
• Examples of WSDL – Web Service Description Language

Web Services Description Language (WSDL)

In Java Web Development World, WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate, however, the only bindings described in this document describe how to use WSDL in conjunction with SOAP 1.1,HTTP GET/POST, and MIME.

In other words: 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 TYPE 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.
• OPERATIONS– 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.
• PORTS– a single endpoint defined as a combination of a binding and a network address.
• SERVICE– a collection of related endpoints.

➤Explain how SOAP is used with HTTP   

SOAP , is a message protocol that allows distributed elements of an application to communicate. SOAP can be carried over a variety of lower-level protocols, including the web-related Hypertext Transfer Protocol (HTTP).  SOAP defines a header structure that identifies the actions that various SOAP nodes are expected to take on the message, in addition to a payload structure for carrying information. The concept of routing a message through a string of nodes that perform different functions is how SOAP supports things like addressing, security and format-independence. Essentially, the headers identify roles, which in turn provide the SOA features which SOAP then routes to. Stringing messages through a sequence of steps is uncommon in today’s microservice-centric development environments.

SOAP Advantages and Disadvantages

SOAP is an integral part of the service-oriented architecture (SOA) and the Web services specifications associated with SOA. Because it allows the sender to create a message route based on the logical services that have to be applied to the message on the way to its destination, it lends itself to providing secure and compliant connections, controlling access, offering reliable delivery and failure recovery, and supporting dynamic service discovery. SOA without SOAP is difficult to imagine.

SOAP’s messages are defined at a high level in XML, but most SOAP applications use Web Services Definition Language (WSDL), which is authored in XML.  The XML structure of SOAP makes it handy for applications that expect their information to be provided in XML form, and the fact that SOAP can ride on a variety of network protocols, including HTTP, means it’s easily passed through firewalls, where other protocols might require special accommodation.

The data structure of SOAP is based on XML, which is similar in many ways to the HTML used to define web pages. Like HTML, XLM is largely human-readable, which makes it fairly easy to understand a SOAP message, but also makes the messages relatively large in comparison to the Common Object Request Broker Architecture (CORBA) and its Remote Procedure Call (RPC) protocol that will accommodate binary data.

The biggest disadvantage of SOAP (and SOA overall) is that it’s a heavyweight protocol for a heavyweight architecture.  The notion of a message passing through a string of nodes to be processed by each seems to mix protocols and service bus architectural models for software, and neither of those two are considered optimal for microservice-based development as popularly used today.

SOAP APIs

SOAP is a protocol that’s almost always used in the context of a Web Services/SOA framework.  As such, it’s application programming interface (API) is typically hidden by the higher-level interface for SOA. There are SOA API middleware tools available for nearly all modern programming languages, and Microsoft offers a variety of .NET SOAP/SOA tools.

SOAP vs REST

SOAP is designed to break traditional monolithic applications down into a multi-component, distributed form without losing security and control. In contrast, REST is a model of distributed computing interaction based on the HTTP protocol and the way that web servers support clients. REST over HTTP is almost always the basis for modern microservices development and communications. RESTful APIs uses HTTP requests to GET, PUT, POST and DELETE data.

REST/HTTP is simple, flexible, lightweight, and offers little beyond a way of exchanging information. SOAP can ride on HTTP as well, but it connects the elements of a complex set of distributed computing tools (the Web Services and SOA framework) as well as application components, and this forms a part of a total service-oriented framework.

Future of Simple Object Access Protocol

SOAP was the first widely used protocol for connecting web services in a Service Oriented Architecture (SOA). Today, nearly all modern development of distributed applications is based on RESTful principles. SOAP is almost always confined to legacy applications and projects, and over time its use is declining.

➤Explain the structure of SOAP message in message oriented communication, indicating the elements used.

SOAP Message Structure

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.

As discussed in the previous topic, a simple SOAP Message has the following elements –

• The Envelope element
• The header element and
• The body element
• The Fault element (Optional)

Let's look at an example below of a simple SOAP message and see what element actually does.

1. As seen from the above SOAP message, the first part of the SOAP message is the envelope element which is used to encapsulate the entire SOAP message.
2. The next element is the SOAP body which contains the details of the actual message.
3. Our message contains a web service which has the name of "Guru99WebService".
4. The "Guru99Webservice" accepts a parameter of the type 'int' and has the name of TutorialID.

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.

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

➤Discuss the importance of the SOAP attachments, explaining the MIME header 

Multipurpose Internet Mail Extensions (MIME) headers appear at the beginning of a MIME message as well as within the separate body parts. Some MIME headers can be used both as message headers and in MIME body parts. Some additional headers are defined for use only in body parts.

The following headers are defined in MIME:

• MIME-Version
• Content-Type
• Content-Transfer-Encoding
• Content-ID
• Content-Description
• Content-Disposition

There are additional headers that are applied in specialized situations, such as Content-Base and Content-Location. All of the "Content-xxx" headers have defined sub-headers, fields, and/or parameters. Headers that begin with "Content-" are the only headers that have defined meaning in body parts. All other body part headers can be ignored and might actually be removed by message transfer agents (MTAs).

MIME-Version is a required header indicating that this message is to use the rules of MIME. "MIME-Version: 1.0" is the only currently defined MIME-Version header allowed. The MIME-Version header is a top-level header only and does not appear in body parts unless the body part is an encapsulated, fully formed message of content-type message/RFC 822, which might have its own MIME-Version header.

Content-Type headers are used to specify the media type and subtype of data in the body of a message and to fully specify the native representation of such data. This header embodies much of the power of MIME. The IETF can add new official content types. Additionally, private content-type values can be defined by anyone. Such private content types have values of "x-something" or "X-something", where "something" can take on any value.

Content-Transfer-Encoding headers can have two different meanings. If the value is "base64" or "quoted-printable", then the header indicates the encoding used for this body part. If the value is "7bit", "8bit", or "binary", then the header indicates that there is no encoding and that this value indicates only the type of content this body part contains. The default is "7bit". It should be noted that "8bit" and "binary" cannot be assured of being handled by all Internet (SMTP) MTAs, and are not actually valid in Internet mail. Provision is made for private Content-Transfer-Encoding headers. These have values that begin with "x-" or "X-". These are for specialized cases where the users have the tools to decode or otherwise process a specific "x-" encoding.

Content-ID headers are world-unique values that identify body parts, individually or as groups. They are necessary at times to distinguish body parts and allow cross-referencing between body parts.

Content-Description headers are optional and are often used to add descriptive text to non-textual body parts.

Content-Disposition headers provide information about how to present a message or a body part. When a body part is to be treated as an attached file, the Content-Disposition header will include a file name parameter.

SOAP Messages and MIME Headers

When a SOAP message is wrapped for transmission in HTTP (or another protocol, such as SMTP), suitable MIME headers must be created. At minimum, the wrapper must include the Content-Type and Content-Lengthheaders along with the SOAPAction header. Similarly, when a message is received, any MIME headers that accompany it must be extracted from the protocol-specific wrapper and be made part of the created SOAPMessage. The MIME headers associated with a SOAPMessage are held in an object of typejavax.xml.soap.MimeHeaders .

In terms of the structure of an encapsulated SOAP message, the MIME headers logically appear outside the envelope, where they form the protocol-specific wrapper. In the case of a SOAP message with attachments, in addition to the headers in the outer wrapper, the SOAP message part and each of the attachment parts have their own collection of MIME headers that are distinct from those of the wrapper

 

➤Explain the annotations in JAX-WS, 




Java 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 portType, 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.

For JAX-WS web services, the use of the webservices.xml deployment descriptor is optional because you can use annotations to specify all of the information that is contained within the deployment descriptor file. You can use the deployment descriptor file to augment or override existing JAX-WS annotations. Any information that you define in the webservices.xml deployment descriptor overrides any corresponding information that is specified by annotations.

Starting with WebSphere® Application Server Version 7.0 and later, Java EE 5 application modules (Web application modules version 2.5 or later, or EJB modules version 3.0 or later) are scanned for annotations to identify JAX-WS services and clients. However, pre-Java EE 5 application modules (web application modules version 2.4 or before, or EJB modules version 2.1 or before) are not scanned for JAX-WS annotations, by default, for performance considerations.

In the Version 6.1 Feature Pack for Web Services, the default behavior is to scan pre- Java Platform, Enterprise Edition (Java EE) 5 web application modules to identify JAX-WS services and to scan pre-Java EE 5 web application modules and EJB modules for service clients during application installation. Because the default behavior for WebSphere Application Server Version 7.0 and later is to not scan pre-Java EE 5 modules for annotations during application installation or server startup, to preserve backward compatability with the feature pack from previous releases, you must configure one of the following properties:

• You can set the UseWSFEP61ScanPolicy property in the META-INF/MANIFEST.MF of a WAR file or EJB module to true. For example:

  Manifest-Version: 1.0
  UseWSFEP61ScanPolicy: true

  When this property is set to true in the META-INF/MANIFEST.MF file of the module, the module is scanned for JAX-WS annotations regardless of the Java EE version of the module. The default value is false and when the default value is in effect, JAX-WS annotations are only supported in modules whose version is Java EE 5 or later.
• You can set the com.ibm.websphere.webservices.UseWSFEP61ScanPolicy custom Java virtual machine (JVM) property using the administrative console. See the JVM custom properties documentation for the correct navigation path to use. To request annotation scanning in all modules regardless of their Java EE version, set the custom property com.ibm.websphere.webservices.UseWSFEP61ScanPolicy to true. You must change the setting on each server that requires a change in the default behavior.

If the property is set within the META-INF/MANIFEST.MF file of the module, this setting takes precedence over the server's custom JVM property. When using either property, you must establish the desired annotation scanning behavior before the application is installed. You cannot dynamically change the scanning behavior once an application is installed. If changes to the behavior are required after your application is installed, you must first uninstall the application, specify the desired scanning behavior using the appropriate property and then install the application again. When federating nodes that have the com.ibm.websphere.webservices.UseWSFEP61ScanPolicy set to true in the configuration of the servers contained within the node, this property does not affect the deployment manager. You must set the property to true on the deployment manager before the node is federated to preserve the behavior as it was on the node before federation.

Annotations supported by JAX-WS are listed in the following table. The target for annotations is applicable for these Java objects:

1. types such as a Java class, enum or interface
2. methods
3. fields representing local instance variables within a Java class
4. parameters within a Java method

➤Discuss how a web service can be tested using different approaches



Web Services Testing is testing of Web services and its Protocols like SOAP & REST. To test a Webservice you can

1. Test Manually
2. Create your own Automation Code
3. Use an off-the shelf automation tool like SoapUI.

WebService Testing involves following steps -

1. Understand the WSDL file
2. Determine the operations that particular web service provides
3. Determine the XML request format which we need to send
4. Determine the response XML format
5. Using a tool or writing code to send request and validate the response

Suppose we want to test a WebService which provides Currency Conversion Facility. It will the current conversion rates between the different countries currency. This service we can use in our applications to convert the values from one currency to the other currency.

Using a tool or writing code to send request and validate the response

There are lots of tools available to test web services. SoapUI is one of the popular tool which will help us to test the web services. In fact you can use the any programing language which is capable of sending the XML request to the web service provider application over the http and able to parse and validate the response XML against the expected result. In our case, we will test the WebService

1. Using Java
2. Using SoapUI

WebService Testing Using Apache Axis2 API (Java).

Generally web service takes the request and sends the response in the XML format.

Apache Axis2 API project is a Java implementation API, which will be used to create the Web services for both server side (service provider) and client side (service consumer).

Axis2 is capable of sending SOAP messages and Receives & Processes the SOAP messages. We can write a small Java program using the API to create the web service. Axis2 will generate the WSDL from Java program which will be used to communicate the services offered by the web service. We can use the same Axis2 to generate the Java class (stub) from WSDL file which we can use as a client program to generate the web service request, to send the request to the service end point and to process the response.

1. Basically we will create a simple Java program in which we will instantiate the stub class.
2. Using the stub we will invoke the request method by passing all the required information.
3. Stub program will convert that request into XML request format and sends it the service end point which will read the request and processes the request and sends the response in XML format.
4. The XML response will be converted into Java class by stub and returned to the actual program

REFERENCES


https://www.service-architecture.com/articles/web-services/web_services_description_language_wsdl.html

https://www.tutorialspoint.com/wsdl/wsdl_elements.htm

https://crunchify.com/basic-wsdl-structure-understanding-wsdl-explained/

https://searchmicroservices.techtarget.com/definition/SOAP-Simple-Object-Access-Protocol

https://www.guru99.com/soap-simple-object-access-protocol.html

https://docs.microsoft.com/en-us/previous-versions/office/developer/exchange-server-2010/aa563068(v=exchg.140)

https://www.oreilly.com/library/view/java-web-services/0596003994/ch03s05.html

https://www.ibm.com/support/knowledgecenter/en/SS7JFU_8.5.5/com.ibm.websphere.express.doc/ae/rwbs_jaxwsannotations.html

https://www.guru99.com/webservice-testing-beginner-guide.html