Well 184.108.40.206 is now available for download so I thought I would build a Windows Server environment to run it. I will minimize the memory footprint of the installation by putting all functionality into the Admin Server of the SOA Suite domain.
If possible I recommend installing a 64-bit JDK as this allows you to assign more memory to individual JVMs.
Windows XE will work, but it is better if you can use a full Oracle database because of the limitations on XE that sometimes cause it to run out of space with large or multiple SOA deployments.
The following flow chart outlines the steps required in installing and configuring SOA Suite.
The steps in the diagram are explained below.
Is a 64-bit installation required? The Windows & Linux installers will install 32-bit versions of the Sun JDK and JRockit. A separate JDK must be installed for 64-bit.
If you are using 64-bit then install WebLogic using “java –jar wls1036_generic.jar”. Make sure you include Coherence in the installation, the easiest way to do this is to accept the “Typical” installation.
If you are not installing SOA Suite then you can jump straight ahead and create a WebLogic domain.
Run the SOA Suite installer and point it at the existing Middleware Home created for WebLogic. Note to run the SOA installer on Windows the user must have admin privileges. I also found that on Windows Server 2008R2 I had to start the installer from a command prompt with administrative privileges, granting it privileges when it ran caused it to ignore the jreLoc parameter.
Do you have access to a database into which you can install the SOA schema. SOA Suite requires access to an Oracle database (it is supported on other databases but I would always use an oracle database).
I use an 11gR2 Oracle database to avoid XE limitations. Make sure that you set the database character set to be unicode (AL32UTF8). I also disabled the new security settings because they get in the way for a developer database. Don’t forget to check that number of processes is at least 150 and number of sessions is not set, or is set to at least 200 (in the DB init parameters).
The SOA Suite database schemas are created by running the Repository Creation Utility. Install the “SOA and BPM Infrastructure” component to support SOA Suite. If you keep the schema prefix as “DEV” then the config wizard is easier to complete.
The Config wizard creates the domain which hosts the WebLogic server instances. To get a minimum footprint SOA installation choose the “Oracle Enterprise Manager” and “Oracle SOA Suite for developers” products. All other required products will be automatically selected.
The “for developers” installs target the appropriate components at the AdminServer rather than creating a separate managed server to house them. This reduces the number of JVMs required to run the system and hence the amount of memory required. This is not suitable for anything other than a developer environment as it mixes the admin and runtime functions together in a single server. It also takes a long time to load all the required modules, making start up a slow process.
If it exists I would recommend running the config wizard found in the “oracle_common/common/bin” directory under the middleware home. This should have access to all the templates, including SOA.
If you also want to run BAM in the same JVM as everything else then you need to “Select Optional Configuration” for “Managed Servers, Clusters and Machines”.
To target BAM at the AdminServer delete the “bam_server1” managed server that is created by default. This will result in BAM being targeted at the AdminServer.
I had a few problems when I came to test everything in my mega-JVM.
On a Windows 2008R2 Server running under VirtualBox I was able to bring up both the 11gR2 database and SOA/BPM/BAM in 3G memory. I allocated a minimum 512M to the PermGen and a minimum of 1.5G for the heap. The setting from setSOADomainEnv are shown below:
set DEFAULT_MEM_ARGS=-Xms1536m -Xmx2048m
set PORT_MEM_ARGS=-Xms1536m -Xmx2048m
set DEFAULT_MEM_ARGS=%DEFAULT_MEM_ARGS% -XX:PermSize=512m -XX:MaxPermSize=768m
set PORT_MEM_ARGS=%PORT_MEM_ARGS% -XX:PermSize=512m -XX:MaxPermSize=768m
I arrived at these numbers by monitoring JVM memory usage in JConsole.
Task Manager showed total system memory usage at 2.9G – just below the 3G I allocated to the VM.
Performance is not stellar but it runs and I could run JDeveloper alongside it on my 8G laptop, so in that sense it was a result!