tute 5

Compare and contrast web applications with web services

Web Applications

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

WDSL(Web Services Description language)

 

The Web Services Description Language (WSDL /ˈwɪz dəl/) is an XML-based interface description language that is used for describing the functionality offered by a web service. The acronym is also used for any specific WSDL description of a web service (also referred to as a WSDL file), which provides a machine-readable description of how the service can be called, what parameters it expects, and what data structures it returns. Therefore, its purpose is roughly similar to that of a type signature in a programming language.

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 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 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.^[1] 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 services, and is much simpler to implement.^[2][3] 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 (BPEL) only supports WSDL 1.1.

Fundamental properties of a WSDL document

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.

These elements are described in detail in Section 2. 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) [11] 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 1.1
• 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.

PortType element

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.

SOAP (Simple Object Access Protocol)

SOAP (abbreviation for Simple Object Access Protocol) is a messaging protocol specification for exchanging structured information in the implementation of web services in computer networks. Its purpose is to provide extensibility, neutrality and independence. It uses XML Information Set for its message format, and relies on application layer protocols, most often Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.

SOAP allows processes running on disparate operating systems (such as Windows and Linux) to communicate using Extensible Markup Language (XML). Since Web protocols like HTTP are installed and running on all operating systems, SOAP allows clients to invoke web services and receive responses independent of language and platforms.

SOAP is a messaging protocol and in a nutshell is just another XML language. ...SOAP messages are usually exchanged via HTTP. Although it is possible to useother (application) protocols, e.g. SMTP or FTP, the non-HTTP bindings are not specified by SOAP specs and are not supported by WS-BP (interoperability spec).

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^[1] 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:

1.   extensibility (security and WS-Addressing are among the extensions under development)

2.   neutrality (SOAP can operate over any protocol such as HTTP, SMTP, TCP, UDP, or JMS)

3.   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—such as a real-estate price database—with the parameters for a search. The server then returns a SOAP response (an XML-formatted document with the resulting data), e.g., prices, location, features. 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^[2] and the envelope/header/body from elsewhere (probably from WDDX).

SOAP specification can be broadly defined to be consisting of the following 3 conceptual components: protocol concepts, encapsulation concepts and network concepts.^[12]

Protocol concepts

·         SOAP: The set of rules formalizing and governing the format and processing rules for information exchanged between a SOAP sender and a SOAP receiver.

·         SOAP nodes: These are physical/logical machines with processing units which are used to transmit/forward, receive and process SOAP messages. These are analogous to Node networking

·         SOAP roles: Over the path of a SOAP message, all nodes assume a specific role. The role of the node defines the action that the node performs on the message it receives. For example, a role "none" means that no node will process the SOAP header in any way and simply transmit the message along its path.

·         SOAP protocol binding : A SOAP message needs to work in conjunction with other protocols to be transferred over a network. For example, a SOAP message could use TCPas a lower layer protocol to transfer messages. These bindings are defined in the SOAP protocol binding framework

·         SOAP features: SOAP provides a messaging framework only. However, it can be extended to add features such as reliability, security etc. There are rules to be followed when adding features to the SOAP framework.

·         SOAP module : A collection of specifications regarding the semantics of SOAP header to describe any new features being extended upon SOAP. A module needs to realize zero or more features. SOAP requires modules to adhere to prescribed rules.^[14]

Data encapsulation concepts

SOAP message: Represents the information being exchanged between 2 SOAP nodes.

·         SOAP envelope : As per its name, it is the enclosing element of an XML message identifying it as a SOAP message.

·         SOAP header block: A SOAP header can contain more than one of these blocks, each being a discrete computational block within the header. In general, the SOAP roleinformation is used to target nodes on the path. A header block is said to be targeted at a SOAP node if the SOAP role for the header block is the name of a role in which the SOAP node operates. (ex: A SOAP header block with role attribute as ultimateReceiver is targeted only at the destination node which has this role. A header with a role attribute as next is targeted at each intermediary as well as the destination node.)

·         SOAP header : A collection of one or more header blocks targeted at each SOAP receiver.

·         SOAP body : Contains the body of the message intended for the SOAP receiver. The interpretation and processing of SOAP body is defined by header blocks.

