BPEL and transactions - part 5 (last part)

About transaction standards and protocolls. Here is part 5 of "BPEL and transactions".

Transaction standards and protocols

The execution of distributed transactions poses new requirements to a transaction environment. Services have to be executed and managed in heterogenous systems.

Most transactions standards are based on the Distributed Transaction Coordinator Model.Those standards are distinguished from another by the length of the transaction. Some standards are suited for short-lived transactions, because during execution resources are blocked. Others are more suited for long transacton times.

Identification of a transaction by transaction context

The context of the transaction has to be managed during the existence of the transaction and also it must be broadcasted to all engaged systems.

The occurence of an error may not lead to inconsistencies in many different systems.

Transaction standard:  Web Service Atomic Transaktion (WS-AT)

With the adoption of WS-AT the ACID properties can be implemented over distributed services on different application servers. As resources are locked during execution, WS-AT is only suitable for short-living processes. The WS-AT standard is supported by different middleware manufacturers.


Web Service Atomic Transaktion (WS-AT) in Oracle SOA Suite

The Oracle Weblogic Server 11gR1 (10.3.3) and Oracle SOA Suite 11g R1 PS2 (11.1.1.3) support the WS-AT standard version 1.2. For being able to use WS-AT on a WLS, the domain must be configured for WS-AT. The start of the transactions has to be set through a property in the BPEL process and at the references WS-AT has to be activated. When calling external references the transaction participation has to be transfered.

Transaction participation

Never: the service executes in an own transaction
Supports: the service participates at the transaction
Mandatory: the service participates at the transaction. If there is no transaction available, an exceptio message/fault is thrown.

Other error options:

-system errors
-deadlocks
-protocol errors
-network errors
-hardware errors
-timeout

Error handling when the coordinator fails

Before the sending of the prepare message, all participants must be logged. The response message of all participants must also be logged. With the logs the coordinator can restart at the point of failure.

Error handling when a participant fails

All requests are logged, just like the response messages.With the logs the coordinator can restart at the point of failure.

Summary

With the adoption of WS-AT the ACID properties can be implemented over distributed services on different application servers. All participants must support the WS-AT standard. If possible distributed transactions should not be too complex. Frequently a transaction, which is distributed over different heterogenous systems and products is complex and error-prone. Local transactions should be use where it is possible.

Master Data Management

I found an interesting article about Master Data Management in the german IT magazine  "CIO"

http://www.cio.de/strategien/2268458/index.html

BPEL and transactions - part 4

And here is part 4 of "BPEL and transactions". This time I write about BPEL and error detection in a transactional enviroment.

BPEL and error detection

To trigger a compensation action, every service has to return a fault in case of error. In case of synchronous services faults are returned by default. With asynchronous services no fault is returned. A "receive element" would wait forerver for the result of the service (endless loop).

Pick element

The pick element contains the two cases "on Message" and "on Alarm". It waits until the called asynchronous process returns a result ("on Message") or the maximum waiting time ("on Alarm") is reached and then executes the corresponding block.

T-Shape professionals

After visiting one of his presentations, I was just reading a book by Prof. Dr. Gunter Dueck with the title "Professionelle Intelligenz - Worauf es morgen ankommt". That translates roughly to "Professional Intelligence - What will be important tomorrow".

Especially the concept of T-Shape IT professionals appeals to me. For those of you who are not familiar with that, take a look at Wikipedia:
http://en.wikipedia.org/wiki/T-shaped_skills

The T-Shape professional has a mixture of skills. On the one hand he has very deep, maybe expert-level knowledge of one special area (the I in the T). On the other hand he is not only an expert in that field, but has a strong basic knowledge in other generell areas concerning his job (the - in the T). For example being a great JEE-Developer is sometimes not enough in the modern IT world. You may also have to have knowledge in more generel domains like busines processes, project management, team work, presentation techniques, sales and marketing or other social skills.

In this way T-Shape professionals become much more valuable for their company, because they are much more applicable. I think this is getting more and more important. Expecially being an IT consultant!

An interesting article about T-Shape in german language can be found here:
http://www.perspektive-mittelstand.de/T-Shaped-Professionals-Die-IT-Fachkraft-der-Zukunft/management-wissen/3775.html

Here is also an english article, which is a bit older.
http://fixcv.com/t-shaped-people-jobs-and-recruiting-4828.html

BPEL and transactions - part 3

About controlling transactions in the Oracle SOA Suite MEDIATOR component. Here is part 3 of "BPEL and transactions".

Control of transactions in Mediator

When the mediator component of Oracle SOA Suite is called from an external process, a new transaction will be created. If a parent transaction exists and mediator can use this, it will do so.

With sequential (syncronous) routing rules, all rules will be executed in one transaction. In case of error there will be a rollback of all routings. The fault policies of the mediator are NOT being executed.

In case of parallel routing rules, a new transaction is created for every new rule. In case of error a rollback will be executed. Here, the fault policies of the mediator are executed and can be used to react to errors.

First, sequential routing rules are executed in one transaction. After that every parallel rule is executed in its own transaction.

SOA/BPM guidelines article

The german magazine "Computerwoche" published an interesting link to an article on SOA/BPM guidelines/code of practice:
http://soa-know-how.de/index.php?id=45

This article is in german language.

BPEL and transactions - part 2

Here is part 2 of "BPEL and transactions". This is about how to control transactions in BPEL. Have fun!

Control of transactions in BPEL

There 2 alternatives of executing a transaction in BPEL or a composite.
1. inherit the parent transaction, if one exists
2. execution in a new transaction

The control of the transaction is conducted by properties. Unfortunately exist different properties in Oracle SOA Suite 10g and 11g. The control of the transactions can be done by "breakpoint acitivities".
In Oracle SOA Suite 11g there are properties in the composite to control transactions. For "exposed services" and/or "external references" the property "Transaction Participation" can be set to "Never", "Supports", "Mandatory" or "WSDLDriven". In the bpel component the property "bpel.config.transaction" can be set to "requiresNew" or "required".

A syncronous invoke without transaction properties

A syncronous invoke with BPEL property "bpel.config.transaction" set to "required"

The local transaction is being completed by BPEL by a "breakpoint activity" or at the end of the flow (dehydration). Following "breakpoint activities" exist:
- Receive (unless it is the first receive and the flow is part of the parent transaction)
- OnMessage
- Wait (is being commited after some seconds)
- OnAlarm
- Invoke (if partner link is idempotent)
- End of flow (if process has its own transaction)
A syncronous invoke with partner link property "idempotent" set to false.