Installing Oracle SOA Suite 11gR1 on Windows XP

Keywords: Oracle SOA Suite, 11gR1, Microsoft Windows XP, Oracle Database 10g Express Edition,
XE, WebLogic, Service Oriented Architecture, SOA, Repository Creation Utility, RCU, Oracle
Fusion Middleware, Services, Java Access Bridge, Loopback adapter.

This article is mainly concerned with Oracle SOA (Service Oriented Architecture) Suite 11gR1
installation on Microsoft Windows XP, service pack 3 platform. It is for reference purpose, as I
practically carried out the necessary steps for the installation, and also made a note of the difficulties
faced at each step, as I also include the steps to overcome these problems as a part of this
documentation. In depth discussion and administrative concepts of SOA, WebLogic Server, Oracle
Database and Oracle Fusion Middleware are not being dealt here, as ample documentation regarding
these are already available.

Oracle SOA Suite is a middleware component of Oracle Fusion Middleware, and provides complete
set of infrastructure required for designing, deploying and managing SOA composites. Oracle Fusion
Middleware is based on the three emerging trends in the field of information technology. These are,
Service Oriented Architecture (SOA), Grid Computing Architecture (GCA) and Enterprise Information
Architecture (EIA). As more and more businesses move towards a service oriented architecture in
which, “Services” are built instead of “Applications” and these “Services” are exposed, so that they can
be reused in developing composite applications and complex business processes as and when required,
instead of recoding every time whenever there is a change in business processes/policies, and thereby
providing flexibility and agility to the entire system. This can be rather considered as an “Application
Grid” where loosely coupled “Services” (by “Services”, it is meant to be a unit of work which is a part
of a complex business process), and “Applications” exposed as “Services” are present whose services
can be tapped whenever required, without being considered about where these “Services” actually
reside. That is, the “Services” are aware or the presence of other “Services”, and they can interact
among themselves too, but they are not dependent on each other for their operation. Absence of one
“Service” does not affect another “Service”. A mere knowledge of the presence of the required
“Service” is enough. They are loose coupled. It is exactly like an infrastructure grid, just that the
“infrastructures” like printers and other such hardware components are replaced here by “Services”
which are nothing but a software component/implementation.

The installation of SOA Suite requires an Oracle database already up and running. This is the first
and the most important prerequisite. Any Oracle database can be used, most preferably Oracle Database
10g or 11g. However for this installation, I used Oracle Database 10g Express Edition which is a small
footprint database based on the 10g R2 code, and comes handy for use by developers and DBAs. This
Oracle database is required because the installation of Oracle SOA Suite requires some schemas to be
already present in a database, which acts as the metadata repository for the SOA suite components. The
Oracle Database 10g XE can be downloaded from the URL provided below:

http://www.oracle.com/technology/software/products/database/xe/index.html

The installation of Oracle Database 10g Express Edition (XE) is very simple. Following and during
the installation, it is necessary to note down some information like the database listener port, the
database name, and the service name. These will be required in the later stages of the installation
process. If not noted during the installation, these information can also be extracted from the
listener.ora and tnsnames.ora files present in the app\oracle\product\10.2.0\server\NETWORK\ADMIN
directory under Oracle Home. Generally the service name is same as that of the database name. For me
it is 'XE'. The default database listener port is always 1521.
 After the database installation is over, try logging into the database by using the following statement
from the DOS command prompt: SQLPLUS “/AS SYSDBA” after navigating to the appropriate Oracle
Home. This connects to the database as a SYSDBA, and lets you make any administrative
modification. One thing that can be done is to change the password for the SYS user, in case you do not
remember the default one. This can be done by

ALTER USER SYS IDENTIFIED BY <new_password>;

The SYS password will again be required in later stages of the installation process, perticularly
while using RCU. Again, make sure that the database is up before continuing.

The Oracle SOA Suite requires some default schemas to be present in the database which acts as the
metadata repository for the SOA Suite components, as has been mentioned before. The schemas
required are MDS, SOAINFRA, ORASDPM, and ORABAM. Of these, MDS and ORASDPM are
required by both SOA Suite and BAM (Business Activity Monitoring), SOAINFRA is required by SOA
Suite and ORABAM by Oracle BAM. These schemas cannot be created using CREATE USER SQL
statement, because these schemas are not just schemas, but they are supposed to contain a large number
of database objects (tables and views) build into them for storing the information, vital for the SOA
Suite components operation.

To create these schemas, one requires a RCU (Repository Creation Utility). This RCU does not
come along with the SOA suite distribution. At least I did not get it along with the distribution which I
downloaded from the Oracle Technology Network (OTN). So, I had to download it separately from the
following location:

http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html

