A Case for Upgrading to SOA Suite 11gR1
By Reza Shafii on Jan 18, 2010
During the past year and a half, my main preoccupation as part of the Fusion Middleware platform product management team has been to define and execute a suitable upgrade and interoperability strategy. The main goal of the upgrade strategy has been to ensure that the 11gR1 release of Fusion Middleware, which came out last summer, provides a smooth upgrade path for our OracleAS 10g customers. One of the challenges to this goal was the change from Oracle Containers for J2EE (OC4J) as the underlying Java EE application server for 10g products to the Oracle WebLogic Server in 11g. As it should hopefully be obvious from the material available on the OTN Fusion Middleware Upgrade Center, the Fusion Middleware 11gR1 upgrade process makes the change in the underlying Java EE application server nearly transparent and furthermore greatly simplifies the upgrade process for all of the 11gR1 products including Oracle SOA Suite, WebCenter, IDM, Portal, Reports, and Forms.
In my experience when describing our upgrade strategy, once the simplicity of the process is understood, some of the main questions that come up are with regards to the business reasons for going through the upgrade of existing systems which might currently be stable and performing their tasks as required. The short answer to such questions is of course that the new capabilities provided by the 11gR1 version of Fusion Middleware products will lead to the high level benefits of increase in quality of service and return on investments while decreasing total cost of ownership. There are a great deal of technical facts supporting this answer - with many resulting from the large array of new capabilities provided by WebLogic Server Suite - which I might have a chance to explore in more details in upcoming posts. In this post however, I would like to go over some specific benefits which became very obvious to me while I was recently preparing the following slide on the comparison of topologies between SOA Suite 10g and 11gR1.
This slide illustrates a comparison of the installation, configuration, and runtime topologies between the 10g and 11gR1 SOA Suit components. Let's briefly discuss each of these areas and the benefits which result from the 11g layout when compared to 10g.
On the installation side, in 10g, the product bits for the three components involved had to be laid out in separate Oracle Home directories. In 11g, the SOA Suite installation lays down all three products within a single Oracle Home. This consolidation clearly simplifies maintenance tasks such provisioning, patching, and backup of the product installation. Also note that Oracle BAM 11gR1 is now fully Java EE based and can therefore be installed on the same wide range of platforms as the rest of the Oracle SOA Suite components thus removing the Windows only restriction that was present with BAM 10g and allowing for OS platform consolidation.
On the configuration front, two important changes are worth highlighting. First, a SOA Suite 11gR1 installation can be used to configure multiple SOA WebLogic Server domains as opposed to SOA Suite 10g installations which were always associated with a single server configuration. This capability is by virtue of the WebLogic Server domain feature which, for those not familiar with the concept, is compared and contrasted with OC4J server configurations in the "General WebLogic Server Concepts for OC4J Users" section of this white paper which I wrote last year. This clear separation of installation bits from configuration data brings two important benefits. First of all, the maintenance of a product installation (such as for example the application of an Oracle patch) can be performed once and take effect for all domains which stem from this install. Second, it allows for greater agility in the provisioning (and de-provisioning) of server configurations as domains can easily be created and deleted without requiring an install and/or de-install of the product's binaries. In environments with high churn such as dev and QA, these benefits can easily translate to highly significant efficiency gains.
The consolidation of all SOA components (including BPEL/ESB, B2B, and BAM) within a single domain is the second important change from 10g from a configuration point of view. As a result of this change all SOA components can be centrally managed as part of the WebLogic Server domain encompassing them. This includes the ability to provision the components configuration changes and scale-outs through a single set of WebLogic Scripting Tool (WLST) scripts and the ability to backup, secure, and modify the server's configurations through the central location of their domain directory.
Finally, on the runtime front, the consolidation of the SOA components within a single domain not only allows for a central and consistent runtime management scheme, but it also enables specific optimizations which were previously not possible. In terms of the runtime management, the SOA domain's Enterprise Manager Fusion Middleware Control console provides a single point of management and monitoring of all of the SOA components including BPEL/ESB, BAM, and B2B. This is in contrast to the three separated runtime management tools that would have been required in 10g. Again, this consolidated administrative approach should not only allow for a more efficient management of the SOA server components but also facilitate the detection of runtime issues through centralized monitoring, which should in turn lead to a higher quality of service.
In terms of optimizations, BPEL PM processes can now integrate with a B2B server residing within the same domain using an optimized protocol through the B2B SCA service. The implementation for this service senses environments where BPEL PM and B2B are deployed on the same WebLogic managed server (which is the default configuration) and in such cases uses in-memory communication. This is in contrast to SOA 10g where JMS/AQ integration with B2B was required in all cases.
As you can see, the tight installation, configuration, and runtime integration between the SOA Suite 11gR1 components leads to many benefits that can fairly easily be tied to business value and thus contribute, along with the benefits that can be achieved by all of the new features available in 11gR1, to the case for upgrading from SOA Suite 10g.