April 2015 - Collaborate/IOUG

1. COLLABORATE 15 – IOUG Forum
Middleware
1 | P a g e “What Every Client Should Do On Their Oracle SOA Projects ”
White Paper
What Every Client Should Do On Their Oracle SOA Projects
Ahmed Aboulnaga, Raastech
ABSTRACT
Having provided advanced subject matter expertise to numerous customers for their integration projects, a common theme
emerges; most forget to factor in some important elements into their integration design. These are often introduced later as
the organization grows in its SOA maturity level, but then comes at considerable cost and effort.
Some recommendations are architectural in nature, such as implementing service level authentication and setting up high
availability. Others are infrastructure related; performance tuning the infrastructure and setting up purging. Meanwhile, certain
development considerations must be thought of ahead of time which includes establishing an error handling and message
recovery framework, and identifying a few key integration design patterns to standardize on. Products discussed include Oracle
SOA Suite, OSB, OWSM, and WebLogic Server.
This presentation shares with current and future users of Oracle SOA Suite a checklist of activities to consider prior to the
initiation of the SOA project, saving considerable effort down the line. We conclude with a Q&A.
TARGET AUDIENCE
This white paper is intended for those embarking on new implementations of Oracle SOA Suite. Half of the instructions are
specific to Oracle SOA Suite 11g, but many concepts are applicable to 12c.
EXECUTIVE SUMMARY
Learner will be able to:
 Receive best practice recommendations needed for every Oracle SOA implementation.
 Deep dive into architectural, infrastructure, and development considerations for your Oracle SOA implementation.
 Understand the importance of starting off with security, deployment, availability, and design patterns in your SOA
project.
BACKGROUND
After providing advanced subject matter expertise to numerous customers for their integration projects, a common theme
emerges; most do not factor in some important elements into their integration design. These are often introduced later as the
organization grows in their SOA maturity, but then comes at considerable cost and effort.
Oracle SOA Suite is the product of choice for many system integrations. It is a complete, open, and comprehensive suite of
products to help build, deploy, and manage service-oriented architectures (SOA), and is comprised of technologies such as
BPEL, Mediator, Oracle Service Bus (OSB), Web Services Manager (OWSM), B2B, and Business Activity Monitoring (BAM).
This single product suite can satisfy most, if not all, of your integration needs.
In this article, we share with current and future users of these technologies a checklist of activities often neglected for
consideration prior to the initiation of your SOA project, which can save considerable effort down the line. These
recommendations should be reviewed from the beginning and include considerations for architecture, infrastructure, and
development.

2. COLLABORATE 15 – IOUG Forum
Middleware
2 | P a g e “What Every Client Should Do On Their Oracle SOA Projects ”
White Paper
TECHNICAL DISCUSSIONS AND EXAMPLES
Establish a Deployment Process
SOA code can be deployed via Ant, the WebLogic Scripting Tool (WLST), or the web console. Choose one of these
approaches you want to use, and be consistent. Oracle SOA code is somewhat different than other programming languages,
say Java, in that endpoint references are hardcoded. Thus, establishing a firm and working deployment process in the
beginning is essential. You may want to leverage configuration plans for SOA composites, customization files for OSB
projects, or Ant tokenization for everything (our preferred approach), but avoid using JDeveloper or the console as your
deployment strategy. A slew of resources are available online that detail these various approaches.
Performance Tune the Infrastructure
There are numerous resources, books, and whitepapers out there that walk you through various performance tuning settings
within WebLogic Server, SOA Suite, and the Oracle Database. In addition to these, Table 1 highlights critical settings that are
often overlooked.
Tuning Task Explanation
Set audit logging to
deferred
By default, the information associated with your BPEL activities or Mediator routing rules is logged to the
database synchronously. This means that instances will remain active until the audit information is committed
to the database. This does not perform ideally under load. By switching the audit policy to deferred, all audit
operations are invoked asynchronously, resulting in performance comparable to setting the audit level to off.
This is significant and results in an immediate 20% to 35% performance improvement.
Configure JCA
retries
By default, retries on the JCA adapters is set to unlimited. Preferably, limit the global inbound JCA retry
count to 5 instead. The GlobalInboundJcaRetryCount takes effect if jca.retry.count is not set at the adapter service
level.
Lower log levels The amount of log information maintained in the .out server logs should be reduced for all non-development
environments, unless additional logging is needed for troubleshooting purposes. Lowering the log level to
ERROR:1 (SEVERE) reduces the amount of information logged and improves performance slightly.
Optimize JTA
timeout
Ensure that the JTA timeout setting is not set to a value too low so transactions are not rolled back. A
recommended value of 120-300 (or higher) is generally ideal. If an end-to-end flow is taking longer than the
JTA timeout setting, the transaction will roll back. If retries are involved, the retry counter is reset and may
thus result in an infinite number of retries.
Configure Log Rotation
Given the comprehensive nature of Oracle WebLogic Server, there are numerous log files you would want to ensure are
controlled. This can be accomplished by frequently rotating the log files (by size) and limiting the number of files that are
retained, otherwise your file system will likely get filled up over time. Fortunately, the WebLogic Server Administration
Console provides us the means to do so.
Log Location
Managed Server Logs Server > [managed_server] > Logging > General
Managed Server HTTP
Logs
Server > [managed_server] > Logging > HTTP
Data Source Logs Server > [managed_server] > Logging > Data Source
Domain Level Logs soa_domain > Configuration > Logging
Managed Server System Out Unfortunately, the WebLogic Server log rotation affects only the .log files but not the standard .out