To create the above mentioned schemas, unzip the RCU distribution and navigate to the
rcuHome/BIN directory from the DOS command prompt. Execute the rcu.bat batch file. This provides
a GUI where it asks for the following information:

Database Type
Host Name (for me it is localhost since I am installing it in my laptop)
Port (the DB listener port. Default is 1521)
Service Name (check listener.ora and tnsnames.ora. For me, it is XE)
Username (User with DBA or SYSDBA privilege)
Password (SYS password)
Role (SYSDBA)

These are the database connection details which are required by the RCU to connect to the specified
database and create the repository for Oracle SOA Suite and Oracle BAM. An user with SYSDBA
privilege is required because it is only the user with SYSDBA privilege who is allowed to create
schemas in a database.

After the information has been provided, the RCU asks for the repository components. Here it is
required to specify the schemas which are to be created in the database. Expand the “SOA
Infrastructure” component to find SOAINFRA, ORASDPM, and ORABAM. A prefix automatically
gets attached to the schema names. The default prefix is DEV. So, the schema names become
DEV_SOAINFRA etc.

One more schema is required, which is the Metadata Services or MDS. This can be found by
expanding the “Oracle AS Repository Components”.

At one point, while running the RCU, an error message is displayed which shows that the number of
processes expected is 200, which actual is 40. This happens with Oracle Database 10g XE. It is a
problem with the initialization parameters of the Oracle Database 10g XE where the parameter
PROCESSES have a value set to 40. Don't do anything to the RCU GUI. Let it be as it is because the
repository creation can be continued from this point onwards, once the issue with the PROCESSES
parameter is resolved.

To overcome the problem shown by the RCU error message, it is necessary to change the
PROCESSES initialization parameter for the database. For that, first create a init<DBNAME>.ora
parameter file, where DBNAME is the database name, which in my case is “xe”. This can be done by
issuing the following statement at the SQL command prompt

CREATE PFILE= '<PATH>' FROM SPFILE;

This will create the PFILE at the path name specified. Open this file using a text editor, and make a
new entry as PROCESSES=200 (if the entry is already not present) in exactly the same manner as the
rest of the parameters. For me, there was a '*.' before every parameter and so I also preserved while I
made the PROCESSES parameter entry. Next, shutdown the database using the following command.

SHUTDOWN IMMEDIATE;

After that, the database has to be started up using the parameter file (PFILE) so that the parameters
defined there take immediate effect. If the PFILE is not mentioned, it takes the initialization parameters
from the server parameter file by default. This is done using the following command.

STARTUP PFILE= '<PATH>'

Now, it is necessary to recreate the SPFILE so that the changes take effect in the SPFILE as well, so
that the next time when the database is bounced, it is not necessary to specify the PFILE location. In
fact, creation of the SPFILE is always preferred because whenever a database is started by using the
command STARTUP, it will always look for the SPFILE first, for the initialization parameters, and if
found, it will never look for the PFILE. If the SPFILE is not found, it then goes on to search for the
PFILE (init<DBNAME>.ora), but it will search for it only in the default location where it is supposed
to reside. In case the PFILE (init<DBNAME>.ora) is located somewhere else, or if it has a different
name, Oracle Database will not be able to detect the file. So, making a SPFILE makes sure that the
database can be started up even without the PFILE present anywhere. SPFILE is created in a similar
manner as the PFILE.

CREATE SPFILE FROM PFILE='<PATH>;

No location for the SPFILE has to be mentioned. Let the database create the SPFILE in its default
location with the default name so that it can easily track it the next time it is bounced.

After the SPFILE creation, bounce the database again so that it makes use of the SPFILE to start
rather than the PFILE.

SHUTDOWN IMMEDIATE

STARTUP

A point to be noted is that, the SPFILE should never be modified. In fact, it should not be touched.
Opening a SPFILE with a text editor can corrupt the file, and in case there is no PFILE, it may not be
possible to bring up the database. To modify the SPFILE, always create a PFILE and then recreate the
SPFILE back as stated above.

After the changes, continue with the RCU. It should not give any error now.

While running the RCU, at one point it may show an error message that the database is not
supported. Just ignore the message and continue with the repository creation process.

Clicking next goes on to create the necessary tablespaces (a default and a temporary) for the
specified schemas. One can easily check the tablespaces created by connecting to the database as
SYSDBA and then checking the V$TABLESPACE table.

The next step in the SOA Suite installation process is to install an Oracle WebLogic Server. Oracle
WebLogic Server 11gR1 (10.3.1) can be downloaded from OTN via the following link:

http://www.oracle.com/technology/software/products/ias/htdocs/wls_main.html

I however downloaded the software from Oracle SAC, which is an Oracle software repository for
internal use accessible to Oracle employees.

Unzip the zip file and execute the wls1031_win32.exe file. Go for a custom installation. After the
installation is over, there is no need to run the config.cmd, as is usually done after the WebLogic server
installation to create and configure domains.

