Biradar ShriKant Oracle SOA Blog

Dehydration Store Tables Extension Details

noreply@blogger.com (ShriKant Biradar) — Thu, 15 Mar 2018 18:15:00 +0530

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

noreply@blogger.com (ShriKant Biradar) — Thu, 15 Mar 2018 18:08:00 +0530

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.

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

Case 2: Client invokes AsynchronousBPELProcess

Client invokes AsynchronousBPELProcess.
AsynchronousBPELProcess gets instantiated and starts its operations while Client also continues to perform its operations.
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?

noreply@blogger.com (ShriKant Biradar) — Thu, 15 Mar 2018 17:34:00 +0530

A Service Oriented Architecture is essentially a collection of services.

These services communicate with each other.
Services are software components that carry out business processes.
Services have well defined interfaces.
A service is the end point of a connection.
Services are the interfaces to the business logic.
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