SOA Best Practices and Design Patterns

SOA Best Practices and Design Patterns


Implementing and Managing an Oracle SOA infrastructure

SOA Governance: Framework and

Best Practices

SOA Suite 11g Transaction Semantics Part 3

For Mediator ----  SOA Suite 11g Transaction Semantics Part 1


For BPEL  -----      SOA Suite 11g Transaction Semantics Part 2


One-way invocations:

Usually a one way invocation (with a possible callback) is exposed in a wsdl as below

<wsdl:operation name="process">

        <wsdl:input message="client:OrderProcessorRequestMessage"/>

    </wsdl:operation>

This will cause the bpel engine to split the execution into two parts.

 First, and always inside the caller transaction, the insert into the dlv_message table (in 10.1.3.x that is into the inv_message), and secondly the transaction & new thread that executes the workitems, and creates a new instance.

This has several advantages in terms of scalability - because the engine's threadpool (invoker threads) will execute when a thread is available. However, the disadvantage is that there is no guarantee that it will execute immediately.

If one needs to have a sync-type call based on a one way operation - then they can use onewayDeliveryPolicy, which is a forward port of deliveryPersistPolicy in 10.1.3.

This property can be set by specifying bpel.config.oneWayDeliveryPolicy in a bpel component of composite.xml.

Possible values are "async.persist", "async.cache" and "sync". If this value is not set in composite.xml, engine uses the oneWayDeliveryPolicy setting in bpel-config.xml

async.persist => persist in the db
async.cache => store in an in-memory hashmap
sync => direct invocation on the same thread

onewayDeliveryPolicy ! = sync (default, callee runs in separate thread/treansation)

throw any fault
caller doesn't get response because message is saved in delivery service. The callee's transaction will rollback if the fault is not handled.

throw bpelx:rollback
caller doesn't get response because message is saved in delivery service. It will rollback on unhandled fault.

-------
onewayDeliveryPolicy=sync, txn=requriesNew (callee runs in the same thread, but different transaction)

throw any fault
caller gets FabricInvocationException. Callee transaction rolls back if the fault is not handled.

throw bpelx:rollback
caller gets FabricInvocationException. Callee transaction rolls back.

-------
onewayDeliveryPolicy=sync, txn=required (callee runs in the same thread and the same transaction)

throw any fault
Callee faulted. Caller gets FabricInvocationException. Caller has a chance to handle the fault.

throw bpelx:rollback
whole transaction rollback.

SOA Suite 11g Transaction Semantics Part 2

For Mediator  ---- SOA Suite 11g Transaction Semantics Part 1


BPEL:

By default  BPEL will create a new transaction on request basis - that is if one already exists, it will be suspended, and a new one created. Upon completion of the child, the master one resumes. 

                         
However, if the request is async (that is one-way) we either inherit the transaction for the insert into the dehydration store (that is dlv_message in this case) or if one exists enlist transparently into it. So we guarantee you zero message loss. Either the invocation message is in the dehydration store, to be processed, or otherwise the consumer is notified via a fault.

One only needs to set the (new) transaction flag on the calee bpel component. This can be done in the composite editor's source by adding bpel.config.transaction into a bpel component - as shown below

  <component name="SampleProject">

    <implementation.bpel src="SampleProject.bpel"/>

    <property name="bpel.config.transaction"

         many="false" type="xs:string">required | requiresNew</property>

  </component>

The two possible values are 

1> required, which makes BPEL inherit the tx that is already there, or if not creating a new one

2> requiresNew which makes BPEL suspending one if exists, and ALWAYS create a new one 

                     

Implications of setting the above (the default is requiresNew)

Case one - BPELCaller calls BPELCallee (the latter has requiresNew set)

a) BPELCallee replies (that is uses <reply>) with a fault: BPELCallee transaction is saved, BPELCaller get's the fault and can catch it.
b) BPELCallee throws (that is uses <throw>) a fault, that is NOT handled: BPELCallee tx get's rolled back, BPELCaller get's the fault and can catch it
c) BPELCallee replies back with a fault (FaultOne), and then throws a fault (FaultTwo): BPELCallee tx get's rolled back, and BPELCaller get's FaultOne
d) BPELCallee throws (that is uses <throw>) a bpelx:rollback fault: BPELCallee tx get's rolled back, BPELCaller get's a remote fault

Example:--

Create two processes (BPELMaster and BPELChild), both sync, each using the same db adapter reference that inserts the same record (and hence causes a PK violation). (And of course has set xADatasourceName). In this case

                 

Once the fault occurs, and is not handled - the BPELChild will rollback. If the BPELMaster has a catch block his transaction will commit, so you end up with the record from the Master in the db.If you don't catch the fault in the master as well - you get a second rollback - two different transactions though.