The next step is to install a Java Access Bridge. This is required for Windows systems only and not
required for Unix/Linux. The Java Access Bridge can be downloaded from the following location:

http://java.sun.com/javase/technologies/accessibility/accessbridge/index.jsp

Install the Java Access Bridge by clicking the executable downloaded. It may ask for the system to
be rebooted. After the installation is over, go to the installation location. For my system, the installation
location is C:\Program Files\Java Access Bridge. Go to the installerFiles location. Copy the access-
bridge.jar and jaccess-1_4.jar from this location to the jre/lib/ext directory of the corresponding JDKs
installed under the Middleware home where the Oracle WebLogic server was installed. Then, go back
to C:\Program Files\Java Access Bridge\ installerFiles and copy the WindowsAccessBridge.dll,
JavaAccessBridge.dll, and JAWTAccessBridge.dll to the jre/bin directory of the JDK directory or
directories. Finally, copy the accessibility.properties file to the jre/lib directory of the corresponding
JDKs. For my system, it showed two jdk folders under Middleware home, namely jdk160_05 and
jdk106_11.

The next step involves creating a loopback adapter. This is required only when the installation is to
be made on a DHCP system. Else it is not required. I carried out this step for my system as it was
necessary. For this, go to the control panel and click add hardware. Select next. Then select “Yes, I
have connected the hardware”. Then select “Add a new hardware” at the bottom of the list. Select
Network Adapter. Select manufacturer as Microsoft, and Network Adapter as Microsoft Network
Adapter. And go on clicking next. This will install the loopback adapter.

After installing the loopback adapter, go to the desktop, and right click on the network places. Select
properties. This will show all the network connections. Select the connection that corresponds to the
Microsoft Loopback adapter and select properties. Select TCP/IP and provide an IP address. I gave
192.168.88.83 and the network mask as 255.255.255.0. Note down this IP address as it will be required
later. Then, go to C:\WINDOWS\system32\drivers\etc and open the hosts file. Make a entry there just
after the localhost line as shown below

IP_ADDRESS HOST_NAME.DOMAIN_NAME HOST_NAME

For my installation, I specified it as,

192.168.88.83 idc.hyd.oracle.com idc.hyd

Save it and restart the computer. Go to the command prompt and ping the hostname.domainname to
see if the IP is accessible.

The SOA home directory, that is where SOA is to be installed has to reside under the Middleware
home where we installed the Oracle WebLogic server. It is mandatory to do so.

The SOA home should be under the Middleware home. After unzipping the distribution, begin the
installation using the setup.exe executable present under the Disk1 folder. The setup.exe will open a
command prompt asking for the JDK/JRE location. If the Oracle WebLogic server installs a JDK. The
pathname of that JDK can be provided. The location should be provided in a way such that
<location_provided>\bin has the executable java.exe. For me, the location was
C:\ORA_SOA\MIDDLEWARE\jdk160_11 or infact, I could have also provided the path of the JDK as
C:\ORA_SOA\MIDDLEWARE\jdk160_05, as the WebLogic server installation installed two JDKs.

Any name of the SOA home will do, just that it should be under the Middleware home. I continued
with the default one provided by the installer, i.e, Oracle_SOA1.

After the SOA suite installation is over, it is time to configure the WebLogic server domains. This
has to be done by running the config.cmd script, present under the <SOA_HOME>/common/bin
directory, not the one provided by the WebLogic server installation. For my installation, the location of
this config.cmd script was C:\ORA_SOA\MIDDLEWARE\Oracle_SOA1\common\bin\config.cmd.
Using the DOS command prompt, I navigated to this folder and ran the config.cmd. This starts the
Configuration Wizard.

Go for creating a new WebLogic server domain and click next. The next screen asks for selecting
the products which are to be supported. The options include SOA suite, EM, BAM and JRF. This
options will not be provided when the config.cmd script corresponding to the WebLogic server
installation, present under the <MIDDLEWARE_HOME>\wlserver_10.3\common\bin directory is run.
In fact, this is the step where the SOA Suite installation is integrated with the WebLogic server
installation done previously. Till now, the WebLogic server installation did not come into picture than
just providing the Middleware home where the SOA home resides. SOA suite requires an application
sever, and by running the Configuration Wizard, the application server (which is the WebLogic server
for SOA Suite 11gR1) is provided to it. Select all the products (SOA, EM, BAM and JRF) and
continue.

Provide the domain name. Verify the location of the domain and the applications. As you proceed,
the mode will be asked for. Continue with the development mode. For further details of the the modes,
refer the WebLogic server documentation.

