Installing the Latest & Greatest

Running SOA Suite 11.1.1.5 on OEL 6

In my last post I set up Oracle 11gR2 on an Oracle Enterprise Linux 6 system hosted in VirtualBox.  In this post I will install SOA Suite onto the same box.

This will give me a complete SOA environment in a single virtual image that has all the latest software, OS, database, Java, App Server and SOA.  Because I am running a 64-bit Linux I will install 64-bit JVMs (multiple for choice and testing) and a generic WebLogic install.

Specifically I will install

I will also run the Repository Creation Utility to create the required schemas in the database.

Additional OS Preparation

Most of the OS configuration was done in preparing it for the database install but I needed to add two more packages in order to run the RCU.  These packages are:

  • libXext.i686
  • libXtst.i686

I added them by using yum:

yum install libXext.i686 libXtst.i686

Creating SOA Repository

Having added the required packages I ran the RCU and installed into my 11gR2 database.  The RCU doesn’t check the client it is executing on, only that the target database server is certified so there were no problems with running the RCU.

Installing Java

Because I am on a 64-bit system I don’t want to use the 32-bit JVMs bundled in the WebLogic install so I started off by installing the JVMs I wanted to use.

Before installing the JVMs I created a Middleware Home directory because I wanted my JVMs to be in the same middleware home as the rest of my installation.  My database installation had created an ORACLE_BASE at “/home/oracle/app/oracle” and an ORACLE_HOME at “$ORACLE_BASE/product/11.2.0/db”.  I decided to use the same ORACLE_BASE and put my MW_HOME at “$ORACLE_BASE/product/FMW” so that my middleware installs would mirror the structure of my database install.

I then changed to that directory and installed the 1.6 HotSpot JVM, the JRockit JVM for Java 6 and the JDK 1.7 JVM.  To make it easier to upgrade in the future I then created symbolic links for the JVMs:

ln –s jrockit-jdk1.6.0_24-R28.1.3-4.0.1 jrockit-jdk1.6

ln -s jdk1.7.0 jdk1.7

ln -s jdk1.6.0_25 jdk1.6

Using symbolic links allows me to install a later version of a JDK and start using it by updating the link.

Installing WebLogic

Having installed the JVMs I was then ready to run the WebLogic installer.  Because I was using a 64-bit JVM I had to run the generic installer which is delivered as an executable jar file.  I added all three of my JVMs to the list of JVMs in WebLogic and made the 1.6 HotSpot JVM the default.  Note that WebLogic identifies the JVMs and follows symbolic links to get to the actual directory.  The 1.7 JDK is identified as an Oracle rather than a Sun JDK because Oracle now own Sun.  Normally if the vendor is Oracle then WebLogic assumes that this is a JRockit JVM.  This will cause a problem later because HotSpot has different parameters to JRockit.

After installing WebLogic I edited $MW_HOME/wlserver_10.3/common/bin/commEnv.sh to refer to the synbolic link for the JVM rather than the actual directory.  This will make it easier in the future to upgrade the JVM.

JAVA_HOME="/home/oracle/app/oracle/product/FMW/jdk1.6"

Installing OSB

Both OSB and SOA Suite use the Oracle Universal Installer to check the platform, required OS parameters and packages of the target system.  Unfortunately OEL 6 is not on the list of expected OS platforms and so the installer fails it pre-requisite checks.  In the DB installer we could choose to ignore failed checks from the GUI.  With the DB and OSB installers you can’t.  So we have two options, ignore the pre-requisite checks or add new ones.  Whichever choice you go with the install of OSB is now straightforward.  I didn’t install the designer because it is currently only built for a 32-bit system.  I will install the designer on a client machine rather than on my server VM.

Option 1 – Ignore Pre-Reqs

You can ignore the installer pre-req check by passing the –ignoreSysPrereqs to the installer

./runInstaller –ignoreSysPrereqs

This has the advantage that it is quick and easy but of course you may actually fail a check because something really is needed and you would never know it.  So that leads us to option 2.

Option 2 – Create New Check for OEL 6

