SERVER-SIDE DEVELOPMENT 1 SOAP

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

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.

• Every SOAP message needs to have a root Envelope element. It is absolutely mandatory for a SOAP message to have an envelope element.
• Every Envelope element needs to have at least one soap body element.
• If an Envelope element contains a header element, it must contain no more than one, and it must appear as the first child of the Envelope, before the body element.
• The envelope changes when SOAP versions change.
• A v1.1-compliant SOAP processor generates a fault upon receiving a message containing the v1.2 envelope namespace.
• A v1.2-compliant SOAP processor generates a Version Mismatch fault if it receives a message that does not include the v1.2 envelope namespace.

• SOAP-ENV: VersionMismatch – This is when an invalid namespace for the SOAP Envelope element is encountered.
• SOAP-ENV: MustUnderstand - An immediate child element of the Header element, with the mustUnderstand attribute set to "1", was not understood.
• SOAP-ENV: Client - The message was incorrectly formed or contained incorrect information.
• SOAP-ENV: Server - There was a problem with the server so the message could not proceed.

• Organizations are being challenged to partner with other organizations in order to respond more rapidly to new business opportunities, increase the efficiency of business processes, and reduce the time to market for their products. To address these issues, they're typically required to develop interoperability between disparate, legacy applications to support collaborative business processes.

• This is accomplished by coordinating the exchange of business documents between applications in a predefined manner. For example, two insurance companies with different systems may need to exchange auto insurance claim data, such as a TIFF file for claims processing.

• Enterprise applications that support these types of requirements are known as business services. Supporting business services through Web applications, commonly known as Web services, requires a careful evaluation of available technologies. An important underlying technology of Web services is Simple Object Access Protocol. SOAP enables applications to communicate with each other in a platform, language, and operating system-independent manner.

• For those who need to use a Web service to perform a functionality such as sending a document in the form of attachments (e.g., a TIFF file) from one application to another using SOAP, a pertinent specification is the SOAP Messages with Attachments note. This article discusses this emerging W3C note and illustrates how it can be used with the Apache SOAP implementation.

• As you know, SOAP is a simple, lightweight XML-based distributed computing protocol. The SOAP 1.1 specification essentially comprises three parts:

• A SOAP message is an XML document that comprises a SOAP envelope. Within the envelope are an optional SOAP header and a mandatory SOAP body. The SOAP message header represents the metadata of the message and provides a way to extend SOAP. The SOAP message body is the actual message payload. The details of a remote procedure call including the arguments are described in the envelope that is transported from one application to another over a selected protocol (e.g., HTTP). HTTP provides a firewall-friendly application-level protocol for communication between heterogeneous applications. The SOAP Messages with Attachments specification builds on SOAP 1.1.

• Before we discuss this specification, we should briefly consider the concept of a Multipurpose Internet Mail Extensions multipart. MIME is leveraged in the SOAP with Attachments specification as well as in other related Web services specifications such as WSDL (Web Services Description Language). Typically, e-mail messages with attachments are sent over the Internet using Simple Mail Transfer Protocol and MIME. SMTP is limited to 7-bit ASCII text with a maximum line length of a thousand characters which results in the inability to send attachments. MIME addresses these limitations by specifying message header fields and allowing different related objects such as attachments to be included in the message body in the form of a MIME multipart.

• For example, if the message body contains multiple independent objects of possibly different data types, the message body is divided into parts by boundaries. To indicate that the message body comprises a multipart structure of independent attachments, a Content-Type message header field is set. The message body boundary is defined with a parameter in the Content-Type field as shown below:

• The Content-Type header can also be used to identify a Multipart structure with related MIME parts. RFC 2387 specifies the Multipart/Related Content-Type to provide a mechanism for representing an object that consists of related MIME body parts. As you'll see, the Multipart/Related Content-Type allows a SOAP message to reference attachments such as audio and image files.

• Armed with this basic knowledge of SOAP and MIME, let's discuss the concept of SOAP messages with attachments. Let's assume we use the MIME specifications to support SOAP messages with attachments and we package a SOAP 1.1 message as a part of a MIME multipart structure. Further, let's assume we provide a way for that SOAP 1.1 message to refer to attachments that are represented as other parts of that MIME multipart. In a nutshell, this is the approach described in the SOAP Messages with Attachments technical note.

• This note specifies how to package a SOAP 1.1 message with attachments using existing MIME specifications. A SOAP Message Package, which is a central concept in this specification, consists of a SOAP 1.1 message that can reference attachments and any related attachments. A SOAP message package is built using the Multipart/Related Content-Type. The primary SOAP 1.1 message must be included in the root body part of the Multipart/Related container. Thus the type header of the Multipart container and the Content-Type header of the root body part will be the same (i.e., text/XML). The attachments in the Multipart container must be composed of a Content-ID MIME header or a Content-Location MIME header.

