Fundamentals of BPEL

To Start with, BPEL (Business Process Execution Language), is an OASIS standard executable language for specifying actions within business processes with web services. Source Wiki

So if we say BPEL we mean a standard language, whose basics will not change as per the implementing companies/product. All we need is BPEL engine to run the BPEL code. This engine can be open source or licensed one, depending on the additional features we may require for the product/service to be developed.

For example we have few companies IBM, Oracle, WSO2 which strictly follow BPEL (OASIS) standards and provide additional features on top of the basic BPEL.

Latest version of BPEL is 1.2 -->2.0 which was revised from 1.1.

Few differences are :

New Activities 2.0

• activity to repeat the set of activities . Replace the FlowN activity in BPEL 1.1 version.

• - Use this activity if the body of an activity must be performed at least once. The XPath expression condition in the repeatUntil activity is evaluated after the body of the activity completes.

•  -- - Replaces the switch activity in BPEL 2.0 - This activity enables you to define conditional behavior for specific activities to decide between two or more branches. Only one activity is selected for execution from a set of branches.

• Changed to

•  - to compensate the specified child scope

• A activity has been added to fault handlers this activity enables you to rethrow a fault originally captured by the immediately enclosing fault handler.

New activity types:- repeatUntil, validate, forEach (parallel and sequential), rethrow, extensionActivity, compensateScope 
Renamed activities:- switch/case renamed to if/else, terminate renamed to exit 
Termination Handler:- added to scope activities to provide explicit behavior for termination
Variable initializationportType attribute:- The attribute "portType" of messaging activities such as "receive," "invoke," "reply," "pick," and "onEvent" is no longer mandatory and can be omitted

Source: http://www.albinsblog.com/2012/09/difference-between-bpel-11-and-bpel-20.html#.VR5s3cbCkRY

Just To summarise and revise ;) 

Messaging:- In BPEL 1.1 there is no defined behavior for a process that receives a message for a request-response operation and finishes without replying. In BPEL 2.0, such a scenario would have trigged a new BPEL standard fault called "missingReply" fault.

Source : http://pushplsingh.blogspot.in/2011/10/comparison-between-bpel-11-and-20.html

Coming back to BPEL, since I am from Oracle SOA suite background I would share my learnings in BPEL in terms of features and extensions provided by oracle.

Oracle extensions: 

Email 

Java Embedding activity:

we can embed Java code snippets directly into the BPEL process using the Java BPEL exec extension.

When we drag a Java Embedding activity into a BPEL process in Oracle BPEL Designer, the  element and bpelx:exec tag are automatically added.

IM

Replay

Transform

Dehydration Store :As discussing this will require more than one blog..there is one informative blog for dehydration you can refer to : http://www.soatutor.com/2012/08/dehydration-in-bpel-oracle-soa-suite-11g.html

Dehydrate

Over the life cycle of a BPEL instance, the instance with its current state of execution may be saved in a database. When a BPEL instance is saved to a database, the instance is known as being dehydrated. The database where the BPEL instance is saved is called a dehydration store.

Skipping dehydration

• For Synchronous processes that do not need to be durable, you can turn off the dehydration mechanism by setting the following properties at process or engine level:

• Skipping dehydration will increase performance with a cost of auditing.

• By Default, all BPEL processes are dehydrated regardless of whether they are Synchronous or Asynchronous process.

• Set inMemoryOptimization to true.

• Set completionPersistPolicy property to faulted or Off.

• Asynchronous process invocation messages are always saved to the dehydration store.

• Durable process are always dehydrated regardless of the settings of the persistence properties.

Dehydration Tables

1. Cube_Instance: Stores the information about the composite instance that gets created.
2. Cube_scope: Stores information about the scopes and variables declared and used.
3. DLV_Message: All the incoming payload details are stored.
4. Invoke_Message: All the outgoing message payload details are stored.
5. Audit_Trail: Used to store information of the xml that is rendered in EM console.

Link Referred :http://manoharsr.wordpress.com/2013/05/13/dehydration-in-soa/