The pre-req checks are held in a file “Disk1/stage/prereq/linux64/refhost.xml” on the installation image.  I added a new <OPERATING-SYSTEM> tag to the <CERTIFIED-SYSTEMS>.  I copied the redhat 5.4 tag and changed the “<VERSION>” “VALUE” attribute to “6.0” and changed the “i386” “ARCHITECTURE” attributes in “<PACKAGE>” elements to “i686”:

    <OPERATING_SYSTEM>
      <VERSION VALUE="6.0"/>
      <ARCHITECTURE VALUE="x86"/>
      <NAME VALUE="Linux"/>
      <VENDOR VALUE="redhat"/>
      <GLIBC ATLEAST="2.5-12">
      </GLIBC>
      <PACKAGES>
              <PACKAGE NAME="binutils" VERSION="2.17.50.0.6" />
          <PACKAGE NAME="compat-libstdc++-33" VERSION="3.2.3" ARCHITECTURE="x86_64" />
          <PACKAGE NAME="compat-libstdc++-33" VERSION="3.2.3" ARCHITECTURE="i686" />
              <PACKAGE NAME="elfutils-libelf" VERSION="0.125" />
              <PACKAGE NAME="elfutils-libelf-devel" VERSION="0.125" />
              <PACKAGE NAME="gcc" VERSION="4.1.1" />
              <PACKAGE NAME="gcc-c++" VERSION="4.1.1" />
              <PACKAGE NAME="glibc" VERSION="2.5-12" ARCHITECTURE="x86_64" />
              <PACKAGE NAME="glibc" VERSION="2.5-12" ARCHITECTURE="i686" />
              <PACKAGE NAME="glibc-common" VERSION="2.5" />
              <PACKAGE NAME="glibc-devel" VERSION="2.5" ARCHITECTURE="x86_64" />
          <PACKAGE NAME="glibc-devel" VERSION="2.5-12" ARCHITECTURE="i686" />
          <PACKAGE NAME="libaio" VERSION="0.3.106" ARCHITECTURE="x86_64" />
          <PACKAGE NAME="libaio" VERSION="0.3.106" ARCHITECTURE="i686" />
              <PACKAGE NAME="libaio-devel" VERSION="0.3.106" />
          <PACKAGE NAME="libgcc" VERSION="4.1.1" ARCHITECTURE="x86_64" />
          <PACKAGE NAME="libgcc" VERSION="4.1.1" ARCHITECTURE="i686" />
          <PACKAGE NAME="libstdc++" VERSION="4.1.1" ARCHITECTURE="x86_64" />
          <PACKAGE NAME="libstdc++" VERSION="4.1.1" ARCHITECTURE="i686" />
          <PACKAGE NAME="libstdc++-devel" VERSION="4.1.1" />
          <PACKAGE NAME="make" VERSION="3.81" />
          <PACKAGE NAME="sysstat" VERSION="7.0.0" />
      </PACKAGES>
      <KERNEL>
<!--
              <PROPERTY NAME="semmsl" NAME2="semmsl2" VALUE="250" />
              <PROPERTY NAME="semmns" VALUE="32000" />
              <PROPERTY NAME="semopm" VALUE="100" />
              <PROPERTY NAME="semmni" VALUE="128" />
              <PROPERTY NAME="shmmax" VALUE="536870912" />
              <PROPERTY NAME="shmmni" VALUE="4096" />
              <PROPERTY NAME="shmall" VALUE="2097152" />
              <PROPERTY NAME="file-max" VALUE="65536" />
              <PROPERTY NAME="ip_local_port_range" ATLEAST="1024" ATMOST="65000" />
              <PROPERTY NAME="rmem_default" VALUE="4194304" />
              <PROPERTY NAME="rmem_max" VALUE="4194304" />
              <PROPERTY NAME="wmem_default" VALUE="262144" />
              <PROPERTY NAME="wmem_max" VALUE="262144" />
-->
              <PROPERTY NAME="VERSION" VALUE="2.6.18"/>
              <PROPERTY NAME="hardnofiles" VALUE="4096"/>
              <PROPERTY NAME="softnofiles" VALUE="4096"/>
      </KERNEL>
    </OPERATING_SYSTEM>

This allows you to run the installer as normal and it will validate the pre-reqs correctly giving you confidence that things are set up correctly in the OS.

Installing SOA Suite

After installing OSB I installed SOA Suite using the same work around for the OS pre-req mismatch as we used for OSB.  At this point I took another snapshot so that I could build different types of domain from the same repository.

Creating a Development Domain

My next step was to create a domain suitable for development with SOA Suite and Service Bus.  I chose the Developer OSB and Developer SOA Suite templates from the domain configuration wizard along with the Enterprise Manager template.  This creates a single server, the AdminServer, that has all the SOA and Service Bus components.  This works well for development environments as it minimizes the memory footprint required by putting everything into a single server.  After creating the domain and starting the AdminServer I fired up jconsole to check the memory usage of the JVM.  I saw that it had committed 1.3GB out of a maximum 1.5GB.  I was surprised to notice that the PermGen was using almost 500MB.  The initial default memory size is 750MB and the maximum is 1.5GB so I changed the memory settings by editing setSOADomainEnv.sh.  I increased the initial memory size to 1.5GB and set the maximum memory size to be 2.5GB by setting the PORT_MEM_ARGS in setSOADomainEnv.sh.  I also modified the initial PermGen size to be 512MB and the maximum PermGen size to be 750MB to ensure I didn’t run out of space for code.

PORT_MEM_ARGS=”-Xms1536m –Xmx2560m”
PORT_MEM_ARGS=”${PORT_MEM_ARGS} -XX:PermSize=512m -XX:MaxPermSize=768m"

Note I used PORT_MEM_ARGS because I was using a 64-bit Linux system.  If it was a 32-bit system then I would have set the DEFAULT_MEM_ARGS.

I then took a snapshot of my virtual image so I can jump straight to a ready to use domain when I need it.