• For the SOAP message to reference attachments in the MIME container, the SOAP 1.1 encoding rules are used. In the specification, a URI that is a value of an HREF attribute can be used to refer to a resource. Since each attachment in the MIME container has a URI reference in its Content-Location or Content-ID header, it's possible for the attachments to be referred to using the HREF attribute from the SOAP 1.1 message. To refer to an attachment with a specific Content-ID header value, the Content-ID Uniform Resource Locator scheme, "cid," is used, as defined in RFC 2111. So, for example, to refer to a MIME part (GIF image) with a Content-ID of 286.apache-soap.MYHOST, an HREF value of "cid:286.apache-soap. MYHOST" is used. An illustration of a SOAP message package with an image attachment constructed using a MIME multipart is shown in Figure 1.

• The Apache Software Foundation (www.apache.org) provides an implementation of SOAP including support for SOAP Messages with Attachments. I've chosen to discuss the Apache implementation because it's freely available. Apache SOAP version 2.2, which can be downloaded from the Apache Web site, requires a number of components, such as a servlet container (e.g., Apache Tomcat), JavaMail, JavaBeans Activation Framework, and a JAXP-compatible XML parser. As you know, JavaMail is a J2EE API that provides a platform and protocol-independent interface for sending and retrieving e-mail messages. It interacts with the message content through another layer in the form of the JavaBeans Activation Framework. JAF provides a uniform way of determining the type of a message's content and encapsulating access to it. You can obtain more information on JavaMail and JAF from the Resources section.

• Here's a quick overview of how a simple Web service can be constructed with Apache SOAP and Java. The first step is to define and implement a Web service. When developing a simple Java application to support a Web service using SOAP, you'll notice that there's no SOAP-specific code in your Java class because Apache SOAP manages the details pertaining to SOAP. After implementing the service, you deploy the service describing the operation(s) that it supports and assign the service a unique service ID. When a SOAP client uses the service by calling one of its operations, the Apache SOAP RPC router servlet responds to the request. The request is routed to the pertinent Java object that supports the Web service. The service object interfaces with the core business logic to perform the business function and a response is returned to the client.

• After deploying a Web service, you could create a Java client that calls the Web service. The client program uses a Call object to specify values such as the service ID, method name, and parameters of the method such as attachments. The invoke() operation of the Call object requires the URI of the rpc router servlet and returns a Response object. The response is also a SOAP message. If an error occurs during the invocation of the method, a Fault object can be returned within the SOAP message body. The Fault object includes a code and a description of the error.

• The SOAPMappingRegistry class handles the marshaling and unmarshaling of data types and comes with preregistered serializers and deserializers such as the MimePartSerializer class. This and other classes and interfaces you might encounter using the Apache SOAP Messages with Attachments implementation are summarized in Table 1.

• To provide a simple, concrete illustration of the previous discussion, let's assume we have a subscriber who uses systems provided by messaging system vendors A and B. Suppose, using A's system, a subscriber needs to change his/her voicemail greeting on B's system. This need can be met by a Web service using SOAP provided by vendor B. So, vendor A develops a Web application that accesses vendor B's Web service using SOAP to change the voicemail greeting of a subscriber.

• To support this scenario, two simple Java programs will be used to illustrate the SOAP RPC approach rather than the message-based approach. The first program will implement the Web service; the second will be a test client to call the service. The class to support the Web service consists of one operation, changeGreeting(), with two parameters - a subscriber ID and a voice greeting in the form of a WAV file attachment. The attachment is obtained using a DataHandler object and written to disk for this example. Vendor B's existing business objects could then use this audio file to actually change the greeting. Notice how the Web service can simply provide a coarse-grained service-based interface that shields the calling application from an organization's existing business-logic-layer implementation (Java classes, CORBA objects, EJBs) that is reused to support the Web service. A code snippet of the class that implements this Web service is given in Listing 1.

• To deploy the code, a deployment descriptor is needed to specify the URN of the SOAP service ("urn:soapattachtest") and operations (changeGreeting) that SOAP clients can use. The Java class (GreetingService) that supports the Web service is also specified in the deployment descriptor provided in Listing 2.

• The other program involved in this example is a client program that calls the Web service. In this SOAP client, a Call object is created and initialized with the serviceID and the name of the operation (changeGreeting), both of which must match the values in the deployment descriptor. The Call object is also initialized with two parameters needed for the changeGreeting() operation - the subscriber ID and a voice greeting attachment file. After the Call object is initialized, the URL representing the rcprouter servlet is passed into its invoke() operation to call the Web service and send the attachment. Listing 3 gives a code snippet of this class. The code listings shown can be deployed on Apache Tomcat and SOAP 2.2.