Case two - BPELCaller calls BPELCallee (the latter has required set)
a) BPELCallee replies (that is uses <reply>) with a fault: BPELCaller get's the fault and can catch it, BPELCaller owns the transaction - hence if he catches it - tx is committed, if BPELCaller does not handle it - global rollback.
b) BPELCallee throws (that is uses <throw>) a fault BPELCaller get's the fault and can catch it
c) BPELCallee replies back with a fault (FaultOne), and then throws a fault (FaultTwo): BPELCaller get's FaultOne
d) BPELCallee throws (that is uses <throw>) a bpelx:rollback fault: BPELCaller tx get's rolled back, no way to catch it.

Example :--

Create two processes (BPELMaster and BPELChild), both sync, each using the same db adapter reference that inserts the same record (and hence causes a PK violation). (And of course has set xADatasourceName). In this case

 If no fault handlers are in place - the whole tx will rollback, based on the BPELMaster's unhandled fault.With a fault handler in the BPELMaster to catch the Fault from the BPELClient - and throw up a rollback fault. Globally the tx will rollback as well.

Note :-- tx stands for ongoing transaction

Oracle ESB Overview Part 2

Oracle ESB Overview Part 1

Oracle Enterprise Service Bus contains the following components:

■ ESB Server

The ESB Server is the runtime server which listens on the control topic for updates

from the ESB Metadata Server and updates its cache.

■ Oracle ESB Control

The Oracle ESB Control provides a Web-based interface for managing,

administering, and monitoring services that you have registered with the ESB

Metadata Server.

■ ESB Metadata Server

The database that holds your ESB metadata such as schemas, transformations, and

routing rules. The ESB Metadata Server is the server to which you register the ESB

services that you have designed using Oracle JDeveloper and configured using

Oracle ESB Control.

■ Oracle JDeveloper

Oracle JDeveloper is a graphical and user-friendly way to model, edit, and design

the services that comprise an Oracle Enterprise Service Bus system.

Oracle ESB Architecture

ESB services are designed and configured with Oracle JDeveloper and Oracle ESB

Control user interfaces. The ESB project which contains the services is registered to the

ESB Server. The ESB Server supports multiple protocol bindings including

HTTP/SOAP, JMS, JCA, WSIF, and Java that ensure guaranteed, reliable message

delivery using synchronous/asynchronous, request/reply or publish/subscribe

models. However, the ESB Server does not support Remote Method Invocation (RMI).

Oracle ESB DT(Design Time)

When an ESB project is registered with the ESB server, ESB files created in Oracle

JDeveloper or Oracle ESB Control are deployed to the design time metadata server.

The following JMS topics are running on the design time metadata server: control,

monitor, resubmit, and defer. Also running on the metadata server are the following

servlets: console, WSIL, design time, WebDav, and SOAP provider.

The created or updated service definition files are translated and captured in a

relational form in the ORAESB schema in the database repository while the XSD, XSL,

WSDL, and map files are written to the file system. The service definition files have

pointers to the XSD, XSL, WSDL, and map files.

Oracle ESB RT (Run Time)

An ESB runtime server, or multiple servers in a cluster, accesses the control topic file

on the design metadata server to cache the information for the ESB runtime services.

ESB runtime servers listen on the control topic to get notified of any metadata changes.

These notifications result into reload of cached metadata for the entities that changed.

The ESB runtime server contains the following: server execution, memory cache, JMS

error topic, XML/XSL engine, and JCA adapter agents.

At runtime, the ESB message flow is initiated by an inbound adapter polling or

listening for an event, such as a file copied to the directory specified for an inbound

file adapter. The ESB flow is also initiated when an external SOAP/HTTP process

invokes the Web service associated with an ESB routing service.

Note:--


If execution is synchronous, then Oracle Enterprise Service Bus
invokes the target service immediately; control is not returned to the routing
service until the message has been received by the target service for processing.


If execution is asynchronous, then Oracle Enterprise Service Bus
uses JMS for delivering the message to the target service, which will be invoked at
a later time. Control is returned to the routing service immediately, before the
target service has received the message.

Oracle ESB Overview Part1

Oracle ESB Overview Part 2

What Is An ESB


Depends On Who You Ask

·         Service architecture built on top of messaging

·         Web service management

·         J2EE Application Server

·         Suite or Standalone Product?

           

 Oracle ESB Is All of the Above

·         Key Component of Oracle SOA Suite

·         Delivers Data and Application Integration Functionality

·         Supports Multiple Protocols

·         Based on Open standards and is 3^rd Party Interoperable

SOA Suite 11g Transaction Semantics Part 1

For BPEL ---- SOA Suite 11g Transaction Semantics Part 2
Mediator: 

On the inbound side, when mediator is invoked via binding.ws it will create an manage a new transaction, otherwise (e.g. if invoked through an adapter it will inherit the existing transaction)