Creating a Production Domain

Having created a development domain that ran in a single server I also wanted a production style domain that had everything I would need for SOA.  I chose the BPM Suite, SOA Suite, Enterprise Manager, Service Bus and Business Activity Monitoring templates for this domain.  I chose production mode for my domain to make it better reflect what customers would have in their production environments.  I accept all the other defaults and created the domain.  This creates separate managed servers for SOA/BPM, BAM and OSB.  Consoles still run in the AdminServer.  Before starting I created a boot.properties file with the following properties:

username=weblogic
password=welcome1

I created the following directories under my domain directory (using “mkdir –p <dirname>”) and put a boot.properties file in each of them.

  • servers/AdminServer/security
  • servers/soa_server1/security
  • servers/bam_server1/security
  • servers/osb_server1/security

I then started the admin server.  While it was starting I ran the “$MW_HOME/oracle_common./common/bin/setNMProps.sh” script to enable Node Manager to start the managed servers.  I then started the Node Manager.

With the node manager running I was able to check the consoles were working fine and then I noticed that the OSB server was not targeted at a machine and so could not be started by node manager.  I targeted “osb_server1” at the default “LocalMachine” and then started the managed servers.

After verifying that all was well with the managed servers I shutdown the machine and took a snapshot.

A Solid Base

I use this kind of VM configuration all the time because I can always create a new domain from the base software to match my exact requirements.  But most of the time I can use one of the existing domains.  Although it is quite heavy on disk it is more efficient than having multiple images.  Hope you find this useful.

Comments:

Thanks for this Antony - it's great to have all the instructions for a laptop VM in one post. I'm also glad that Oracle have released PS4 for SOA as a full installer again as it's much easier than having to patch up a base release... long may it continue! (and spread to other OFM products)

Posted by guest on May 17, 2011 at 07:34 AM MDT #

Hi Antony, I thought that, at least with earlier versions of the WebLogic Server installer, symbolic links were dereferenced at install-time, so the actual path winds up embedded in places like setDomainEnv.sh. Perhaps I'm mis-remembering, but I had tried exactly your approach, and found myself having to change config files in order to use a different JVM. Cheers, Geoff.

Posted by Geoff on May 18, 2011 at 12:23 PM MDT #

Geoff, You are correct that symbolic links are de-referenced by WebLogic. But only in the installer. If you alter the commEnv.sh script then when you create a domain it will use the symbolic link rather than the physical link. Antony

Posted by Antony on May 18, 2011 at 11:02 PM MDT #

FWIW I always install the JDK(s) outside the MW_HOME and just reference the full path in the installer. Then I can easily upgrade each domain to a new version later in the setDomainEnv.sh.

Posted by Simon Haslam on May 18, 2011 at 11:33 PM MDT #

Thanks for your postings.

I wondered if this VM was available for download for people like me that are architects and are not skilled administrators.

Posted by guest on August 04, 2011 at 12:25 AM MDT #

Hi Anthony,

I have one quick question, Is it possible to have the Repository in AIX while maintaining FMW stack on OEL 5.6 or equivalent ?

Regards,

Makarand

Posted by guest on September 12, 2011 at 04:44 AM MDT #

Makarand

I don't see why not - providing both ends are on supported versions of the platforms (see SOA sections of FMW certification matrix at http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html). In fact the database requirements aren't very challenging for lab environments like this - using Oracle XE for the repository should be fine (I think a few minor workarounds were required but am not sure with the latest patchset).

HTH

Simon

Posted by Simon Haslam on September 23, 2011 at 09:34 AM MDT #

The repository can be in any supported database version on any platform supported for that database version. However the Repository Creation Utility (RCU) must be run from Windows or Linux, although it can populate a remote database on AIX for example.

Antony

Posted by Antony on October 11, 2011 at 05:17 AM MDT #

Hi Antony,

I'm having trouble running the RCU and was hoping you could point me in the right direction. I've google'd all manner of useless info. I'm getting the error "..../rcuHome/jdk/jre/lib/i386/xawt/libmawt.so: libXext.so.6: cannot open shared object file: No such file or directory"

I've run "rpm -qa | grep libXext" and found "libXext-1.1-3.el6.x86_64", so it's my understanding that libXext.so.6 is installed (since it's in /usr/lib64)

Thanks in Advance :)
Eric

Posted by Eric on December 16, 2011 at 07:32 AM MST #

By the time the moderator posted my comment / request for help, I was able to resolve the issues.

Posted Dec 16th - posting shown Dec 29th

Thank you,
Eric

Posted by Eric on December 29, 2011 at 02:42 AM MST #

Post a Comment:
Comments are closed for this entry.
About

Musings on Fusion Middleware and SOA Picture of Antony Antony works with customers across the US and Canada in implementing SOA and other Fusion Middleware solutions. Antony is the co-author of the SOA Suite 11g Developers Cookbook, the SOA Suite 11g Developers Guide and the SOA Suite Developers Guide.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today