Dehydration Store Tables Extension Details

Some tables of SOA dehydration stores and details are available at below Oracle documentation -

http://docs.oracle.com/cd/E23943_01/core.1111/e10108/bpel.htm#r12c1-t12

Also pasting the contents here for ready reference -

Table Name	Table Description
audit_trail	Stores the audit trail for instances. The audit trail viewed in Oracle BPEL Control is created from an XML document. As an instance is processed, each activity writes events to the audit trail as XML.
audit_details	Stores audit details that can be logged through the API. Activities such as an assign activity log the variables as audit details by default. Audit details are separated from the audit_trail table due to their large size. If the size of a detail is larger than the value specified for this property, it is placed in this table. Otherwise, it is placed in the audit_trail table.
cube_instance	Stores process instance metadata (for example, the instance creation date, current state, title, and process identifier)
cube_scope	Stores the scope data for an instance (for example, all variables declared in the BPEL flow and some internal objects that help route logic throughout the flow).
dlv_message	Stores incoming (invocation) and callback messages upon receipt. This table only stores the metadata for a message (for example, current state, process identifier, and receive date).
dlv_subscription	Stores delivery subscriptions for an instance. Whenever an instance expects a message from a partner (for example, the receive or onMessage activity) a subscription is written out for that specific receive activity.
document_ci_ref	Stores cube instance references to data stored in the xml_document table.
document_dlv_msg_ref	Stores references to dlv_message documents stored in the xml_document table.
wftask	Stores tasks created for an instance. The TaskManager process keeps its current state in this table.
work_item	Stores activities created by an instance. All activities in a BPEL flow have a work_item table. This table includes the metadata for the activity (current state, label, and expiration date (used by wait activities)).
xml_document	Stores all large objects in the system (for example, dlv_message documents). This table stores the data as binary large objects (BLOBs). Separating the document storage from the metadata enables the metadata to change frequently without being impacted by the size of the documents.
Headers_properties	Stores headers and properties information.

Asynchronous vs. Synchronous BPEL process

This article explains the difference between an asynchronous and a synchronous process.

I have tried to explain the difference with the help of a simple example below:

Suppose there are two processes SynchronousBPELProcess and AsynchronousBPELProcess. As the name suggest former one is a synchronous and later one is an asynchronous BPEL process. Also there is a third process which we’ll call as Client. The Client invokes the above processes.

Case 1: Client invokes SynchronousBPELProcess.

1. Client invokes SynchronousBPELProcess.
2. SynchronousBPELProcess gets instantiated and starts its operations while Client waits for the response from the SynchronousBPELProcess.
3. SynchronousBPELProcess completes its operations and sends a response back to Client.
4. Client continues and completes its processing.

Case 2: Client invokes AsynchronousBPELProcess

1. Client invokes AsynchronousBPELProcess.
2. AsynchronousBPELProcess gets instantiated and starts its operations while Client also continues to perform its operations.
3. AsynchronousBPELProcess completes its operations and callback the Client with the response message.

Here we noticed that if a synchronous process is invoked, the operations of this process has to be completed first and only then the client is able to resume its operations while in the case of asynchronous both the process continues to perform their operations.

Fig1: An image showing bpel diagram of an asynchronous and a synchronous process.

What makes the difference?

Synchronous Process:

 The synchronous process defines one two way operation port to receive the request and send the response. Using the invoke activity the client invokes the Synchronous BPEL process on this port and waits to receive the response on the same port. As soon as the client receives the response from the BPEL process it continues with its flow. On the BPEL process side, the Synchronous BPEL process gets instantiated on receiving the client request and sends back the reply using the reply activity on the same port on which the Client is waiting.

Asynchronous Process:

In the asynchronous process two one way operations ports are defined to receive the request and send the response. On the client side, the client uses the invoke activity to invoke the asynchronous BPEL process and continues with its flow. It uses the receive activity to receive the response later in the flow. The asynchronous BPEL process receives the request on one of the ports and sends back the reply from another port (callback port). To send the response the asynchronous BPEL process invokes the client on the callback port using the callback activity.

Fig 2: An image showing the wsdl of an asynchronous and a synchronous process.

Fig 3: An image showing a call to asynchronous and synchronous process.

We also find different operation names like initiate, onResult and process in the .bpel file. These are just labels to differentiate between sync and async processes.

* A port is nothing but a method with input and output. So a two way operation port has an input and an output while a one way operation port has only input or output.

What is Service Oriented Architecture?

A Service Oriented Architecture is essentially a collection of services.

1. These services communicate with each other.
2. Services are software components that carry out business processes.
3. Services have well defined interfaces.
4. A service is the end point of a connection.
5. Services are the interfaces to the business logic.
6. Services are connected to each other with loosely coupled connections

