Friday 3 February 2012

How to design? - the performance of OSB

What factors do we have to take into consideration in the design phase or architecture planning to ensure the best performance of OSB? I am sure that I won't be able to give a complete answer for this question but just some tricks or thoughts. Not because I don't want to but simply I just don't have suffice knowledge. :)

The performance is important for any system but for the OSB it is really vital. As I mentioned earlier the OSB seems to be a gateway between two or more systems (we know it is not just a gateway but if we consider a communication between 2 systems then it seems to be).
The data don't just flow through the OSB (this is true even if we are thinking of the simplest message) but the OSB parses the the requests/responses XML messages, logs the events, handles some inner handler components (e.g. What to display on the OSB console), save data into the OSB management database and so on. These operations take time and resources.

So we can say that the communication is quicker without than with OSB... This is a hard conclusion but take a look at the next figure:


It is clear that the second communication is quicker than the first one. But the situation is unambiguous if we are talking about pure network communication (e.g. webservice calling).
I know that the mission of OSB is not to accelerate the communication (it can do it in some cases as we will see soon) but I am going to examine the performance factor in this blog.

The business services in OSB can handle a lot of protocols and even we can use many adapters of the Oracle SOA Suite. Using these adapters might be more effective than how any system could handle the communication. So it is more useful to use the OSB to connect two systems than you should develop a new communication way (e.g. 'system A' has to send data to 'system B' but 'system B' can receive data via email so you should develop an email sending module into 'system A').

We can use the Oracle Coherence to cache static data on OSB. If we are sure that the source system sends back static data (not transactional data but product code or date of birth of people) then the OSB (with Oracle Coherence) can send back these information directly without using the source system. Take a look at the next figure:


The OSB (Oracle Coherence) can serve multiple client requests without using the source system. For the first time (when any of clients send its first request) the cache has to be filled. It means that OSB needs to call the source system and put the result from the source system to the cache. Later the cache will call the source system when it must refresh its data (the frequence of the refresh can be set).
We can disencumber the source system with OSB's help so the performance of communication can be optimized as well. We should be careful how we use Oracle Coherence. I mean how often do we have to refresh the cache, which services should we mock with Coherence and so on.

We can protect the source system against overwhelming it with requests. We can limit the number of requests by the throttling function of OSB. This is an attribute group of business services.

Other important possibility of OSB is to alert if there is problem with some services of source systems. We can define SLA alerts for business services and indicate if the service stopped working. We can assign operations to these alerts for sending emails, logging and so on.
Moreover we can assign these SLA alerts to throttling metrics as well so we can predict events (OSB can notify us that a service can serve less requests now than earlier).

The service bus can analyze the request and route it to different systems according to the request parameters. For example there is a date parameter in the request of a query service and if the difference between the actual date and this date is greater than 6 months then the OSB has to call the service of the data warehouse but if it is less then the service bus has to use the service of the transactional system.
And there are a lot of other tricks as well...

And I don't want to talk about how much time and money You can save to use the OSB (considering the cost of starting a new project in a legacy system...). But we are discussing about the performance topic.
You can improve the performance by considering :
- the efficiency of the message flows
- the configuration of OSB
- the configuration of Weblogic

The message flow must be as simple as possible. You mustn't put any unnecessary steps into the message flow as it might slow down the service.
If You have to call administration services (e.g. logging) then You should use asynchronous calls (if possible) not to bother the main message flow. In case of asynchronous call there is not response so the message flow doesn't have to wait for it.
You should consider how many times the service must be called (in case of an error) and how much time the message flow must wait between two calls. You must set the attributes of business services very carefully.
Other effective trick is to use split-join to execute multiple tasks in parallel.