| Oracle® Retail Integration Bus Implementation Guide Release 14.0 E48340-01 |
|
 Previous |
 Next |
There are no physical location constraints on where 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 Weblogic Application Server as integrating application (<app>.ear) but in its own WLS managed server instance.
Centralized: In this deployment, all rib applications (rib-<app>.ear) are deployed in a single Weblogic Application Server (not managed server instance) independent of where the Oracle Retails apps (<app>.ear) Weblogic Application Server is.
In all cases, the rib application (rib-<app>.ear) should be deployed in its own managed server instance. It is not recommended to deploy multiple rib applications into the same WLS managed server instance, or to have the rib application (rib-<app>.ear) deployed into the same WLS managed server instance as the integrating application (<app>.ear). This configuration of deploying multiple rib-<app>s in one managed server instance is not recommended or supported by WLS.
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 WLS instance is never the single point of failure for the whole integration system.
When WLS 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 WLS 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 WebLogic Application Server but in separate Java EE containers (managed server instances). The integrating applications (<app>.ear) are deployed in their own separate WebLogic 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.
The configuration is simple to find, view, and manage.
Because all rib-<app>.ear (applications) reside on the same WebLogic Application Server, system resources are shared among the applications, which means each can adversely affect the performance of another. For example, rib-aip.ear can become slow when rib-rpm.ear is processing a lot 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 WebLogic 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.
|
 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|