ADF Runtimes vs WLS versions as of JDeveloper 220.127.116.11.0
By Chris Muir-Oracle on Mar 09, 2012
The following blog post attempts to give Oracle WebLogic Server (WLS) administrators and Oracle Application Development Framework (ADF) customers some guidance of the pairing of ADF Runtime versions to WLS, in order to assist future planning and project management.
The blog post discusses two different branches of Oracle's JDeveloper, namely the 11.1.1.X.0 branch including versions 18.104.22.168.0 through the current 22.214.171.124.0, and separately the 11.1.2.X.0 branch including 126.96.36.199.0 through the current 188.8.131.52.0. In reading this post readers must be clear on the two different branches.
The recent Oracle JDeveloper 184.108.40.206.0 release shows a small change in Oracle's pairing of ADF Runtimes versions to WebLogic Server which WLS administrators should be aware of.
Since the inception of JDeveloper 11g each new release has required a new version of WLS too. For example:
- ADF Runtimes 220.127.116.11.0 required WLS 10.3.1
- ADF Runtimes 18.104.22.168.0 required WLS 10.3.2
- ADF Runtimes 22.214.171.124.0 required WLS 10.3.3
- ADF Runtimes 126.96.36.199.0 required WLS 10.3.4
- ADF Runtimes 188.8.131.52.0 required WLS 10.3.5
This "history" is articulated in summary form in the 184.108.40.206.0 Certification and Support Matrix under the Application Server heading.
Note with the release of JDeveloper 220.127.116.11.0 there is a subtle change in the ADF Runtime to WLS version pairing. The latest ADF Runtimes 18.104.22.168.0 can run against WLS 10.3.6 and 10.3.5. This is the first time in the 11.1.1.X branch we've seen a version run on two versions of WLS. As such if you have a 10.3.5 WLS server or have just installed WLS 10.3.6 you can also happily install the 22.214.171.124.0 ADF Runtimes on either.
Customers need to be careful though as this does not imply the opposite. If you install WLS 10.3.6, only the ADF Runtimes 126.96.36.199.0 are certified, the 188.8.131.52.0 ADF Runtimes are not (though the 184.108.40.206.0 ADF Runtimes are still of course certified against WLS 10.3.5).
While I'm not in a position to comment publicly in detail on future JDeveloper versions beyond those revealed in the roadmaps at OOW, in terms of future releases in the 11.1.1.X.0 branch you should see this trend continue (note the italics on "should", there's no guarantees), namely the 220.127.116.11.0+ runtimes running on both WLS 10.3.5 and WLS 10.3.6. Obviously to customers having some indication of the trend here is useful, as in previous releases customers had to build a new set of WLS servers for each JDeveloper 11.1.1.X.0 release which was considerable effort.
On considering the other 11.1.2.X.0 branch of JDeveloper, as per it's Certification and Support Matrix, the current requirement is a WLS 10.3.5 server with the ADF Runtimes 18.104.22.168.0 installed and a ADF Runtime 11.1.2.X.0 patch applied over the top.
Observant readers referring to Oracle's roadmap from OOW will note the upcoming 12c JDeveloper release. There are no specifics I can give on versions and release dates at all, but it is reasonable to say the ADF 12c runtimes will only run on WLS 12c, not WLS 10.3.X. There is no information available beyond the general release numbers, so readers should not assume any of the existing or future WLS 12c versions will be satisfactory at this time for ADF 12c - essentially this is to-be-advised at the official release. The only thing to take from this last paragraph is the 12c release of JDeveloper will require a new stripe of 12c WLS servers, which should assist your future planning efforts if you wish to move to that platform when available.
For customers interested in Fusion Middleware (FMW) including SOA Suite etc over ADF, note the same rules apply across the board. However I recognize my reader base is mostly ADF developers thus my focus on the ADF Runtimes.
If there's anything unclear in the explanation or in the Certification and Support Matrixes please leave a comment and we'll endeavour to rectify this.
Thanks to Brian Fry with his assistance on this blog post.