Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

What Every Client Should Do On Their Oracle SOA Projects (whitepaper)


Published on

April 2015 - Collaborate/IOUG

Published in: Technology
  • Be the first to comment

  • Be the first to like this

What Every Client Should Do On Their Oracle SOA Projects (whitepaper)

  1. 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. 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. 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. 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. 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.