·         SOAP fault: In case a SOAP node fails to process a SOAP message, it adds the fault information to the SOAP fault element. This element is contained within the SOAP body as a child element.

Message sender and receiver concepts

·         SOAP sender: The node that transmits a SOAP message.

·         SOAP receiver : The node receiving a SOAP message. (Could be an intermediary or the destination node.)

·         SOAP message path : The path consisting of all the nodes that the SOAP message traversed to reach the destination node.

·         Initial SOAP sender: This is the node which originated the SOAP message to be transmitted. This is the root of the SOAP message path.

·         SOAP intermediary: All the nodes in between the SOAP originator and the intended SOAP destination. It processes the SOAP header blocks targeted at it and acts to forward a SOAP message towards an ultimate SOAP receiver.

·         Ultimate SOAP receiver: The destination receiver of the SOAP message. This node is responsible for processing the message body and any header blocks targeted at it .

Specification

SOAP structure

The SOAP specification defines the messaging framework, which consists of:

·         The SOAP processing model defining the rules for processing a SOAP message

·         The SOAP extensibility model defining the concepts of SOAP features and SOAP modules

·         The SOAP underlying protocol binding framework describing the rules for defining a binding to an underlying protocol that can be used for exchanging SOAP messages between SOAP nodes

·         The SOAP message construct defining the structure of a SOAP message

SOAP building blocks

A SOAP message is an ordinary XML document containing the following elements:

Element	Description	Required
Envelope	Identifies the XML document as a SOAP message.	Yes
Header	Contains header information.	No
Body	Contains call, and response information.	Yes
Fault	Provides information about errors that occurred while processing the message.	No

Transport methods

Both SMTP and HTTP are valid application layer protocols used as transport for SOAP, but HTTP has gained wider acceptance as it works well with today's internet infrastructure; specifically, HTTP works well with network firewalls. SOAP may also be used over HTTPS (which is the same protocol as HTTP at the application level, but uses an encrypted transport protocol underneath) with either simple or mutual authentication; this is the advocated WS-I method to provide web service security as stated in the WS-I Basic Profile 1.1.

This is a major advantage over other distributed protocols like GIOP/IIOP or DCOM, which are normally filtered by firewalls. SOAP over AMQP is yet another possibility that some implementations support. SOAP also has an advantage over DCOM that it is unaffected by security rights configured on the machines that require knowledge of both transmitting and receiving nodes. This lets SOAP be loosely coupled in a way that is not possible with DCOM. There is also the SOAP-over-UDP OASIS standard.

Message format

XML Information Set was chosen as the standard message format because of its widespread use by major corporations and open source development efforts. Typically, XML Information Set is serialized as XML. A wide variety of freely available tools significantly eases the transition to a SOAP-based implementation. The somewhat lengthy syntax of XMLcan be both a benefit and a drawback. While it promotes readability for humans, facilitates error detection, and avoids interoperability problems such as byte-order (endianness), it can slow processing speed and can be cumbersome. For example, CORBA, GIOP, ICE, and DCOM use much shorter, binary message formats. On the other hand, hardware appliances are available to accelerate processing of XML messages.^[15][16] Binary XML is also being explored as a means for streamlining the throughput requirements of XML. XML messages by their self-documenting nature usually have more 'overhead' (headers, footers, nested tags, delimiters) than actual data in contrast to earlier protocols where the overhead was usually a relatively small percentage of the overall message.

In financial messaging SOAP was found to result in a 2–4 times larger message than previous protocols FIX (Financial Information Exchange) and CDR (Common Data Representation).^[17]

XML Information Set does not have to be serialized in XML. For instance, CSV and JSON XML-infoset representations exist. There is also no need to specify a generic transformation framework. The concept of SOAP bindings allows for specific bindings for a specific application. The drawback is that both the senders and receivers have to support this newly defined binding.

Advantages

·         SOAP's neutrality characteristic explicitly makes it suitable for use with any transport protocol. Implementations often use HTTP as a transport protocol, but other popular transport protocols can be used. For example, SOAP can also be used over SMTP, JMS and message queues.

·         SOAP, when combined with HTTP post/response exchanges, tunnels easily through existing firewalls and proxies, and consequently doesn't require modifying the widespread computing and communication infrastructures that exist for processing HTTP post/response exchanges.

