One of the most important requirement against OSB is the response time. Usually we must prepare to process huge amount of requests. The more requests the OSB has to serve the more time the OSB needs to process one request. After a while the response time is going to be so long that it will decrease the user experience or it won't meet the SLA values or simply we get an error as it has caused a timeout.
It is vital to have standby as well to prepare the unexpected loading. Just imagine that a campaign has been launched to popularise a new product. If this campaign is successful then it can cause a bigger traffic than usual. If we are not prepared to handle these more requests then I think it is really hard to explain to the business users or our boss that the problem is that too many customers want to buy our products... :)
The obvious solution is in this case to add more servers to our OSB environment. Of course there are more possible workarounds too (optimizing code of OSB components or external services) but adding servers is the quickest one (Usually it is pretty difficult to change the existing code and sometimes it is not possible if an external system should be optimized.)
I am not stating that getting and installing a new server takes only minutes. A server could cost a fortune so getting one ore more needs the confirmation of different departments which can last ages. Afterwards it has to be set up, installed, etc.Nevertheless our OSB components/environment must be prepared for working in cluster environment. We could say that it is not so difficult at all as we put the new server into the Weblogic cluster and the components will be deployed onto the new server as well.
On the picture above our cluster contains seven servers and all the OSB components (proxy services, etc.) are going to be deployed onto every server. It doesn't seem to be a bad idea but we can find out better! Have a look at the next figure:
Why is it better? First of all: this architecture is more flexible, we have got many opportunities to set up the system. Probably the system is going to be quicker too.
However I think I have to explain more detail the diagram above. There are three clusters in this architecture. The cluster C1 uses 4 servers (S4, S5, S6, S7), the cluster C2 uses 3 servers (S1, S2, S3) and the cluster C3 has got 7 servers (S1 - S7).
Let's suppose that we have got 40 proxy services which must be deployed onto the servers. In case of the first architecture there is just one cluster which has got all the servers so we just have to deploy the proxy services onto the cluster and that's it. It is very simple but on the other hand we haven't got any possibility to tune our system. What if we should improve the performance of one service? We can improve the performance of the entire OSB environment by adding new servers as we have got just one cluster. If we have got more clusters which use different servers we should add the new server(s) to that cluster where our service is.
It is important to examine the services and estimate their loading (e.g. how many requests must be served in a day/hour/etc.). We have to find the services which will be heavily used and those ones which are won't. Using the former example 10 of the 40 proxy services are overused the rest of the services are not used so often. We have got 3 clusters so we have options how to arrange the services:
| Heavily used services | Not often used services | |
|---|---|---|
| Cluster 1 | 6 | 5 |
| Cluster 2 | 4 | 5 |
| Cluster 3 | 0 | 20 |
Of course it is not sure that this is the best allocation of the services but this is just an example and the important thing is that WE CAN improve the performance of our OSB environment if it is necessary. What's more we could tune that part of our environment which is really needed to improve so the tuning can be much more effective.
So the base idea is to group the services which must be deployed onto the same cluster. The simplest solution is to do that to create an OSB project for each cluster and put those services into the project which should be deployed onto the cluster. Take a look at the next picture:
There are four projects for the OSB components:
- cluster_1 : for those services which must be deployed onto the Cluster 1
- common_components : those artifacts can be put here which might be used in more projects or proxy services (e.g. XSD's, internally used proxy services, etc.)
- services_COMMON : generally used proxy services
- business_services : for the business services
Considering the future it is better solution to define all the business services in one project and just deploy them to every cluster.
