BPEL Related Interview Question & Answer
Q. What is choreography? How does it differ from
orchestration?
Orchestration
== Executable Process
Web
Service Orchestration relates to the execution of specific business processes.
WS-BPEL is a language for defining processes that can be executed on an
orchestration engine.
In this case we have a central controller process which controls and co-ordinates all the Web Services involved in the application. How the participating Web Services will be called, what will be the control flow, what all transformation will take place ... these all things are known only to the central controller process.
Choreography
== Multi-party Collaboration
Web
Service Choreography relates to describing externally observable
interactions between web services. WS-CDL is a language for describing
multi-party contracts and is somewhat like an extension of WSDL: WSDL describes web services interfaces; WS-CDL
describes collaborations between web services.
Here we don't have any central
controller process and hence all the participating Web Services know when to
call, whom to interact, when to execute operations, etc.
Orchestration has a central controller
process and all other participating Web Services don't know about the actual
business process. They are called only by the controller process and they don't
know anything about other Web Services involved in the application.
Whereas Choreography doesn't have any
controller process/service and all the participating Web Services know the
actual business process and they are well aware of which all Web Services they
need to interact with, when to execute the operations, etc.
Fault handling is easier in
Orchestration as the execution is controlled which is not the case with
Choreography. Web Services can be easily and transparently replaced in case of
Orchestration as the involved Web Services don't know the actual business
process whereas it'll be difficult in case of Choreography.
Thus, we see that Orchestration is having quite a few advantages over
Choreography and hence Orchestration is normally preferred for business process
implementations, but Choreography may certainly have its own usage in some
selected scenarios.
Q. What is BPEL?
Web Services Business Process Execution
Language (WS-BPEL) is an XML based programming language to describe high level
business processes. A 'business process' is a term used to describe the
interaction between two businesses or two elements in some business. An example
of this might be company A purchasing something from company B. BPEL allows
this interaction to be described easily and thoroughly such that company B can
provide a Web Service and company A can use it with a minimum of compatibility
issues.
The
BPEL language enables you to define how to:
1.
Send XML messages to, and asynchronously receive XML messages from, remote
services
2.
Manipulate XML data structures
3.
Manage events and exceptions
4.
Design parallel flows of process execution
5.
Undo portions of processes when exceptions occur
Q.
What is Web-Service?
In terms of BPEL, the term 'Web Service'
means something with which you can interact. For example, you could have a web
service which you can interact with to get the time of day, or a web service
you can interact with to buy a fridge. The web service can have any purpose.
A Web Service is typically described
using Web Service Description Language (WSDL). This is another XML based
language which allows you to describe the interface to the web service.
WSDL tells you exactly how you can
interact with the web service but says nothing about how the web service works.
Q. What is a pick activity? Can I have a pick activity
with no onMessage branch?
This activity waits for the occurrence
of one event in a set of events and performs the activity associated with that
event. The occurrence of the events is often mutually exclusive (the process
either receives an acceptance or rejection message, but not both). If more than
one of the events occurs, then the selection of the activity to perform depends
on which event occurred first. If the events occur nearly simultaneously, there
is a race and the choice of activity to be performed is dependent on both
timing and implementation.
onMessage branch is
mandatory.
The pick activity provides two branches,
each one with a condition. When you double-click the Pick
icon, the pick activity appears and displays these two
branches: onMessage
and onAlarm.
The onMessage
branch contains the code for receiving a reply, for example, from a loan
service. The onAlarm
branch contains the code for a timeout, for example, after one minute.
Whichever branch completes first is executed; the other branch is not. The
branch that has its condition satisfied first is executed.
Q. What are the different message exchange patterns in
BPEL?
The port type name attribute
provides a unique name among all port types defined within in the enclosing
WSDL document. WSDL has four transmission primitives that an endpoint can
support:
|
One-way
|
The operation can receive a
message but will not return a response
|
|
Request-response
|
The operation can receive a
request and will return a response
|
|
Solicit-response
|
The operation can send a request
and will wait for a response
|
|
Notification
|
The operation can send a message
but will not wait for a response
|
The most important message exchange
patterns are one-way, request/response, and request/callback (asynchronous
request/response).
For example, the request/response MEP
defines that a consumer sends a request message and waits for the answer, which
is sent by the provider as a response message.
What is
portType?
The <portType> element
combines multiple message elements to form a complete oneway or round-trip operation.
<portType name="Hello_PortType">
<operation
name="sayHello">
<input
message="tns:SayHelloRequest"/>
<output
message="tns:SayHelloResponse"/>
</operation>
</portType>
An abstract set
of operations supported by one or more endpoints (commonly known as an
interface); operations are defined by an exchange of messages. A portType is a
named set of abstract operations and the abstract messages involved.
What is port?
A
port number
is part of the addressing information used to identify the senders and
receivers of messages.
Q. What is the difference between Sync and Async activity
on wsdl level and BPEL Process as well?
The synchronous process defines one two
way operation port to receive the request and send the response.
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.
Synchronous
process using only one port for request and reply operation.
Asynchronous BPEL process is having two
Port Types and each of them supports single operation. That means 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.
Synchronous
BPEL process has one reply activity instead of callback. Synchronous BPEL
process WSDL is having single partnerLinkType instead of two.
Q. How does pick
activity differ from a receive activity?
Pick activity can act as a multiple receive
activity in some business scenarios. If we have two inbound operations and both
can trigger the bpel process then we will go with pick activity as we can’t
have two receive activity with create Instance box checked.
This activity enables you to specify one
or more activities to be performed concurrently. A flow activity completes when
all activities in the flow have finished processing. Completion of a flow
activity includes the possibility that it can be skipped if its enabling
condition is false.
It is parallel.
This property is used when you have more than one
invoke activity in parallel like in a typical flow activity.
By default, Oracle BPEL Process Manager
executes in a single thread by executing the branches sequentially instead of
in parallel. When this property is set to True, the process manager creates a
new thread to perform each branch's invoke activity in parallel. This property
is applicable to both durable and transient processes.
Consider setting this property to True
if you have invoke activities in multiple flow or flow n branches. This is
especially effective if the parallel invoke activities are two-way, but some
benefits can be realized for parallel one-way invokes as well.
This property enables you to execute a
synchronous BPEL process calling multiple synchronous Web services in flow in
real parallel mode. If you set the nonBlockingInvoke property to false, Oracle BPEL Server
blocks the Web service call until the other is finished.
What is a flowN activity and how does it leverages the
flow activity?
This
activity enables you to create activities within a flow. You specify the number
of branches of these activities to create.
Q. How does sync and async request run in the backend?
Synchronous
Process Execution:
The following steps are
performed:
1.
The
client calls a request on the delivery service (this can also be a BPEL
process).
2.
The
synchronous flow starts. In this case, the first activity is received.
3.
The
flow executes some activities, and then encounters a checkpoint, which is a
breakpoint activity (other breakpoint activities are received, onMessage, wait,
and onAlarm). Once the flow encounters this activity, the instance must be
dehydrated. The assign following the checkpoint is processed by another thread
in the background.
4.
The
thread (the one from the client) goes back to the delivery service and waits
for the reply from the reply queue. This waiting is subject to the
syncMaxWaitTime value. If this time is exceeded, then the client thread returns
to the caller with a timeout exception.
5.
Another
new background asynchronous thread picks up where the other thread left off. It
rehydrates the instance from the database, and executes the remaining
activities.
6.
When
the reply activity is executed, it puts the reply message in the reply queue.
7.
The
reply queue now notifies any waiters that the reply message is available. If
the waiter has not timed out, it gets the message. If it has timed out, the
message is not picked up (note that the flow has completed normally).
8.
If
the waiter has not timed out, it now has the reply message and returns to the
client with the message.
If the flow did not have
a checkpoint, then step 2 processes all the activities, including the reply
(which added the reply message to the queue). When the thread returns to the
delivery service, it waits for the reply. However, since the reply is already
there, it returns immediately and is not subject to the syncMaxWaitTime value.
In
addition, the synchronous process saves itself when it is finished.
Asynchronous
Process Execution:
From
JMS & DB operation perspective
The
sequence of events involved in the delivery of invokes messages is as follows:
1.
The
client posts the message to the delivery service.
2.
The
delivery service saves the invocation message to the invoke_message table. The
initial state of the message is 0 (undelivered).
3.
The
delivery service schedules a dispatcher message to process the invocation
message asynchronously.
4.
The
dispatcher message is delivered to the dispatcher through the afterCompletion ()
call. Therefore, the message is not delivered if the JTA transaction fails.
5.
The
dispatcher sends the JMS message to the queue. Places a very short JMS message
in the in-memory queue (jms/collaxa/BPELWorkerQueue) in OC4J JMS. The small JMS
message triggers the WorkerBean in the downstream step.
6.
This
message is then picked up by a WorkerBean MDB, which requests the dispatcher
for work to execute. If the number of WorkerBean MDBs currently processing
activities for the domain is sufficient, the dispatcher module may decide not
to request another MDB. The decision to request an DB is based on the
following:
7.
Ø
The current number of active MDBs
8.
Ø
The current number pending (that is, where a JMS message has been sent, but an MDB
has not picked up the message)
9.
Ø
The value of dspMaxThreads
10.
MDB
fetches the invocation message from the dispatcher.
11.
MDB
passes the invocation message to Oracle BPEL Server, which updates the
invocation message state to 1 (delivered), creates the instance, and executes
the activities in the flow until a breakpoint activity is reached.
From
Thread perspective
1.
Caller
thread T1 receives an incoming message and saves it to the internal delivery
queue. Thread T1 is then released by Oracle BPEL Server and the caller can
continue its own processing.
2.
Inside
the server, a message driven bean called WorkerBean monitors the queue for
invocation requests. The WorkerBean picks up the message from the delivery
queue, spawns a new thread (T2), and starts a Java Transaction API (JTA)
transaction (Txn1) to create and run the instance.
3.
Thread
T2 encounters a midprocess breakpoint activity (receive) and decides to
dehydrate the process instances.
4.
Thread
T2 retrieves a database connection (C1) from the data source connection pool.
5.
Thread
T2 saves the process instance to the dehydration database, which ends the
transaction (Txn1).
6.
Caller
thread T3 intercepts an invocation from the partner and saves the incoming
message to the delivery queue (dehydration point).
7.
The
Oracle BPEL Server WorkerBean picks up the message from the delivery queue,
spawns a new thread (T4), and starts a JTA transaction (Txn2) to continue the
instance.
8.
Thread
T4 encounters the end of the process and must dehydrate the process instance.
9.
Thread
T4 retrieves a database connection (C2) from the data source connection pool.
10.
Thread
T4 saves the process instance.
Q. Explain error handling in BPEL and what is error
handling framework?
A
BPEL fault has a fault name called a Qname (name qualified with a namespace)
and a possible messageType. There are two categories of BPEL faults:
Business
faults
Runtime
faults
Business
faults are application-specific faults that are generated when there is a
problem with the information being processed (for example, when a social
security number is not found in the database). A business fault occurs when an
application executes a throw activity or when an invoke activity receives a
fault as a response. The fault name of a business fault is specified by the
BPEL process service component. The messageType, if applicable, is defined in
the WSDL. A business fault can be caught with a faultHandler using the
faultName and a faultVariable.
<catch
faultName="ns1:faultName" faultVariable="varName">
Runtime
faults are the result of problems within the running of the BPEL process
service component or web service (for example, data cannot be copied properly
because the variable name is incorrect). These faults are not user-defined, and
are thrown by the system. They are generated if the process tries to use a
value incorrectly, a logic error occurs (such as an endless loop), a Simple
Object Access Protocol (SOAP) fault occurs in a SOAP call, an exception is
thrown by the server, and so on.
Synchronous Requests
When
exceptions arise in synchronous requests, we will not get enough time to
perform any corrective measures as response needs to be returned to the
requestor immediately. In such cases, we can only return faults to the
requestor. This is true for both BPEL and Mediator.
BPEL
can catch, throw and compensate for exceptions. Mediator can catch multiple
exceptions per operation and perform transformations before returning faults to
the initial caller.
Asynchronous Requests
As
the client of the service is not expecting an immediate response, asynchronous
requests provide us with enough time to correct any issues arising in the
request flow.
error handling framework
SOA Suite 11g offers an excellent tool
to handle exceptions at framework level. Usually business faults are handled at
component level and system faults at framework level.
Fault Management Framework lets us
handle exceptions through simple XML directives. Fault policies can be defined
in a file called fault-policies.xml. We can declaratively specify exceptions to
be handled through human intervention, retried, terminated or a combination of
any of these actions.
Q. What do you mean by non-idempotent activity? Which all
activities are non-idempotent by default?
All retriable activities
are idempotent by default. If idempotent is set to be false then it is a start
of new transaction and in other words a Dehydration point is created. recieve,pick,wait,checkpoint()
are non-idempotent by default.
Transient
Processes
Transient
processes do not incur dehydration during their process execution. If an
executing process experiences an unhandled fault or the server crashes,
instances of a transient process do not leave a trace in the system. Thus,
these instances cannot be saved in-flight regardless if they complete normally
or abnormally. Transient processes are typically short-lived, request-response
style processes. Synchronous processes are examples of transient processes.
Durable
Processes
Durable
processes incur one or more dehydration points in the database during
execution. Dehydration is triggered by one of the following activities:
·
Receive
activity
·
OnMessage
branch in a pick activity
·
OnAlarm
branch in a pick activity
·
Wait
activity
·
Reply
activity
·
checkPoint()
within a <bpelx:exec> activity
Durable
processes are typically long-living and initiated through a one-way invocation.
Because of out-of-memory and system downtime issues, durable processes cannot
be memory-optimized.
Q. Dehydration
in Oracle BPEL?
Storing the current status of the BPEL
process into the Database is known as dehydration. The Dehydration Store
database is used to store BPEL process status data, especially for asynchronous
BPEL processes. Also, all successfully executed BPEL process instances are
stored in the dehydration store. The database schema is created for this as a
part of SOA Suite installation is ORABPEL schema.
This property can only be set to True if
it does not have dehydration points. Activities like wait, receive, onMessage,
and onAlarm or a call to Async WSDL API create dehydration points in the
process. During the execution if any dehydration point is reached the instance
will get dehydrated irrespective of bpel process type (sync/async).
