Overview of SOAP Message Handlers

Overview of SOAP Message Handlers

Some Web services need access to the SOAP message, for which you can create SOAP message handlers. A SOAP message handler provides a mechanism for intercepting the SOAP message in both the request and response of the Web service.

A simple example of using handlers is to access information in the header part of the SOAP message. You can use the SOAP header to store Web service specific information and then use handlers to manipulate it.

You can also use SOAP message handlers to improve the performance of your Web service. After your Web service has been deployed for a while, you might discover that many consumers invoke it with the same parameters. You could improve the performance of your Web service by caching the results of popular invokes of the Web service (assuming the results are static) and immediately returning these results when appropriate, without ever invoking the back-end components that implement the Web service. You implement this performance improvement by using handlers to check the request SOAP message to see if it contains the popular parameters

JWS Annotations Used To Configure SOAP Message Handler Chains:

JWS Annotation	Description
javax.jws.HandlerChain	Associates the Web service with an externally defined handler chain. Use this annotation when multiple Web services need to share the same handler configuration, or if the handler chain consists of handlers for multiple transports.
javax.jws.soap.SOAPMessageHandlers	Specifies a list of SOAP handlers that run before and after the invocation of each Web service operation. Use this annotation (rather than @HandlerChain) if embedding handler configuration information in the JWS file itself is preferred, rather than having an external configuration file. Note; This annotation works with JAX-RPC Web services only.
javax.jws.soap.SOAPMessageHandler	Specifies a single SOAP message handler in the @SOAPMessageHandlers array.

Difference between top-down and bottom-up approach of developing web services

Difference between top-down and bottom-up approach of developing web services

In top-down approach, first WSDL document is created and then Java classes are developed based on WSDL contract, so if WSDL contract changes you got to change your Java classes.

In bottom up approach, you first create Java code and then use annotations like @WebService to specify contract or interface and WSDL field will be automatically generated from your build.

Difference between REST web services and SOAP web services

SOAP	REST
	REST is more simple and easy to use as it is based on use of nouns and verbs (better readability)
SOAP uses XML	REST uses HTTP protocol for producing or consuming web services
The SOAP WS is transport protocol neutral. Supports multiple protocols like HTTP(S), Messaging, TCP, UDP SMTP, etc	REST is transport protocol specific. Supports only HTTP or HTTPS protocols.
	REST is lightweight as compared to SOAP and preferred choice in mobile devices and PDA's.
	REST does not need XML parsing, no message header (to and from), hence less bandwidth
SOAP only supports XML.	REST supports different format like text, JSON and XML
SOAP based reads cannot be cached.	REST based reads can be cached.
SOAP: can have user defined error	REST: requires HTTP error handling
SOAP supports both SSL security and WS-security, which adds some enterprise security features like maintaining security right up to the point where it is needed, maintaining identities through intermediaries and not just point to point SSL only, securing different parts of the message with different security algorithms, etc.	The REST supports only point-to-point SSL security. The SSL encrypts the whole message, whether all of it is sensitive or not.
The SOAP has comprehensive support for both ACID based transaction management for short-lived transactions and compensation based transaction management for long-running transactions. It   also supports two-phase commit across distributed resources.	The REST supports transactions, but it is neither ACID compliant nor can provide two phase commit across distributed transactional resources as it is limited by its HTTP protocol.
The SOAP has success or retry logic built in and provides end-to-end reliability even through SOAP intermediaries	REST does not have a standard messaging system, and expects clients invoking the service to deal with communication failures by retrying

Ways to access web service

Ways to access web service:

There are two ways to access web service.

• SOAP: - If Service provider knows client: If service provider knows its client then it will provide it’s wsdl to client and client will be able to access web service.

• REST: - Service provider register its WSDL to UDDI and client can access it from UDDI: Web services can register with a UDDI and make themselves available through it for discovery

1.Service provider registers with UDDI.

2.Client searches for service in UDDI.

3.UDDI returns all service providers offering that service.

4.Client chooses service provider

5.UDDI returns WSDL of chosen service provider.

6.Using WSDL of service provider, client accesses web service.

In the web services terms, Representational State Transfer (REST) is a stateless client-server architecture in which the web services are viewed as resources and can be identified by their URIs.
It consists of two components REST server which provides access to the resources and a REST client which accesses and modifies the REST resources.

In the REST architecture style, clients and servers exchange representations of resources by using a standardized interface and protocol. REST isn't protocol specific, but when people talk about REST they usually mean REST over HTTP.

What is WSDL?

WSDL stands for Web Service Description Language. It is an XML file that describes the technical details of how to implement a web service, more specifically the URI, port, method names, arguments, and data types. Since WSDL is XML, it is both human-readable and machine-consumable, which aids in the ability to call and bind to services dynamically. Using this WSDL file we can understand things like

•     Port / Endpoint – URL of the web service
•     Input message format
•     Output message format
•     Security protocol that needs to be followed
•     Which protocol the web service uses

WSDL describes web services in an xml format so that different technologies can understand

What is UDDI ? Why Soap ?

Web service is a way of communication that allows interoperability between different applications on different platforms, for example, a java based application on Windows can communicate with a .Net based one on Linux. The communication can be done through a set of XML messages over HTTP protocol.

Web services are browsers and OS independent service, which means it can run on any browser without the need of making any changes. Web Services take Web-applications to the Next Level.

Let’s say, you are a java developer and you can publish your functions on internet or LAN through java web service so any other developer (let’s say .Net developer) can access your function.

Universal Description, Discovery and Integration (UDDI):

Directory where any publisher can publish their web services and consumer can get access to all web services. Web services can register with a UDDI and make themselves available through it for discovery.

Simple Object Access Protocol (SOAP)

SOAP is a standard protocol specification for message exchange based on XML.
Communication between the web service and client happen using XML messages. SOAP is a XML format used to encode and decode different messages across network so that irrespective of technology it can understand each other.

Simple web service architecture has two components:

·Client

·Service provider

So in order to communicate client must know some information for e.g.

·Location of web services server

·Functions available, signature and return types of function.

·Communication protocol

·Input output formats

Service provider will create a standard XML file which will have all above information. So if this file is given to client then client will be able to access web service. This XML file is called WSDL.

What are the benefits of IOC? What is the difference between singleton and prototype bean?

What are the benefits of IOC?

    ·   It minimizes the amount of code in your application.It makes your application easy to test as it doesn't require any singletons or JNDI lookup mechanisms in your unit test cases. Loose coupling is promoted with minimal effort and least intrusive mechanism.IOC containers support eager instantiation and lazy loading of services.

What is Spring IoC container?

The Spring IoC creates the objects, wire them together, configure them, and manage their complete lifecycle from creation till destruction. The Spring container uses dependency injection (DI) to manage the components that make up an application.

What are types of IoC containers? Explain them.

·   Bean Factory container: This is the simplest container providing basic support for DI .The BeanFactory is usually preferred where the resources are limited like mobile devices or applet based applications

·         Spring ApplicationContext Container: This container adds more enterprise-specific functionality such as the ability to resolve textual messages from a properties file and the ability to publish application events to interested event listeners.

What is the difference between singleton and prototype bean?

Prototype scope = A new object is created each time it is 

injected/looked up. It will use new SomeClass() each time.

Singleton scope = The same object is returned each time it 

is injected/looked up. Here it will instantiate one instance 

of SomeClass and then return it each time.