• The Apache SOAP implementation also includes a useful utility called TcpTunnelGui that allows you to "sniff" SOAP messages exchanged between a SOAP client and a SOAP server. For example, assuming you're using Apache Tomcat, a SOAP client can connect to port 8070 to send SOAP requests that are then routed to port 8080 (Apache Tomcat's default port) on your Web server's host. As you can see in Figure 2, this tool is helpful for learning about the contents of SOAP requests and responses as they pertain to the SOAP Messages with Attachments specification.

• Over the last few years, the popularity and usage of web services or APIs have increased. Web services or APIs are a collection of procedures or software components that help an application to interact or perform some process/transaction by forming a connection between other application or server. There are basically two types of web service – REST and SOAP to drive the communication of data and information over internet protocol.

• Since these web services are exposed to the web and distributed over different networks, they are vulnerable to risks and security threats which affect the processes based on them. Hence, testing of web services or APIs becomes necessary to ensure they perform rightly and respond correctly to the queries.

• There are several commercial and open source testing tools in the market to test their connectivity, response, and performance. These testing tools automate testing for a specific scenario such as functional testing, load testing, performance testing, etc. Below tools are not in any specific order.

• Provides printable, exportable, and HTML-based reports at Project, TestSuite, TestCase, or LoadTest level.
• Comes integrated with Hudson, Bamboo, Maven, ANT, and JUnit.
• Allows developing own set of features as SoapUI Plugins.
• Records, monitors, and displays all the data.
• Supports WS-Security and SSL decryption.

• Supports String comparison to validate the API response.
• Helps log API defects through integrated bug tracking tools like JIRA, Mantis, and FogBugz.
• Generates visual logs and reports of test execution with an emailing facility.
• Allows distributed and parallel execution across multiple machines and nodes.
• Provide Continuous Integration with Jenkins, Bamboo & Hudson.
• Supports data-driven and keyword-driven testing.

• Supports vulnerability tests with XSD-mutation.
• Provides comprehensive WSDL and Schema parsing.
• Performs load testing with behavior modeling and multiple simultaneous loading transactions.
• Provides reports in XML, DOC, XLS, PDF, RTF, and RPT formats.
• Integrates with HP Quality Center.

• Provides end-to-end testing
• Supports 120+ protocols/message types.
• Comes with an easy-to-use interface.
• Helps create sophisticated, extensible and reusable tests without coding.
• Supports continuous integration testing.

• Uses command-line prompt for functional, load and performance testing.
• Features an intuitive look and feel with a standard multi-windowed IDE.
• Provides a monitoring dashboard to run tests and display live results.
• Allows accessing all Java libraries and classes due to Jython language.

• Allows collecting and organizing APIs in a feature called Postman Collections.
• Facilitates collaboration and sharing of API data and controls with the team.
• Comes with pasting text feature for hassle-free test creation on command line window.
• Allows writing Boolean tests within Postman Interface.

• Comes with a mock server functionality to create API mock within minutes.
• Provides a Chrome extension to record and playtest cases.
• Supports integration with Jenkins for continuous server integration and Jira for bug tracking.
• Facilitates roles and permissions management.
• Allows exporting and importing test cases and reports from external tools such as Postman Collections, Swagger 2, and more

• Comes with an easy-to-use and elegant user interface that doesn’t require advanced technical skills.
• Uses HTTP methods such as GET, POST, DELETE etc.
• Provides different validation types and expressions to ease testing.
• Utilizes command-line interface for test creation and execution
• Allows storing all information – API calls and project data at a single place.

• Allows creating tests with dynamic data for even complex cases.
• Displays visually-rich metrics and analytics to identify problems.
• Integrates with tools like HipChat, Webhooks, Slack, and PagerDuty to notify when the APIs are down.
• Allows reusing and executing tests across multiple locations.
• Facilitates managing tests centrally for better team collaboration.

• Uses HTTP standard methods such as POST, GET, PUT, and DELETE.
• Allows storing prototyped requests against a specific web service.
• Contains built-in REST definition builder and object library.
• Comes with powerful, integrated reporting capabilities.
• Supports cross-browser testing and parallel execution.

• Provides real-time results display.
• Monitors system response time.
• Supports different usage – as a complete test framework and as a standalone test runner.
• Generates reports in HTML and XML formats.
• Allows integration with other systems as a plugin for external monitoring.

• Allows testing multiple web services from a single UI.
• Helps edit raw SOAP requests.
• Allows invoking web service methods that contain complex data types.
• Supports testing of WCF apps.

 @WebMethod

 @WebResult

 @WebServiceClient

 @RequestWrapper

@Oneway

The directory structure of this example

• Create a Dynamic web project
• create a servlet
• add servlet-api.jar file
• Run the servlet

 Configure tomcat server in Eclipse

 JAR Files

WAR Files

Difference Between JAR and WAR Files

Definition

Long Form

File Extension

Consist of

Usage

Tomcat starts but Home Page does NOT open on the browser with URL http://localhost:8080