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.
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 singlepartnerLinkType 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).
No comments:
Post a Comment