| Oracle® Retail Integration Bus Implementation Guide Release 13.0 |
|
 Previous |
 Next |
As the logical srchitecture diagram shows, there are many rib-<app> applications that coordinate message flows between the various Oracle Retail applications. There are no physical location constraints on where these rib-<app> applications can be deployed as long as they are visible from the same network. But the decision on where to physically and logically locate your rib-<app> applications has a huge impact on the high availability, performance and maintainability of your integration solution, so this decision must be given careful consideration.
The RIB applications can be deployed in a variety of physical and logical configurations depending on the retailer's needs. Oracle Retail has two recommended configuration alternatives.
Distributed In this deployment each of the rib application (rib-<app>.ear) is deployed in the same Oracle Application Server as integrating application (<app>.ear) but in its own oc4j instance.
Centralized In this deployment all rib applications (rib-<app>.ear) are deployed in a single Oracle Application Server (not oc4j instance) independent of where the Oracle Retails apps (<app>.ear) Oracle Application Server is.
In all cases, the rib application (rib-<app>.ear) should be deployed in its own OC4J Instance. It is not recommended to deploy multiple rib applications into the same OC4J instance, or to have the rib application (rib-<app>.ear) deployed into the same OC4J instance as the integrating application (<app>.ear).
In this deployment setting the rib application (rib-<app>.ear) is deployed in the same Oracle Application Server as the integrating application (<app>.ear). Logically rib-<app>.ear and <app>.ear are closely tied to each other, so it makes sense to also deploy them physically close to each other within the same Oracle Application Server. There will be only one JMS server and all participating rib-<app> are configured to use the same JMS server.
Following are some advantages and disadvantages of this configuration.
Required single Oracle Application Server for both rib (rib-<app>.ear) and integrating application (<app>.ear).
<app>.ear and rib-<app>.ear are close to each other but are still loosely coupled.
It is easy to find which rib-<app>.ear is associated with which integrating application (<app>.ear).
A single OAS instance is never the single point of failure for the whole integration system.
The Oracle Process and Notification manger can optimize network communication much better when both the oc4j instances are managed by the same OAS instance.
When OAS server of rib-<app>.ear has to be bounced, the integrating application (<app>.ear) becomes unavailable as both reside in the same application server. Similarly rib-<app>.ear has to bounce when <app>.ear needs bouncing. This dependency between the two applications is not ideal.
Even though both the applications reside within the same application server, it is the configuration with the applications that are tying them together not the physical characteristics of both being deployed in the same application server. Physical location might be misleading if the system is not configured correctly.
One application server has to work harder for management of resources and services for both applications.
System load distribution between rib-<app>.ear and <app>.ear is not possible as both applications reside within the machine.
Medium to large size deployments can use this configuration. This configuration is appropriate when the machine hosting OAS is adequately sized for its job. A high message volume in rib-<app>.ear can adversely affect the performance of the integrating application (<app>.ear) in areas that are not related to integration. Ideally this kind of behavior is not desirable for an online system.
In this deployment all rib application (rib-<app>.ear) are deployed in a single Oracle Application Server but in separate Java EE containers (OC4J Instances). The integrating applications (<app>.ear) are deployed in their own separate Oracle Application Server. There is only one JMS server and all participating rib-<app> are configured to use the same JMS server.
Following are some advantages and disadvantages of this configuration.
All integration relegated components are deployed in one application server.
Simple to find, view, and manage.
Since all rib-<app>.ear resides in the same Oracle Application Server, system resources get shared between the applications which means that they can adversely affect each others performance. For example rib-aip.ear can become slow when rib-rpm.ear is processing lots of messages even though these applications are not at all related to each other.
Overall performance can be slower as one application server machine has to do lots of work.
The RIB application server and host become the single point of failure for the whole integration system (environment). That is, when the Oracle Application Server goes down the whole integration is down for all retail applications (<app>.ear).
Small to Medium size deployments can use this configuration. When the message size is small and high volume is not expected this configuration can be used. This configuration can also be used when there are only two integrating application. As each rib-<app>.ear publishes and subscribes to each other, they are indirectly (through JMS) interdependent and so performance should not be affected too much when the message volume is less.
RIB deployment recommendation does not take into account your hardware size, network topology, existing legacy system, and so on. One size fits all does not work. You need to do proper due diligence based on our recommendations and your specific environment settings in order to come up with the best deployment architecture that meets your needs.