·         SOAP has available to it all the facilities of XML, including easy internationalization and extensibility with XML Namespaces.

Disadvantages

·         When using standard implementations and the default SOAP/HTTP binding, the XML infoset is serialized as XML. To improve performance for the special case of XML with embedded binary objects, the Message Transmission Optimization Mechanism was introduced.

·         When relying on HTTP as a transport protocol and not using Web Services Addressing or an Enterprise Service Bus, the roles of the interacting parties are fixed. Only one party (the client) can use the services of the other.

·         The verbosity of the protocol, slow parsing speed of XML, and lack of a standardized interaction model led to the domination in the field by services using the HTTP protocol more directly. See, for example, REST.

Soap Attacments with MIME header

The SOAP Messages with attachments use the SOAP Messages with Attachments protocol and are encoded using the MIME Multipart/ Related structure.

The following figure shows the structure of the SOAP Messages with attachments:

The following table describes each part of the SOAP Messages with attachments:

Table 28-4 Description about each part of SOAP Messages with attachments

Name of each part					Description
HTTP header					This is the header information dependent on the HTTP protocol.
Boundary string of the HTTP header and HTTP body					This is a string indicating the boundary of the HTTP header and HTTP body.
HTTP body					This describes the message to be sent. Consists of the root part and attachment part.
	Boundary string of the MIME part				This is a string indicating the boundary of each MIME part.
	Root part				This part describes the main message. Consists of the MIME header and MIME body. One root part is necessarily defined.
		MIME header			This is the header information of the root part.
		Boundary string between the MIME header and MIME   body			This is a string indicating the boundary between the MIME header and MIME body of the root part.
		MIME body			This describes the main message.
			SOAP Envelope		This describes the SOAP Envelope.
				SOAP Header	This describes the header information of the SOAP Message.
				SOAP Body	This describes the SOAP Message text (XML).
	Boundary string of the          MIME part				This is a string indicating the boundary of each MIME part.
	Attachment part				This part describes the attachment contents. Consists of the MIME header and MIME body. Define 0 or more attachment parts.
		MIME header			This is the header information of the attachment part.
		Boundary string between the MIME header and MIME body			This is a string indicating the boundary between MIME header and MIME body of the attachment part.
		MIME body			This describes the attachment contents (binary data).
	End string of the MIME part

Frameworks/libraries for SOAP web service development