In more generic terms: 
If a transaction is present, Mediator participates in that existing transaction. If transaction is not present, Mediator starts the transaction

In case of sync (aka sequential) routing rules, they will be all executed in the same transaction, and if an error occurs, a rollback will be issued. 

Note: in this case even a fault policy that is configured against a mediator fault will NOT trigger.

In case of async routing rules, each rule will be executed in a new transaction, and if errors occur, a rollback will happen, and a fault policy can be configured to react to it.

■ All synchronous services are always executed before

asynchronous services.

■ All SOAP endpoints are nontransactional.

Same System — All Asynchronous

■ If the first asynchronous routing rule fails, no other asynchronous routing rules

execute.

■ If any subsequent asynchronous routing rule fails, it tries to roll back all executed

asynchronous rules. If the end service is nontransactional, the rollback does not

happen. The flow as a whole does not roll back.

Same System — All Synchronous

■ If the first synchronous routing rule fails, no other synchronous routing rules

execute. The complete flow rolls back to the inbound service.

■ If any subsequent synchronous routing rule fails, it tries to roll back all executed

synchronous rules, and no other synchronous rules execute. If the end service is

nontransactional, the rollback does not happen. The flow as a whole rolls back to

the inbound service that started the flow.

Same System — Synchronous and Asynchronous

■ If the first synchronous routing rule fails, no other routing rule executes, and the

flow rolls back, including the inbound service.

■ If any subsequent synchronous routing rule fails, it tries to roll back all executed

synchronous rules, and no other synchronous and asynchronous rules execute. If

the end service is nontransactional, the rollback does not happen. The flow as a

whole rolls back to the inbound service that started the flow.

■ If the first asynchronous routing rule fails, no other asynchronous routing rules

execute, but none of the synchronous routing rolls back.

■ If any subsequent asynchronous routing rule fails, it tries to roll back all executed

asynchronous rules (it does not roll back synchronous routing rules). If the end

service is nontransactional, the rollback does not happen. Also, the flow as a whole

does not roll back.

Multisystem — All Asynchronous (Systems A and B)

■ If the first asynchronous routing rule in system A fails, no other asynchronous

routing rule in this system executes. The execution of routing rules in system B

continues normally.

■ If any subsequent asynchronous routing rule fails in system A, it tries to roll back

all executed asynchronous rules in system A. If the end service is nontransactional,

the rollback does not happen. The flow as a whole does not roll back. Execution of

routing rules in system B continues normally.

Multisystem — All Synchronous

■ If the first synchronous routing rule fails, no other synchronous routing rules (in

any system) execute. The complete flow rolls back to the inbound service.

■ If any subsequent synchronous routing rule fails, it tries to roll back all executed

synchronous rules (both on system A and system B), and no other synchronous

rules execute. If the end service is nontransactional, the rollback does not happen.

The flow as a whole rolls back to the inbound service that started the flow.

Multisystem — Both Synchronous and Asynchronous

■ If the first synchronous routing rule fails, no other routing rule executes (on any of

the systems) and the flow rolls back, including the inbound service.

■ If any subsequent synchronous routing rule fails, it tries to roll back all executed

synchronous rules (on any of the systems), and no other synchronous and

asynchronous rules execute across systems. If the end service is nontransactional,

the rollback does not happen. The flow as a whole rolls back to the inbound

service that started the flow.

■ If the first asynchronous routing rule fails on system A, no other asynchronous

routing rules execute on system A. None of the synchronous routing rolls back and

the execution of routing rules in system B continues normally.

■ If any subsequent asynchronous routing rule fails in system A, it tries to roll back

all executed asynchronous rules in system A, (it does not roll back synchronous

routing rules across systems). If the end service is nontransactional, the rollback

does not happen. The flow as a whole does not roll back. The execution of routing

rules in system B continues normally.

Synchronous BPEL Process Calling Synchronous Mediator Routing (Mediator

Native Binding)

If an MEDIATOR endpoint fails, the MEDIATOR flow rolls back all the way to the BPEL

process and the BPEL process instance goes into the Perform Manual Recovery mode. If the conditions for the end point failure are removed, the recovery happens once manually resubmitted from the Perform Manual Recovery option. The same Mediator instance that errored out now succeeds.

Synchronous BPEL Process Calling Synchronous Mediator Routing (SOAP

Binding)

If an Mediator endpoint fails, the Mediator flow rolls back all the way to the BPEL

process and the BPEL process instance is faulted . The error

returned is something like Privileged Security Exception and the real error

for the Mediator endpoint failure is available from an Mediator Control trace.

Asynchronous BPEL Process Calling Asynchronous Mediator Routing (MEDIATOR Native /SOAP binding)

If an Mediator endpoint fails, the Mediator instance is faulted and the instance can

be submitted again for the failed endpoint. The BPEL process completes successfully.