Open Group's definition of SOA -

Service-Oriented Architecture (SOA) is an architectural style that supports service orientation.

Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services.

A service:

• Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data, consolidate drilling reports)
• Is self-contained
• May be composed of other services
• Is a “black box” to consumers of the service

Business Process Modeling

BPM is an enterprise integration technology complementing SOA, EAI, ESB. The business process orchestrates complex system interactions and is itself a web service that converses with other such services.

Modeling business processes

A business process describes how the work is done in an organization. It has specific inputs and outputs, uses resources and performs tasks in a specific order. The business processes are repeatable in nature. It specifies the potential execution order of operations from a collection of web services, the data shared between these web services.

Modeling languages used for BPM include Business Process Modeling Notation (BPMN), Business Process Execution Language (BPEL), Unified Modeling Language (UML), Web Services Choreography Description Language (WS-CDL).

Architectural Specializations And Other Roles

Product Architect: The product architect is responsible for the delivery of a software product. He is responsible for the various releases of the product.

Domain Architect: Domain architect focuses on a particular domain e.g. business architecture, data architecture, network architecture.

Solution Architect: The solution architect specifically takes a broad, high-level view of the entire solution.

Enterprise Architect: The enterprise architect is responsible for the cross-system information systems architecture of the whole enterprise, including sales and marketing, client-facing systems, products and services, purchasing and accounts, the supply chain, human resources, etc.

Business Analysts: A business analyst is responsible for capturing and documenting detailed business requirements.

Project Managers: A project manager is responsible for ensuring delivery of the product or system and meeting deadlines.

Design Authorities: A design authority is responsible for the quality of the internal element designs for the system.

Technology Specialists: A technology specialist provides detailed expertise in one specific area. The technology specialist provides depth in the specific area.

Developers: They are responsible for the software code.

Orchestration And Choregraphy

Web services can be used for implementing business processes and collaborations within and across organizations.

Two languages for web service composition available are-
1. Business Process Execution Language (WS-BPEL)
2. Choreography Description Language (WS-CDL)

Orchestration refers to composing web services for business processes. It is used for defining composite services and internal processes. It describes the private process model i.e. describes a specific business process that a web service executes. The orchestration approach assumes a single, central point of control over the entire scope of process execution.

Choreography refers to composing web services for business collaborations. It is used for defining how multiple parties collaborate in peer-to-peer manner as part of some larger business transaction. It describes the public process model i.e. describes the interaction in terms of the public (visible) message exchanges that occur between the web services. The choreography approach assumes execution control is shared, potentially across multiple business process engines or various technologies.

There are two reasons for separating the public and private aspects of the business process.

1. The internal processes and data can be hidden from the clients invoking the web services.

2. The implementation details of the the internal process can be changed without affecting the public business protocol.

Synchronous And Asynchronous Services

A client's interaction with a web service can be synchronous or asynchronous.

Synchronous services - With synchronous services, clients invoke a request on a service and then suspend their processing while they wait for a response. e.g.


Synchronous services are best suited when applications require a more immediate response to a request. Web services that rely on synchronous communication are usually RPC-oriented.

Asynchronous services - With asynchronous services (also dubbed document-style web services), clients initiate a request to a service and then resume their processing without waiting for a response. The service handles the client request and returns a response at some later point, at which time the client retrieves the response and proceeds with its processing.

A document-oriented approach is used for asynchronous class of services. Services which process documents tend to use an asynchronous architecture. A document-oriented Web service receives a document as a service request. The document content determines the processing workflow for the Web service. There can be a number of processing steps required to fulfill the request.


There are two ways to obtain the response -

• The client that invoked the service periodically checks the status of the request using the ID that was provided at the time the request was submitted. (This is also known as polling.)

• Or, The web service can then respond, at some later time, by making a call back to the client with the response.Therefore, a client of a web service that contains a callback operation is special in that the client itself must provide an endpoint. We call this the callback endpoint and define an endpoint as a unique address identified by a URI to which SOAP request messages can be sent.

Web service callbacks refer to scenarios that involve the web service provider sending a SOAP message back to its clients. The Web Services Description Language (WSDL) specifications define such operations as being of the type “solicit/response.” Clients of web services that support callback operations must have a web service endpoint themselves, which the web service can use for sending callback requests at any point in time, or, in other words, asynchronously.
The first approach is non-intrusive and an independent polling module can be developed that is responsible for getting the results.

The second approach requires an implementation of event-listener.

Best practices suggest that you should support both polling and callbacks when implementing an asynchronous web service. Supporting both approaches will make your service accessible to the widest audience of clients.