On the 25th of October at Open World 2015, Oracle released the 12.2.1 version of SOA Suite 12c. This release is full of resiliency updates on the operation side of life.

The operations of integration are critical and Oracle listened to the business requirement of customers while developing this release. Here are few of these operations.

• Usually many hardware/software systems are managed by a small team.
• With minimum need for admin intervention an integration needs to run silently, automatically and smoothly.
• When things do go wrong, a console is needed that quickly allows identification and resolution of exceptions.
• Without a lot of admin training it should be relatively simple to manage integrations.
• An integration needs to scale, perform and provide continuous availability to process high workloads.
• Ability to patch applications/composites for emergency fixes.

It isn’t the first time in the life cycle of SOA Suite 12c that Oracle is working on the operations of the product.

SOA Operations in 12.1.3

In the previous 12.1.3 release Oracle already targeted the IT operations. Read my blog about it for more details. But for a quick reference, here are the major updates.

• Automated Operations
  • Auto Purge: Old data past the retention point are periodically on schedule to be automatically be purged.
• Performance
  • Modularity Profile: Startup time and memoty is reduced by starting up components that are used (depends on the selected profile).
  • Lazy Loading: Startup time is reduced by loading composites only on first use.
• Problem Identification & Resolution
  • Centered Error Hospital: The EM is reworked to be centered around exception conditions instead of business as usual, including a centralised Error Hospital.
  • Better Flow Trace: A flow trace with multiple composites shows both in a single trace for better troubleshooting.
• Simplified Tuning
  • Work Managers: Simplify and improve thread tuning by switching to work managers. In 12.1.3 it is possible to assign a work manager per soa-infra partition.

SOA Operations in 12.2.1

Now in this 12.2.1 release Oracle has targeted the IT operations again, but with more focus on resiliency. First lets look at the major updates.

• Resiliency
  • Circuit Breaker: Improved resiliency when downstream services go down by suspending inbound services.
• Performance
  • In-Memory SOA: Optimize performance and scalability by reducing database growth.
  • Integration Workload Statistics: Diagnostic tool for analysing performance similar to DB AWR.
  • Parallel Deployment: Faster SOA and Service Bus startup time.
• Availability
  • Composite Instance Patching: Patch (long running) instances immediately without redeploying new composite version and stalling instances.
  • Automatic Service Migration (ASM): Reduce the failover time and amount of machine resources needed for deployment.

Lets look at them in more details in same order as above.

Resiliency

Circuit Breaker

A problem we all have experienced is when services more downstream get unavailable cause instances to failt and fill up the error hospital. Manual recovery is sometimes difficult and time consuming. These failing instances consume unnecessary resources.

Because of these failing instances the operational costs to recover instances in the error hospital are greater. There is also a potential instability of the system due to the errors on business critical instances.

In the 12.2.1 release Oracle introduces Circuit Breaker. It automatically suspend upstream inbound services and the messages are added in queues on disk for later processing. The inbound services automatically resume when the downstream service endpoint is up.

You can find this option under soa-infra->soa administration->resiliency configuration. You can enable this option, which is part of the Oracle Integration Continuous Availability add-on, by enabling the checkbox. You can configure the failure rate and the retry interval. After the retry interval the downstream service is automatically checked if available by sending.  It is also possible to send out notification when Circuit Breaker is activated.

This failure rate can also be configured on specific services if it is different than on global level. I will go into detail in a separate blog about this topic.

Performance

In-Memory SOA

SOA is Database intensive where the DB is often then bottleneck which limits cluster scalability, requires frequent purging to manage DB growth and it impacts the overall performance.

The In-Memory option uses the Coherence cache instead of the database for dehydration and instance tracking data when applicable. It delivers major performance improvement and reduces DB growth significantly.

Previously all state and flow data was persisted to the Database at every dehydration point.  Now you have the choice to persist flow and instance data only for faulted instances and long running instance running longer than a cutoff time (default 5 minutes). In-Memory SOA leverages the coherence cache for running transactions (flow trace, BPEL state, audit trail and payloads).

The option, which is part of the Continuous Availability add-on, is set at component level, which allow for mix and match in a flow. I will go into detail in a separate blog about this topic.

Integration WorkLoad Statistics

In version 12.1.3 and earlier SOA Suite has a lack of tooling to help troubleshoot performance problems and tune the system. The impact of this is that the training costs for IT staff for tuning / performance troubleshooting is higher or that they have to rely on partners like AMIS. The IT staff need knowledge querying DB or use less convenient or suitable tools.

In many time there is just no tool available, but in this release Oracle provides a tool called Integration WorkLoad Statistics (IWS) to provide DB AWR like reports with key performance data.

IWS, which is part of the Continuous Availability add-on, helps with performance troubleshooting and tuning. It takes periodic snapshots of metrics at configured interval and the data is written to the Database per managed server. IWS generates reports by user specified time range and comes in three formats: XML, CSV and HTML.

With the guide you should be able to tune composites and SOA/WLS/JVM configurations like max thread constraint and heap size. My colleague Maarten Smeets will write a more detailed blog about this topic in the near future.

Weblogic Parallel Deployment

We can be really quick about this feature, which is available without the resiliency add-on. From version 12.2.1 WebLogic Server supports parallel deployment which should improve SOA and Service Bus startup time. During startup composites are loaded/deployed in parallel.

Availability

Composite Instance Patching

When thinking about Composite Instance patching you can think of the following use cases.

• When a instance fails due to a bug and you want to fit it and resubmit from EM.
• When a small bug in your composite causes long running instances to fail.
• When a small change in your flow (e.g. a mapping) has to be applied to long running instances.
• When you need the ability to apply those changes to already running instances.

In the previous release there was no way to make small changes to composites and have running instances see the changes without stalling the instances. Running instances could be running longer e.g. days or months.

This could have huge implications to mission critical services if critical fixes cannot be made in a timely fashion. Composite patching support, still limited changes, patching of same revision of already deployed composite. Long running instances see the change and when failed instances are resubmitted they see the change made in BPEL.

The tooling, JDeveloper, ensure that only compatible changes are made e.g. XSLT, assign activity, BPEL invokes, etc. When deploying the service it can distinguish patches from regular deployments.

The option, which is part of the Continuous Availability add-on, is supported only in production environment with database MDS. I will go into detail in a separate blog about this topic.

Automatic Server Migration (ASM)

In previous releases, SOA, Service Bus and MFT supported Whole Server Migrations only and but BAM supported ASM. For 12.2.1 also the other three support ASM.

ASM reduces the failover time significantly and also the amount of machine resources needed for a deployment are reduced. In ASM, a service fails over from an unavailable managed server to an already executing managed server. Which means you don’t have to deploy the composites to your stand-by environment. You can now use this feature to deploy just the missing composites.

Conclusion

In this release Oracle packed a lot of resiliency features into SOA Suite. Some features are part of the Resiliency add-on. My favorite features are the Circuit Breaker and the In-Memory SOA option. Composite patching is most usable with long running instances, but my opinion is that most of the use cases should be solved with good unit / integration / UAT tests.

Hope that you enjoyed this blog and closely monitor the blog for the detailed blogs about the topics mentioned in this blog.