First, let me start by saying that this post isn’t about how to install and configure JDeveloper and WebCenter. There’s plenty of material out there on JDeveloper standards and WebCenter installation and configuration. Rather this post discusses where the software lives, the various development configuration options, and how to pick the one most effective for your circumstance.
Configuration 1 – Everything installed locally
In this configuration, everything you need to run WebCenter is installed locally: WebLogic Server, WebCenter Portal and Content, JDeveloper, and the database. You need a pretty beefy machine for this configuration, 16GB of RAM at a minimum. But there are other things to consider besides the heft of the machine. One is that you most likely can support only one version of WebCenter. Second, most production systems run WebCenter on Linux, so if you have a Windows PC this setup may introduce enough differences to cause support issues. On the upside, your environment is completely self-contained, with no external dependencies. This setup is best suited for those with a powerhouse machine who are just kicking the tires and/or support a single application, and plan to do a significant portion of their development off-line, disconnected from other environments and points of integration.
Configuration 2 – JDeveloper installed locally with WebCenter installed in an on-premise data center
In this configuration, only JDeveloper is installed locally. Everything else is installed on a development server(s) within an on-premise data center. The development machine only needs to be robust enough to run JDeveloper (4GB RAM), and since multiple versions of JDeveloper can be installed on a single system (ie: 11g, 12c) , multiple variations of WebCenter can be supported, should your development environment make them available. You may also benefit in that the development environment may include points of integration and dependencies (an authentication source for instance) not available had you installed everything locally. This setup is best suited for those where an on-premise development environment is provided (and/or mandated) by your organization or client, and connectivity to it is available. For those working remotely, often a dedicated development machine is left on-site, directly connected to the development network, and a second machine is used by the developer to create a remote desktop session to it via a secure VPN connection.
Configuration 3 – JDeveloper installed locally with WebCenter in the cloud.
This configuration, is similar to configuration 2 in that only JDeveloper is installed locally. It differs in that WebCenter is installed within a cloud provider such as Oracle’s Cloud Service or Amazon Web Service (AWS). Like configuration 2, the development machine only needs to be robust enough to run one or more versions of JDeveloper, multiple variations of WebCenter can be supported, and the cloud setup may include other points of integration not available locally. It differs, however, in that developers can connect directly to the cloud-based environment from anywhere. VPN connections to dedicated development machines physically on the development network typically won’t be required. Also, with a cloud based setup one can create image snapshots very easily. Then they can startup and shutdown WebCenter instances based on those snapshots. This make it much easier to support multiple systems at various points in time. I prefer this option over configurations 1 and 2, however it requires that your organization have an officially sanctioned cloud-based development environment available for use.
Configuration 4 – Everything in a self-contained local virtual machine.
Much like configuration 1, everything is self-contained in a single machine. The machine, however, is a virtual machine (VM) that runs within virtualization software on the developer’s local PC. The only software required is the virtualization software required to run the VM. I suggest using Oracle’s own VirtualBox. They even have a pre-built WebCenter VM so you don’t have to spend time install a bunch of complicated software, allowing you to get right to development. Need a different version, or a very specific setup? You can built your own VM from scratch, from the OS up. You’ll need a very hefty machine to run your WebCenter VMs. A running VM instance requires 12GB of RAM or more. This configuration make it easy to maintain many WebCenter VMs locally. I have VMs for WebCenter versions 11.1.1.7, 11.1.1.8, 11.1.1.9 and 12c saved off on my personal portable expansion drive. I word to the wise though, avoid running the VM from your portable expansion drive. Always copy it to your local hard drive (preferably SSHD) before running, as it’s quite IO intensive. Once my VM local development is complete I can upload my changes to the next upstream environment for integration and/or testing. I find this setup the most efficient and flexible of the four.
