When Client Message Comes to ESB What happens to it When going Through the ESB

When there are 2 applications runs on different platforms and when they need to communicate each other there should be a way to do that in order to support to their communication, as an example when client operate in J SON format and server operate in XML format there should be someone in the middle to translate client request to a format understand by the Server and on the other way Server response should be understand by the client. That is the place where ES B come in to the picture.

The client can send the message to ESB in JSON format and ESB convert the JSON message to SOAP format and do the processing and then SOAP message converts to XML format which is understand by the Server. When we go deep in to the picture then we can see there are several components in ESB which supports to the communication. The verticle components where the message is go through are

• Transport
• Message builder and formatter
• QoS
• Mediation engine

 

Now let’s see what is doing in each vertical component when message is going through the ESB. When a client request comes to ESB it 1^st reaches to the transport layer .It is responsible for carrying the message. it support HTTP/s,JMS,VFS protocols and etc. wso2 transport is based on Apache Axis2 framework. There are 2 main interfaces

• TransportListener
• TransportSender

when a request comes from the client to ESB and 1^st when it hits transport the TransportListener which is implemented in Transport is responsible to receive it and process the message.

After that the client request message next reaches to the component called Message Builder. It is responsible to convert the message into a common format where ESB mediation engine can read and understand and apply the relevant mediation logics. Receiving transport select the message builder according to the content type of the message. As an example when client request comes in JSON format, Message builder convert that message to SOAP which is understand by the mediation engine. And also it does d-serialization of the request message

Then QoS which support security,throttling and logging these features added by the carbon platform

And next request is reaches to the mediation engine.There we can define mediators according the requirement. Mediator is the processing unit in the ESB and it can apply logic to certain message and do any thing to the message.

When request comes to mediation engine ,it go through the in-sequence and do whatever the processing needed according to the requirement. default there is one main sequence .Sequence mean a sequence of mediators when any fault happen in the sequence it will be send in to the fault sequence where we can handle the fault.

After that the message formatter format the SOAP message in to XML format which is understand by the back-end send the request to back-end. The message formatter which needs to be select is decided by again the by content type of the message. And also it does serialization of the message

Once the response is received by ESB again massage builder convert the response message which is in XML format to SOAP format.

And it then it go through the Out sequence .Again it is set of mediators which do processing in the message if any fault happens it will send to the fault sequence.

And again QoS apply certain security rules and other logging and etc.

Then response message go to the message formatter where SOAP response message convert to JSON format which is understand by the client.

Finally transport component where TransportSender is being invoked and it is responsible how the message send from Axis 2 engine.

Ultimate result is Client is happy with receiving a response from back-end which can be understandable by itself.