PRABATH'S TECH BLOG

This blog post assumes that the user who reads has some basic understanding of SSL tunneling and the basic message flow of the ESB. If you are not familiar with the concepts of the SSL tunneling you can refer my previous blog post about the SSL tunneling and you can get detail idea about the message flow from this article . I will give brief introduction about the targetHandler for understand concepts easily. As you may already know TargetHandler(TH) is responsible for handling requests and responses for the backend side. It is maintaining status (REQUEST_READY, RESPONSE_READY .. ,etc) based on the events which fired by the IOReactor and executing relevant methods. As the example if a response which is coming from the backend side hits to the ESB, IOReactor fire the responseRecived method in the targetHandler side. Followings are the basic methods contain in the target handler and their responsibilities. Connect: -  This is executed when new outgoing connection needed. Request

You want to be able to access some restricted destinations and/or ports with some applications from your computer but you are on a restricted network (corporate) - Even using a Torrent client. How to overcome this limitation?  What if backend service is secure one? We can use SSL tunneling for overcome above issue. What is the SSL tunneling? SSL tunneling is when an Internal client application requests a web object using HTTPS on port 8080 through the proxy server.  An example of this is when you are using online shopping. The internet connection to the target relevant e-commerce website  is tunneled to by you through proxy server. The key word here is through. The client communicates with the target web server directly after the initial connection has been established by proxy server, by means of communication within the SSL tunnel that has been created after SSL negotiation has taken place. How it's working? The client makes a tunneling request:

Synapse handler is new feature which come with the ESB 4.9.0. It provide abstract handler implementation to the users. User can create their own concrete handlers which is executing in the synapse layer. Main intention of this blog post is to explain how to write synapse handler and explain basic theoretical background. 1. What is the handler? Handlers are basically talking with the chain of responsibility pattern. Chain of responsibility allows a number of classes to attempt to handle a request independently of any other object along the chain. Once the request is handled, it completes it's journey through the chain. The Handler defines the interface which required to handle the request and concreteHandlers handle request in a specific manner that they are responsible for. 2. What is Synapse handler? Synapse handler is providing abstract handle implementation which executes in the following four scenarios. 1. Request in flow This is exe

Before we talk about the failover message forwarding processor, it’s better to understand the big picture of the concepts and use cases. The Scheduled Failover Message Forwarding Processor is part of the bigger picture of the   message store and message processor . Message Store Message Processor. WSO2 ESB’s Message-stores and Message-processors   are used to store incoming messages and then deliver them to a particular backend with added Quality of Services (QoS), such as throttling and guaranteed delivery. The basic advantage of the MSMP is that it allows you to send messages reliably to a backend service. These messages can be stored in a different reliable storage such as JMS, JDBC message stores. The MSMP powered by three basic components: 1. Store Mediator. The Store mediator is the synapse mediator and can be used to store messages in the message store. 2. Message Store. A message store is storage in the ESB for messages. The WSO2 ESB comes with four types of m

When you run the pre-defined security scenarios in the WSO2 ESB most probably you already faced the Illegal key size or default parameters exception org.apache.axis2.AxisFault: Error in encryption     at org.apache.rampart.handler.RampartSender.invoke(RampartSender.java:76)     at org.apache.axis2.engine.Phase.invokeHandler(Phase.java:340)     at org.apache.axis2.engine.Phase.invoke(Phase.java:313)     at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:261)     at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:426)     at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:398)     at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:224)     at org.apache.axis2.client.OperationClient.execute(OperationClient.java:149)     at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:554)     at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:530)     

Preserving HTTP headers are important when executing backend services via applications/middleware. This is because most of the time certain important headers are removed or modified by the applications/middleware which run the communication. The previous version of our WSO2 ESB, version 4.8.1, only supported “ server ” and “ user agent ” header fields to preserve with, but with the new ESB 4.9.0, we’ve introduced a new new property ( http.headers.preserve ) for the passthru ( repository/conf/ passthru-http.properties ) and Nhttp( repository/conf/ nhttp.properties ) transporters to preserve more HTTP headers. Passthru transporter – support header fields               Location Keep-Alive Content-Length Content-Type Date Server User-Agent Host Nhttp transport – support headers Server User-Agent Date You can specify header fields which should be preserved in a comma-separated list, as shown below. http.headers.preserve = Location, Date, Server Note that

Security is  one of the major concern when we developing API base integrations or application developments. WSO2 supports WS Security , WS-Policy and WS-Security Policy specifications. These specifications define a behavior model for web services. Proxy service security requirements are different from each others. WSO2 ESB providing pre-define commonly used twenty security scenarios to choose based on the security requirements. This functionality is provided by the security management feature which is bundled by default in service management feature in ESB. This configuration can be done via the web console until ESB 4.8.1 release, but this has been removed from the ESB 4.9.0. Even though this feature isn't provided by the ESB web console itself same functionality can be achieved by the new WSO2 Dev Studio . WSO2 always motivate to use dev studio to prepare required artifacts to the ESB rather than the web console. Better way to explain this scenario is by example. Following