3. COLLABORATE 15 – IOUG Forum
Middleware
3 | P a g e “What Every Client Should Do On Their Oracle SOA Projects ”
White Paper
files, which is generated when you use Node Manager to start up and shut down the managed servers.
You must implement a custom solution for the system .out files and many resources online are
available to help you with this.
The key logs and the navigation paths within the WebLogic Server Administration Console can be found in Table 2.
Implement Service Level Authentication
OWSM is a solution that allows for declarative web service security implementations (often no coding is required, and security
is separate from the web service being protected). Web service security and management policies are defined centrally in the
OWSM Policy Manager, and can be added/updated at design time or runtime.
However, OWSM lacks certain desired features surrounding web service security and can be complimented with a web service
gateway. Gateways provide two core functions; (a) virtualization of services, and (2) service-level authentication. Oracle’s
product of choice for a gateway is the Oracle API Gateway (OAG), but for most purposes, OSB works completely fine.
Considering a gateway allows for the attachment of OWSM security policies to gateway services, leaving the actual integration
code untouched. The figure below illustrates how the gateway is independent of your integration infrastructure.
By attaching the policy oracle/wss_username_token_service_policy to your gateway service, every incoming request will have
to add a username and password to the header as shown in the following figure. Couple this with HTTPS and you have a
reasonably secure web service with little complexity and effort.
Install a Highly Availability Infrastructure
Configuring a two, three, or four node Oracle SOA Suite cluster provides redundancy, failover, and additional capacity. The
Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite details the steps on how to set up a highly available
(HA) infrastructure. Our company, Raastech, has further extended this to support a maximum available architecture (MAA),
which can be found online and provides for 100% uptime. This may seem obvious, but some organizations opt out of initially
installing an HA cluster because of the learning curve involved and its complexity.
Set Up Purging

4. COLLABORATE 15 – IOUG Forum
Middleware
4 | P a g e “What Every Client Should Do On Their Oracle SOA Projects ”
White Paper
A good automatic purging strategy is essential for managing the growth of your dehydration store. Oracle’s out-of-the-box
scripts do the job, and improved variations can be found online. Adhering to a good purge strategy will prevent the tables
from growing too large and compromising your database. The lack of purging is perhaps the largest culprit behind poor
performance.
Design an Error Handling Framework
Develop a framework that will serve as your primary error handling service. If your BPEL, Mediator, or OSB service throws
an error, simply make a web service call to your framework, which will ultimately persist it in a table. Now you have a log and
history of all errors encountered to which you can implement some sort of notification.
Design a Message Recovery Framework
When errored out, synchronous transactions simply bubble up the fault back to the original caller. This is not the case with
asynchronous transactions. What if, during an async call, a technical error occurs such as the target system being temporarily
down? Is this message permanently lost? Not if you have designed a framework to enable the scheduled recovery of faulted
asynchronous messages.
You can take advantage of the BPEL recovery framework provided with the product, or if you want to get creative and have
more control, implement your own as in Figure 4. Here, if an invocation to an external system fails, the message is persisted in
a database table, and it can be republished back to the original JMS queue manually or at scheduled intervals.
Things to Avoid
Not only do we recommend to our customers what to use, but there are also certain things we advise against.
JMS Topics
There are two serious flaws with WebLogic Server’s implementation of JMS topics. The first is that there is no simple
way to create a JMS topic that is targeted to all managed servers and accessible via a single JNDI. In short, it is not

5. COLLABORATE 15 – IOUG Forum
Middleware
5 | P a g e “What Every Client Should Do On Their Oracle SOA Projects ”
White Paper
possible to have a truly highly available JMS topic. Secondly, it is not possible to have durable subscribers on
distributed topics.
AIA Foundation Pack (Core Services in 12c)
Like many Oracle AIA Foundation Pack customers, Raastech has been disappointed with the lack of true benefits
achieved by adopting it, particularly surrounding the licensing cost, ongoing maintenance cost, and training investment
needed. AIA Foundation Pack, or Core Services as it is now called in 12c, is marketed as a means to reduce complexity
and speed up development, and it is anything but such.
Oracle Business Activity Monitoring (BAM)
Oracle BAM has limited real world value. It is not a true reporting tool and its value to the business community is
insignificant as it is intended to only capture what flows through your integrations. Furthermore, limitations in field
sorting and expansion, cumbersome navigation, poor search, and inability to handle huge volumes of data hinders the
product (applies to 11g, 12c untested).
Mediator Parallel Routing Rules
Mediator parallel routing rules are designed to support asynchronicity and prevent the starvation of threads.
Unfortunately, the internal logic on when/how these parallel routing rules are processed by the engine is severely
flawed in Oracle SOA Suite, resulting in extreme throughput delays as the number of routing rules across the entire
server increase. Use sequential Mediator routing rules or OSB instead.
Summary
In this article, we highlighted several architectural, infrastructure, and development considerations that we feel every Oracle
SOA project should implement. This is by no means an exhaustive list, but rather items that are often neglected, forgotten, or
unknown to those newly exposed to Oracle SOA Suite and its related technologies.
Checklist Item Importance
Establish a Deployment Process High
Performance Tune the Infrastructure High
Configure Log Rotation Medium
Implement Service Level Authentication Medium
Install a Highly Availability Infrastructure High
Set Up Purging High
Design an Error Handling Framework High
Design a Message Recovery Framework High
Avoid JMS Topics Low
Avoid AIA Foundation Pack (Core Services) Low
Avoid Oracle BAM Low
Avoid Mediator Parallel Routing Rules High
The importance listed in the table above or necessity of some of these items is subjective among the SOA architect
community, but their implementation often and eventually becomes a necessity for most organizations.