The next screen will ask for the details of the database connection, and the schemas which were
created using the RCU. There is no need to modify the Vendor name and driver type. The thin client is
what is required. Provide the DB name or service name in the DBMS/Service field. For me, it was
“xe”. Provide the host name as the one which you configured at the time of the loopback adapter
installation. I provided it as idc.hyd.oracle.com. The listener port is 1521, which is the default port and
was the listener port for my database. Next, you have to provide the Schema owner name and the
corresponding passwords. For changing the schema names and to provide the passwords, select one
schema at a time, de-selecting others, and fill the fields corresponding to schema owner and schema
password under the driver field. If not deselected, the values entered for the schema owner and schema
password will be made common for all the schemas. For going to the next schema, de-select the
previous one for which you just made the entry and select the new one for which entries are to be
provided. Provide values only for those fields which are required. The schema owner names
corresponding to the schemas, for my case were,

DEV_ORABAM for BAM schema

DEV_SOAINFRA for SOA infrastructure
DEV_ORASDPM for User messaging service
DEV_MDS for OWSM MDS schema
DEV_MDS for SOA MDS schema

Click next to test the connections. In case connections fail for any schema, move back to the
previous screen, make the required corrections and test again. In case you have forgotten the passwords
for the schemas, connect to the database as SYSDBA, and change the password, setting it to any value
using the following command:

ALTER USER <schema_name> IDENTIFIED BY <new_password>;

While testing the connection, have a look at the JDBC connection URL. It provided all information
about the database connectivity. It shows that it uses a thin JDBC client, the host name, the DB listener
port number and the service name.

The next step asks for the configuration options. Of these, I configured the Admin Server, the
managed servers, clusters and machines. For details of of these domain configurations, refer to the
WebLogic server documentation.

Configure the Admin server. Just modify the listener port. To check if a port is currently being used,
just go to the command prompt and telnet the host with the port number. For example, to check if the
port 8877 is free on my system, I used the following command:

telnet idc.hyd.oracle.com 8877

 If no connection is established and the connection fails, it means that the port is free and can be
used. (Please refer to WebLogic server installation guide for further details about the installation
process)

Two managed servers are created. These are bam_server1 and soa_server1. The bam_server1
managed server hosts the Oracle BAM, while the soa_server1 managed server hosts the Oracle SOA
Suite. Again specify the port numbers and proceed.

You may configure a cluster if you want.

Next comes the node manager configuration. The listen address can be configured to the IP address
of the host (machine) in which the node manager resides. For me, it is 192.168.88.83, which I
configured during the loopback adapter installation, and for the node manager listen port, I took it to be
default as 6001, while the default is 5556 as the port 5556 was not available to me for use. It was not
free.

Assign all the servers, including the Admin server to the machine just configured. Finally, create the
domain. The installation and configuration of Oracle SOA Suite 11g is done.

To launch the Admin Server URL, first, start the Admin server. The Admin server can be started by
executing startWebLogic.cmd, present under the
<MIDDLEWARE_HOME>\user_projects\domains\<DOMAIN_NAME> folder. Do not close down
the command window. This will kill the Admin server as well.The command window has to remain
open as long as the Admin server is running.

I could access the Admin console can be accessed from the following URL:

http://idc.hyd.oracle.com:7001/console

The Enterprise Manager Fusion Middleware Control console could be accessed from the following
URL:

http://idc.hyd.oracle.com:7001/em

The managed servers were still found to be in the shutdown state. These could be brought up by
using startManagedWebLogic.cmd, present in the
<MIDDLEWARE_HOME>\user_projects\domains\<DOMAIN_NAME>\bin folder. The syntax for
this command is

startManagedWebLogic.cmd <managed_server_name> <admin_console_url>

For me, it was,

startManagedWebLogic.cmd bam_server1 http://idc.hyd.oracle.com:7001

The username and password required will be the ones provided during the domain creation using
SOA suite configuration wizard. This process has to be repeated for each of the individual managed
servers, from separate command prompt windows.
 To access Oracle BAM, the managed server hosting Oracle BAM has to be brought up. In my case,
it was bam_server1. After it is up, Oracle BAM was accessible at the following URL:

http://idc.hyd.oracle.com:9001/OracleBAM

where, 9001 was the listen port for the managed server bam_server1, provided in the configuration
wizard.

To check Oracle B2B, it is necessary to bring the soa_server1 managed server up. The URL for
accessing Oracle B2B for my installation was:

http://idc.hyd.oracle.com:8001/b2b

where, 8001 was the port number of the soa_server_1 managed server, provided at the time of SOA
configuration.

The DMS application were accessible through the following URLs, for the Admin server,
bam_server1 and soa_server1 managed servers respectively:

http://idc.hyd.oracle.com:7001/dms
http://idc.hyd.oracle.com:9001/dms
http://idc.hyd.oracle.com:8001/dms

That makes the installation complete.