WSO2 ESB Advantages

Many organizations use ESBs in their integration scenarios in order to facilitate interoperability between various heterogeneous systems.

WSO2 ESB is one of the leading ESB solutions in the market which is 100% free and open source with commercial support.

Here are the advantages of selecting WSO2 ESB for your integration needs.

• WSO2 ESB is feature rich and standards compliant. It supports standard protocols such as SOAP, REST over HTTP and several other domain specific protocols such as HL7.
• It has numerous built-in message mediators.
• You can select among various message formats, transports as needed.
• WSO2 ESB connector store provides numerous built-in connectors to seamlessly integrate third party systems.
• WSO2 ESB tooling enables quickly build integration solutions to be deployed in WSO2 ESB.
• Furthermore, it is highly extensible since it provides you the flexibility to develop WSO2 ESB extensions such as connectors, class mediators which allow adding more features which are not supported OOTB.

Read through this comprehensive article written by Samisa Abeysinghe (Chief Engineering and Delivery Officer - WSO2 ) on What is WSO2 ESB.

http://wso2.com/library/articles/2017/07/what-is-wso2-esb/

This article explains about when you should consider using WSO2 ESB, what are the advantages of it and also about the powerful capabilities of WSO2 ESB.

AS4 Messaging Standard

AS4 is a recent B2B messaging standard. It can exchange any type of payloads (XML, JSON, Binary, ect.) and also it supports sending multiple payloads in one AS4 message.

AS4 originates from ebXML (Electronic Business XML). AS4 Profile of ebMS 3.0 which is a conformance profile of AS4 defines the following 3 conformance profiles (CP) defining subsets of ebMS V3 options to be supported by an AS4 Message Service Handler (MSH).

• AS4 ebHandler CP
• AS4 Light Client CP
• AS4 Minimal Client CP

AS4 Messaging Model

AS4 defines a Four-Corner-Model including the components involved in a message exchange. Following are the entities of this four-corner-model.

Message Producer: Business application which sends the message content to the sending Message Service Handler(MSH).

Sending Message Service Handler: Packages the message content and sends to the intended receiving MSH.

Receiving Message Service Handler: Receive the message from the sending MSH.

Message Consumer: The business application which receives the message content from receiving MSH.

The above-mentioned conformance profiles of AS4 Profile of ebMS 3.0 defines supported different subsets of AS4 profile options by an AS4 Message Service Handler.

• The message sent from the producer to the sending MSH can be of any format agreed by those two entities.
• Similarly, the messages exchanged between the receiving MSH and the consumer can be of any format.
• AS4 defines the message format being exchanged between the sending MSH and receiving MSH.
• Apart from that AS4 P-mode configuration files which reside in the MSHs instruct on how to handle AS4 messages.

AS4 Message Exchange Patters (MEPs)

In AS4, there are two message exchange patterns. 

• One-way / Push
• In one-way / push MEP, the sending MSH sends the AS4 user message containing payloads to the receiving MSH. The initiator is the sending MSH.
• One-way / Pull
• In one-way / pull MEP, the receiving MSH sends a pull request signal message to the sending MSH. Then the sending MSH sends the user message. The initiator in this MEP is the receiving MSH.

AS4 Minimal Client Profile

As per the specification AS4 minimal client profile applies only to one side of an MEP (acting as a “client” to the other party).

P-Mode configuration file for AS4 Minimal Client Profile

      push
      http://wso2.org/examples/agreement0
      http://www.oasis-open.org/committees/ebxml-msg/one-way
      http://www.oasis-open.org/committees/ebxml-msg/push
      
           org:wso2:example:company:A
           Sender
      
      
           org:wso2:example:company:B
           Receiver
      
      
           

http://localhost:8280/as4Test
1.2
      
      
           Examples
           StoreMessage
      
      
           
                true
                true
           
      

ESB Message Flow

Sample proxy configuration

1. Go inside /samples/axis2Server  and start the simple axis2service :  ./axis2server.sh

2. To send a request to the above proxy, go inside /samples/axis2Client and run the command: ant stockquote -Daddurl=http://localhost:8280/services/TestProxy

So now let's analyze the message In-flow inside ESB.

Message In-Flow

ProxyServiceMessageReceiver is the entry point to Synapse.

Once a message is sent to a proxy service deployed in ESB, is will come to the,

org.apache.synapse.core.axis2.ProxyServiceMessageReceiver::receive()
Receive method here gets a org.apache.axis2.context.MessageContext object.

In the Axis2 level, it uses Axis2 MessageContext. In the mediation engine level, that is, in the Synapse level it needs to be converted to SynapseMessageContext. This is done by MessageContextCreatorForAxis2

Inside the org.apache.synapse.core.axis2.MessageContextCreatorForAxis2::getSynapseMessageContext() method it will get the SynapseConfiguration from AxisConfiguration and get the SynapseEnvironment from AxisConfiguration

Message mediation starts thereafter inside the org.apache.synapse.mediators.base.SequenceMediator::mediate() method. Inside this method, following method call will call to AbstractListMediator::mediate() method.

boolean result = super.mediate(synCtx);

Message mediation starts thereafter inside the org.apache.synapse.mediators.base.SequenceMediator::mediate() method. Inside this method, following method call will call to AbstractListMediator::mediate() method.

boolean result = super.mediate(synCtx);

AbstractListMediator::mediate() method iterate through all the mediators in the mediation flow and verify whether there are content aware mediators exist in the mediation flow. If there are any, it will call AbstractListMediator::buildMessage() in order to build the message.

if (sequenceContentAware && mediator.isContentAware() &&
          (!Boolean.TRUE.equals(synCtx.getProperty(PassThroughConstants.MESSAGE_BUILDER_INVOKED)))) {
          buildMessage(synCtx, synLog);
}

Finally when the SequenceMediator::mediate() method returns true to the ProxyMessageReceiver::receive(), it will send the message to the endpoint.

// if inSequence returns true, forward message to endpointif(inSequenceResult) {
    if (proxy.getTargetEndpoint() != null) {
        Endpoint endpoint = synCtx.getEndpoint(proxy.getTargetEndpoint());

        if (endpoint != null) {
            traceOrDebug(traceOn, "Forwarding message to the endpoint : "                + proxy.getTargetEndpoint());
            endpoint.send(synCtx);

        } else {
            handleException("Unable to find the endpoint specified : " +
                proxy.getTargetEndpoint(), synCtx);
        }

    } else if (proxy.getTargetInLineEndpoint() != null) {
        traceOrDebug(traceOn, "Forwarding the message to the anonymous " +
            "endpoint of the proxy service");
        proxy.getTargetInLineEndpoint().send(synCtx);
    }
}

Exit point from the synapse is org.apache.synapse.core.axis2.Axis2FlexibleMEPClient::send() method.

When a response is returned from the backend, ESB needs to send it back to the client. This message flow is called message Out-Flow. Let's analyze the message out-flow.

Message Out-Flow

In the response path, the entry point to Synapse is org.apache.synapse.core.axis2.SynapseCallbackReceiver::receive() method.

Inside this method, org.apache.synapse.core.axis2.SynapseCallbackReceiver::handleMessage() is called. This method will handle the response or error.

This will call
synapseOutMsgCtx.getEnvironment().injectMessage(synapseInMessageContext);
which will send the response message through the synapse mediation flow.