Axis 2 Web Service - Readers View [ PART 1 ]

The single standalone concept is gone away and now every devices are connected, even rather than hardware also connected and talk between them each other.

The web services provide a way to make interaction between the application to the outer world. When you are willing to make an application you might consume web services in you way. Because you are not able to code everything by your hand. And also if you are willing to connect your application to the world you have to provide services too. 

Web Service defines SOAP, the message format, and WSDL, a common way to describe the Web Services. Different programming languages may define different implementations for Web Services, yet they inter-operate because they all agree on the format of the information they share.

Web Services 

To understand the Axis2 and what it does you need to have understanding of web services and the work flow of web services.

The sender create the original SOAP message, While on sending the system requires additional Ws* recomondations like Ws-Addressing and WS-Security stuffs the message goes for additional processing before it leaves the sender. Once the message is ready then it send through  a particular transport like JMs, HTTP, FIX and so on.

How Axis2 Handle SOAP Messages

In both sending and receiving end Axis2 handle the messages.

In each end point we need to have an application which are deal with sending and recieving, but no matter they are in different platform. The Axis2 is in the middle to deal with the messages. 

The process of message transfer looks like this. 

1. The sender creates the SOAP message.
2. Axis "handlers" perform any necessary actions on that message such as encryption of WS-Security related messages.
3. The transport sender sends the message.
4. On the receiving end, the transport listener detects the message.
5. The transport listener passes the message on to any handlers on the receiving side.
6. Once the message has been processed in the "pre-dispatch" phase, it is handed off to the dispatchers, which pass it on to the appropriate application.

In Axis2 these process are broken into phases.

Axis 2

Apache Axis has been the most successful open source Web Services implementation over the last three years. Axis has been the SOAP engine any other SOAP engine is always compared against and it is the defacto SOAP engine for academics in their research.

But nothing is forever, There is a sudden change took place on the web service space. That is expected features from the web service middle ware have changed. So on the new generation the following are conern as main. 

1. Better Performance on memory and end-to-end latency. 
2. Support for asynchrony and other messaging.
3. Better support for the WS-extensions.

Axis 2, The Concepts

1. Does not assume Request -Response instead it supports a wide range of messaging interactions.
2. Both asynchronous as well as synchronous are given the same stakes.
3. New object model that supports for different parsing. The object model provides easy to use interface for the users.
4. Introduction of a new concept, Modules, to handle the WS-extensions.

Web Services Messaging 

almost all of the solutions for the problem of distributing computer power emerge from two conceptual bases: remote procedure calls (RPC) and messaging.

Unquestionably, using RPCs is the more popular technique among developers, partly due to its resemblance to using local procedure calls. It has an air of familiarity for programmers, and creates a natural tendency towards using RPC style in a distributed system. Messaging, on the other hand, is not remarkably popular, and quite a few developers are likely to raise their eyebrows if it is mentioned. Nevertheless, messaging provides certain advantages over RPC systems in certain scenarios.

The fundamental differences between RPC and messaging frameworks are as follows.

1. Messaging has no notion about client and server. Messaging frameworks only concern about delivering messages. RPC always has the concepts of the service requester (AKA client) and service provider (AKA server).
2. Messaging is time-independent, to a certain extent. None of the peers are expected to accept the message in real time--MOM takes care of delivering a message to the relevant peer when it is available. RPC, however, fails instantly when one party goes down.
3. Messages can be duplicated and delivered to multiple peers quite easily. While RPC is essentially a one-with-one communication strategy, messaging is far more flexible and can deliver copies of the same message to multiple peers without any effort from the emitter.

Web Service Messaging

Web service messaging is based on the XML massaging and the following three parameters are most important for web service messaging. 

1. Message exchange pattern.
2. Synchronous and asynchronous client API.
3. One-way/two-way behavior of the transport.(It is based on simplex or duplex)
   SMTP and JMS are one-way of transport and the other hand HTTP and TCP are two way transport.  Actually, in web service messaging, two-way transports may be used as a one-way transports, but in such cases, they can be effectively treated as one-way.

In most abstract view we see what is web service messaging is just sending and receiving messages. 

Message Exchanging Patterns (MEP)

Message exchange pattern is a template that establishes a pattern for the exchange of messages between two communicating parties. All of the names can be understood by replacing the in with request and out with response.

There are two MEPs are there.

1. In-only/"fire and forget:" The service requester sends a message to the service provider and does not expect any related reponses.
2. In-out/"request response:" The service requester sends a message to the service provider and expects a response.

Synchronous/Asynchronous

It is based on the thread that is handles the web service invocation. 

A synchronous service will block, and wait for related messages to arrive. 

Asynchronous invocation will just return, and waiting for related messages will be done by a different thread that runs in the background.

Behavior of the Transport Layer

The behviour is depends on the web service. The web service, which is decide it is one-way or two-way. Example  when the transport is HTTP, the related message may come from the return path of the HTTP connection, or the web service provider might write HTTP 200 to indicate that there is no response coming on the same connection, in which case the response is sent over a separate HTTP connection.

Web Service Addressing (WS-addressing) 

In ws-addressing following five parameters define the addressing.

1. Message exchange pattern (MEP)
2. Transport with which the service can be accessed
3. Transport used by the related (response) messages
4. Behavior of the transport
5. Synchronous/asynchronous behavior of the client API

The service provider declares the first two, and the client is free to define the other parameters.

Among many other constructs, WS-addressing defines four headers: To, ReplyTo, RelatesTo, FaultTo, and a special address that is called the Anonymous address.

When a service provider receives a SOAP message,

• To : it finds the target service based on the To address and invokes the service. 
• ReplyTo : the results, if there are any, are sent to the ReplyTo address
• FaultTo :  any error is sent to the FaultTo address. 

If any of the above headers are not specified or have the value Anonymous, the result is sent via the return path of a two-way transport (since Anonymous always resolves to the return path of a two-way transport).

• RelatedTo : Messages are related either because they share the same transport channel, or because they all share common information that links them to each other. The RelateTo header of the web service addressing provides precisely this relationship.

References : 

1. Introducing-Axis-2-the-Next-Generation-of-the-Apache-Web-Service-Stack
2. Axis2 Messaging