What I Advise Every Customer To Do On Their Oracle SOA Projects

Transcription

1 What I Advise Every Customer To Do On Their Oracle SOA Projects Save yourself future redesign by considering a few key elements when embarking on your new SOA project. By Javier Mendez & Ahmed Aboulnaga, Raastech 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 serviceoriented 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. 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

2 Database. In addition to these, Table 1 highlights critical settings that are often overlooked. Tuning Task Set audit logging to deferred Configure JCA retries Lower log levels Optimize JTA timeout Explanation 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. 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. 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. Ensure that the JTA timeout setting is not set to a value too low so transactions are not rolled back. A recommended value of (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 Table 1. Oracle SOA Suite Overlooked Performance Tuning Settings 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 Managed Server Logs Managed Server HTTP Logs Data Source Logs Domain Level Logs Managed Server System Out Location Server > [managed_server] > Logging > General Server > [managed_server] > Logging > HTTP Server > [managed_server] > Logging > Data Source soa_domain > Configuration > Logging Unfortunately, the WebLogic Server log rotation affects only the.log files but not the standard.out 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. Table 2. WebLogic Server Logs to Rotate The key logs and the navigation paths within the WebLogic Server Administration Console can be found in Table 2.

3 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. Figure 1 illustrates how the gateway is independent of your integration infrastructure. Figure 1. Deploying a Gateway Allows for Virtualization and Security 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 Figure 2. Couple this with HTTPS and you have a reasonably secure web service with little complexity and effort. Figure 2. Example SOAP Header with Authentication (namespaces removed for readability) Install a ly Availability Infrastructure

4 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 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 Figure 3. Basic SOA Error Handling 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.

5 Figure 4. Basic SOA Message Recovery Framework 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 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 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

6 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 Establish a Deployment Process Performance Tune the Infrastructure Configure Log Rotation Implement Service Level Authentication Install a ly Availability Infrastructure Set Up Purging Design an Error Handling Framework Design a Message Recovery Framework Avoid JMS Topics Avoid AIA Foundation Pack (Core Services) Avoid Oracle BAM Avoid Mediator Parallel Routing Rules Importance Medium Medium Low Low Low Table 3. Importance of the SOA Checklist Items The importance (see Table 3) 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. About the Authors Javier Mendez is a Principal Consultant at Raastech, a full life cycle systems integrator based out of the Washington DC area. Javier is an OCP with extensive hands-on experience in performance tuning, high availability solutions, and administration of Oracle Database and Middleware components. Javier can be reached at javier.mendez@raastech.com.

7 Ahmed Aboulnaga is a Technical Director at Raastech. Ahmed s focus is in technical management, architecture, and consulting within the Oracle Fusion Middleware stack. Ahmed is an Oracle ACE, regularly speaks at major Oracle conferences, and actively contributes to the online community in areas of Oracle middleware technologies. Ahmed can be reached at ahmed@raastech.com on Twitter.