Go to primary content
Oracle® Retail Service Backbone Implementation Guide
16.0
E80618-01
  Go To Table Of Contents
Contents

Previous
Previous
 
Next
Next
 

13 Pre-Implementation Considerations

Before the RSB is installed in an enterprise, there are many factors that need to be considered. Planning and addressing each of the factors will avoid having to reinstall or re-architect because of performance or operational problems.

The process of RSB implementation requires the creation or modification of a retailer's Enterprise Integration Architecture. Typically, retailers will already have an integration strategy, plan or architecture and products in place to integrate their current systems.

Life-cycle Management

Software applications, after being made generally available (GA), have a well defined lifecycle process. The implementer must manage and perform tasks in these phases.

  • Acquire the software components

  • Prepare the environment

  • Assemble the application

  • Deploy and start the application

  • Perform day-to-day monitoring to make sure the application is running properly

  • Apply code fixes to the application

Surrounding text describes image015.png.

RSB supports and follows the RSB Software Lifecycle Management, a well-defined process life cycle that has implemented specific tools and functionality for each of these phases.

  • Preparation Phase: In this phase all relevant components are downloaded, extracted configured, and version compatibility checks done.

  • Application Assembly Phase: In this phase, site specific configuration changes are completed. All the relevant RSB decorators and service integration flows are generated.

  • Deployment Phase: In this phase, using the decorators and administration application created in the previous step and the site specific information present in a global configuration file, the decorators and applications are deployed to the application server instances.

  • Operations Phase: In this phase, day-to-day operations of the decorator applications are performed.

  • Maintenance Phase: In this phase, code fixes, patching and configuration changes and maintenance of the RSB are performed.

High Availability Considerations

As businesses are maturing and having to do everything quicker, better, faster, and with less resource and money they are pushing similar expectation onto their IT infrastructure. Business users are expecting more out of their IT investments, with zero down time, consistent predictable responding systems which are highly available has become basic requirements of today's business applications.

Modern business application requirements are classified by the abilities that the system must provide. This list of abilities such as availability, scalability, reliability, auditability, recoverability, portability, manageability, and maintainability determine the success or failure of a business.

With a clustered system many of these business requirement abilities gets addressed without having to do lots of development work within the business application. Clustering directly address availability, scalability, recoverability requirements which is very attractive to a business. In reality though it is a trade-off, clustered system increases complexity, is normally more difficult to manage and secure and so one should evaluate the pros and cons before deciding to use clustering.

Oracle provides many clustering solutions and options; those relevant to RSB are WebLogic server clusters and Oracle database cluster (RAC).

WebLogic Server Cluster Concepts

A WebLogic server cluster consists of multiple WebLogic server instances running simultaneously and working together to provide increased scalability and reliability. A cluster appears to clients to be a single WebLogic server instance. The server instances that constitute a cluster can run on the same machine, or be located on different machines. You can increase a cluster's capacity by adding additional server instances to the cluster on an existing machine, or you can add machines to the cluster to host the incremental server instances. Each server instance in a cluster must run the same version of WebLogic Server.

In an active-passive configuration the passive components are only used when the active component fails. Active-passive solutions deploy an active instance that handles requests and a passive instance that is on standby. In addition, a heartbeat mechanism is usually set up between these two instances together with a hardware cluster (such as Sun Cluster, Veritas, RedHat Cluster Manager, and Oracle CRS) agent so that when the active instance fails, the agent shuts down the active instance completely, brings up the passive instance, and resumes application services.

In an active-active model all equivalent members are active and none are on standby. All instances handle requests concurrently.

An active-active system generally provides higher transparency to consumers and has a greater scalability than an active-passive system. On the other hand, the operational and licensing costs of an active-passive model are lower than that of an active-active deployment.

Surrounding text describes image016.gif.

Note:

See also Oracle® Fusion Middleware Using Clusters for Oracle WebLogic Server.

Oracle Database Cluster (RAC) Concepts

A cluster comprises multiple interconnected computers or servers that appear as if they are one server to end users and applications. Oracle Database Real Application Clusters (Oracle RAC) enables the clustering of the Oracle database. Oracle RAC uses Oracle Clusterware for the infrastructure to bind multiple servers so that they operate as a single system.

Single-instance Oracle databases have a one-to-one relationship between the Oracle database and the instance. Oracle RAC environments, however, have a one-to-many relationship between the database and instances. In Oracle RAC environments, the cluster database instances access one database. The combined processing power of the multiple servers can provide greater throughput and scalability than is available from a single server. Oracle RAC is the Oracle database option that provides a single system image for multiple servers to access one Oracle database. In Oracle RAC, each Oracle instance usually runs on a separate server.

Oracle RAC technology provides high availability and scalability for all database applications. Having multiple instances access a single database prevents the server from being a single point of failure. Oracle RAC enables capability to combine smaller commodity servers into a cluster to create scalable environments that support mission critical business applications.

Recommended Deployment Options

There are no physical location constraints on where RSB and edge applications are deployed as long as they are visible from the same network. But the decision on where to physically and logically locate your decorators and applications has impact on the high availability, performance and maintainability of your integration solution, so this decision must be given careful consideration.

Cluster Deployment

The supported deployment configuration for RSB is cluster. However, for development purposes non-cluster deployment can be used.

A cluster configuration will have following server instances:

  • AdminServer

  • HTTP Proxy server

  • One or more managed servers

AdminServer is used to manage the cluster. Optionally, you can also use a node manager for startup and shutdown of managed servers.

The HTTP Proxy server acts as the load balancer proxy server for the cluster. The service consumers will connect to the proxy server port. The proxy server will redirect the call to one of the managed servers, depending on the load balancing algorithm chosen at the configuration time. The default load balancing algorithm is round-robin.

Managed servers do the actual work of the service invocation. The decorators are deployed to the managed servers. A cluster can have one or more managed servers. Even though cluster configuration supports one managed server, it really doesn't make sense to have a cluster with single managed server. So for all practical purposes, the minimum number of managed servers must be two. The configuration of all the managed servers in the cluster is same except for one of the managed server. One managed server has a special role of hosting singleton components in addition to being a member of the managed server pool. Typically, this is the first managed server configured in the cluster. There is no user input needed to identify or configure this managed server.

HTTPS Cluster Configurations

If you want the cluster configured for https, you have to do a few additional configurations to make it work in RSB.

  1. Enable https port for AdminServer, Http Proxy Server and all managed servers. Specify the Listen Address. The Listen Address must match the CN entry of the server certificate. Sometimes the CN entry of the server certificate is the fully qualified name (for example, rsbhost.example.com) instead of the short hostname (for example, rsbhost). If the entries do not match, the security configurations will not work. Surrounding text describes image017.jpg.

  2. Set the Front end Host (as wells as HTTP and HTTPS ports, if not configured already) for the cluster. This should match the CN entry of the certificate. Environment > Clusters > [cluster name] > HTTP.

    Surrounding text describes image018.jpg.
  3. Enable Secure Replication Enabled option available in Environment > Clusters > [cluster name] > Replication.

    Surrounding text describes image019.gif.
  4. Enable WebLogic plug-in. Select the WebLogic Plug-In Enabled option in Environment > Clusters > [cluster name] > Advanced.

    Surrounding text describes image020.gif.

Who Should Use This Configuration?

All the production deployments must use the cluster configuration. This configuration is appropriate when the machine hosting WLS is adequately sized for its job. Development environment may use a non-cluster deployment configuration.