Name	Platform	Messaging Model(Destination)	Specifications	Protocols
Zend Framework	PHP	Client/Server	Web application framework implemented in PHP	SOAP, JSON, JSON-RPC, REST, XML-RPC
Yii	PHP	Client/Server	Open source, object-oriented, component-based MVC	REST
XML Interface for Network Services	Java	Server ?	??	SOAP, XML-RPC, WSDL, JSON-RPC, JSON
XFire became Apache CXF	Java	Client/Server	WS-Addressing, WS-Security	SOAP, WSDL
WSO2 WSF/PHP	PHP	Client/Server	SOAP MTOM, WS-Addressing, WS-Security, WS-Security Policy, WS-Secure Conversation, WS-Reliable Messaging	SOAP, WSDL
Windows Communication Foundation	.NET	Client/Server/Asyn support	WS-Addressing, WS-Metadata Exchange, WS-Security, WS-Policy, WS-Security Policy, WS-Trust, WS-Secure Conversation, WS-Reliable Messaging, WS-Coordination, WS-Atomic Transaction ,WS-Discovery	SOAP1.1, SOAP1.2, WSDL, XML, JSON, REST, MTOM, MSMQ, IPC, P2P, TCP, UDP, WebSocket
Web Services Invocation Framework	Java	Client	???	SOAP, WSDL
Web Services Interoperability Technology	Java	Client/Server	WS-Addressing, WS-Reliable Messaging, WS-Coordination, WS-Atomic Transaction, WS-Security, WS-Security Policy, WS-Trust, WS-Secure Conversation, WS-Policy, WS-Metadata Exchange	SOAP, WSDL, MTOM, JSON, XML
Symfony2	PHP	Client/Server	PHP web application framework	JSON, REST, SOAP
Smart.Framework	PHP	Client/Server	a free, BSD licensed, open-source web framework	JSON, REST, SOAP
Jersey	Java	Client/Server	Project Jersey is the production-ready reference implementation for the JAX-RS specification by Oracle (Originally Sun)	REST
Jello Framework	GAE/Java	Client/Server/Asyn Support	End-to-End Java framework for Google App Engine including comprehensive Data Authorization model, a powerful RESTful engine, and out-of-the-box UI views.	REST, OData, JSON
Java Web Services Development Pack / GlassFish	Java	Client/Server	WS-Addressing, WS-Security, ???	SOAP, WSDL, ???
gSOAP	C and C++	Client/Server Duplex/Async	WS-Addressing, WS-Discovery, WS-Policy, WS-Reliable Messaging, WS-Security, WS-Security Policy	SOAP1.1, SOAP1.2, MTOM, WSDL 1.1,WSDL 2.0, REST, XML-RPC, JSON, JSON-RPC, XML
Dframe Framework	PHP	Client/Server	Web application Components helping build MVC project.	JSON, REST
CodeIgniter	PHP	Client/Server	An open source MVC web application framework	XML-RPC
Apache CXF	Java	Client/Server/ Asyn Support	WS-Reliable Messaging, WS-Security, WS-Addressing, MTOM, WS-Policy, WS-Secure Conversation, WS-Security Policy, WS-Trust	SOAP1.1, SOAP1.2, MTOM, WSDL 2.0, WSDL, REST
Apache Axis2	Java	Client/Server/ Asyn Support	WS-Reliable Messaging, WS-Security, WS-Atomic Transaction, WS-Addressing, MTOM, WS-Policy, WS-Metadata Exchange	SOAP1.1, SOAP1.2, MTOM, WSDL 2.0, WSDL, REST
Apache Axis	Java/C++	Client/Server	WS-Reliable Messaging, WS-Coordination, WS-Security, WS-Atomic Transaction, WS-Addressing	SOAP, WSDL
.NET Framework	C#, VB.NET	Client/Server	WS-Addressing, WS-Metadata Exchange, WS-Security, WS-Policy, WS-Security Policy, WS-Trust, WS-Secure Conversation, WS-Reliable Messaging, WS-Coordination, WS-Atomic Transaction	SOAP, WSDL, MTOM

 

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 propertycom.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 thecom.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.

Avoid trouble If this JVM property is being used on the z/OS® platform, it must be set in both the servant and control regions of the server.

Avoid trouble 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 does not affect the deployment manager. You must set the property to true on the deployment manager before the node is federated if you wish 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:

·         types such as a Java class, enum or interface

·         methods

·         fields representing local instance variables within a Java class

·         parameters within a Java method

Different testing approaches in web services

Over the last few years, the popularity and usage of web services or APIs have increased. Web service or API is 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 specific scenario such as functional testing, load testing, performance testing, etc.

Here I discuss about 3 web services testing tools that you must consider for your API or web services testing requirements:

1. SoapUI

SoapUI is an open source, cross-platform testing tool. It can automate functional, regression, compliance and load testing of both SOAP and REST web services. It comes with an easy-to-use graphical interface and supports industry-leading technologies and standards to mock and stimulate behavior of web services.

Key Features

·         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

2. TestingWhiz

TestingWhiz is a codeless test automation tool which comes with API/web services testing capability. It lets you perform functional, compliance, load testing and mocking of REST and SOAP web services via WSDL interface over HTTP and FTP. It also lets perform service denial and penetration checks to ensure the overall health of the web services. Plus, it also lets you perform end-to-end testing right from Web UI, business logic, to database and ETL without coding needs.

·         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 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

3. SOAPSonar

SOAPSonar provides comprehensive web services testing for HTML, XML, SOAP, REST, and JSON. It provides functional, performance, compliance, interoperability and security testing with out-of-the-box support for OASIS and W3C standards.

·         Supports vulnerability tests with XSD-mutation.

·         Provides comprehensive WSDL and Schema parsing.

·         Performs load testing with behavior modelling and multiple simultaneous loading transactions.

·         Provides reports in XML, DOC, XLS, PDF, RTF, and RPT formats.

·         Integrates with HP Quality Center.