Using Oracle’s Edition-Based Redefinition to support multiple SOA Suite revisions with the database adapter

When using the Oracle SOA Suite for web service development, chances are that you are also using an Oracle database and that you are at some point in need of a database adapter in one of your SOA composites. If that happens to be the case, you might also encounter the requirement to support multiple composite revisions and keep them as stabile as possible.
This requirement leads to development of multiple SOA composite revisions, but there is only one database. What if you need more database functionality in your new revision? And let’s say, for example, the package specification you are using in the database adapter needs to change. Is that going to be a problem or can you also have multiple database versions? Normally if the package specification changes the older composite revision will fail and you do have a problem in supporting multiple composite revisions. If you are working with an Oracle Database 11g Release 2 or higher one of its killer features, Edition-Based Redefinition, could provide a solution!

This feature was introduced to the database for hot deployment. It is meant to reduce or eliminate application upgrade down-time, as the Oracle documentation explains it (http://docs.oracle.com/cd/E11882_01/appdev.112/e10471/adfns_editions.htm#ADFNS0201).
With EBR it is possible to create multiple releases of your software in the database. When you create a new edition you can install the same software a second time (or more) in the same database without changing the older version of that same software. For hot deployment this means that a new release can be installed in the database next to the current situation and as soon as the new release is installed correctly the old release can be removed from the database. For more details on EBR I’d like to refer to the Oracle documentation.

In the decoupled world of services you don’t know anymore who is using your service. Sometimes that requires a longer co-existence of an older version of the service next to a new version. When installing the database software for the new service version there is a risk that is somehow changes the functionality of the old version(s). To keep the old version(s) untouched is to keep the associated database software untouched.
With EBR the associated database software can be left untouched. You install a new edition next to existing edition and you create a new data source for the database adapter in the new service version. The option ‘ InitSQL’ for the data source configuration on the Weblogic Service allow you to connect the right edition with an alter session statement.

In the end there is no 100% guarantee that the functionality of the older services won’t change with a new version. There is only one truth in the database and that is the data in the tables. If the tables change drastically there is no way to avoid upgrading or dropping the older version of the service.
If you have the possibility to reinstall the editioning views of the older edition(s), EBR does offer you the chance to change the naming conventions of your tables or do some other changes in your tables (perhaps for a new edition) without too much hassle of persevering those changes in the rest of the database software.

Using EBR for multiple versions of web services has some disadvantages too of course. In the current release of EBR it is possible to have only one child edition of a parent edition. And it is not possible to drop an edition if the edition has a parent and a child edition. Therefore it is not convenient to completely drop and recreate your edition if you need to reinstall an older version of your service. The best you can do to ‘uninstall’ edition is to retire the edition if the edition has a parent and a child edition. Hopefully this will get better in future database releases.
And as mentioned before, you need to create a new data source for every web service version to connect to the right database edition. With wlst scripting you can automate the creation of the data sources. For deployment the data source can be configured in the configuration plan. But performance might not be ideal depending on how much data sources your situation will be needing.

With Oracle Edition Based Redefinition it is possible to maximize database support for multiple SOA Suite revisions in a clear, straightforward way. If it suits your situation, this might be something to think about when you are working with an Oracle database and Oracle SOA Suite.

Resources

• Oracle® Database Advanced Application Developer’s Guide 11g Release 2 (11.2), Chapter 19 Edition-Based Redefinition
  http://docs.oracle.com/cd/E11882_01/appdev.112/e10471/adfns_editions.htm#ADFNS0201
• Configuring and Managing WebLogic JDBC Data Source: Connection Pool
  http://docs.oracle.com/cd/E15051_01/wls/docs103/ConsoleHelp/pagehelp/JDBCjdbcdatasourcesjdbcdatasourceconfigconnectionpooltitle.html
• Oracle® Fusion Middleware Developer’s Guide for Oracle SOA Suite 11g Release 1 (11.1.1.5.0), Chapter 40 Deploying SOA Composite Applications
  http://docs.oracle.com/cd/E21764_01/integration.1111/e10224/sca_lifecycle.htm
• Quick introduction of what and why of Oracle Database Edition Based Redefinition, Lucas Jellema
  https://technology.amis.nl/2012/08/08/quick-introduction-of-what-and-why-of-oracle-database-edition-based-redefinition/
• Choosing the best way for SOA Suite and Oracle Service Bus to interact with the Oracle Database, Lucas Jellema
  https://technology.amis.nl/2011/06/21/choosing-the-best-way-for-soa-suite-and-oracle-service-bus-to-interact-with-the-oracle-database/