2. Asynchronous BPEL Template
3. OneWay BPEL Template
Q. What is
Asynchronous and Synchronous Services?
ReplyOutPut- Synchronous.one port.
Q. What Happens When You Create a SOA
Application and Project
· composite_name
A composite_name file is automatically created when you create a SOA project. This file describes the entire composite assembly of services, service components, references, and wires.
A BPEL directory
is created for BPEL processes.
A Mediators directory
is created for Oracle Mediators.
A HumanTasks directory
is created for human tasks.
An oracle/rules directory
is created for business rules.
Displays the business event files (.edn).
Displays the BPEL process schema files (.xsd).
Displays the test suite files.
Displays the transformation XSLT (.xsl) and XQuery (.xqy) mapper files.
Displays all WSDL files (.wsdl).
One-way
In one way message exchange pattern, source send message
to target service without expecting a response.
Source continue to execute process after sending message
to target service
Target service receives message from the source and does
not prepare any response.
Commonly known as fire and forget.
Synchronous
BPEL Process:
Synchronous web services provide an immediate response to an
invocation. BPEL can connect to synchronous web services through a partner
link, send data, and receive the reply in the same synchronous invocation.
In a synchronous interaction, a client sends a request to a
service and receives an immediate reply.
"Provider service receive request message, prepares a response message and send back the response message to consumer service" Consumer service remain active until it get response message.
Commonly known as Request/response.
"It has each operation with two message types, one
for input request and another for output response."
BPEL process waits for response from a synchronous
service after initiating synchronous service using invoke activity.
Always return a response or fault message.
BPEL
Process Service Component as the Client
When the BPEL process service component is on the client
side of a synchronous transaction, it needs an invoke activity. The port on the
client side both sends the request and receives the reply.
BPEL
Process Service Component as the Service
When the BPEL process service component is on the service
side of a synchronous transaction, it needs a receive activity to accept the
incoming request, and a reply activity to return either the requested
information or an error message defined in the WSDL.
Q. When u will
go for Sync process?
Whenever the services returns the response in few seconds,
it is recommended to go for synchronous BPEL process if not the BPEL process
should be Asynchronous the reason is calling application can’t proceed further
in case of synchronous process.
Q. What
Happens When You Invoke a Synchronous Web Service?
When you create a partner link and invoke activity, the necessary BPEL code for invoking a synchronous web service is added to the appropriate BPEL and Web Services Description Language (WSDL) files.
Ex: We have created a Synchronous BPEL Process which has a receive activity to accept the request from the user. The reply activity simultaneously sends the response back.
Asynchronous
BPEL Process :
Consumer service sends a request message to provider
service and does not wait for response.
Provider service receives request message, prepares a
response message and send back the response message to consumer service.
Consumer service defines call-back function to receive
response message from provider service.
Consumer service goes inactive state after sending
request until its get a response message.
Commonly known as Request/call-back, Asynchronous
Request/Response and Asynchronous with delayed response.
or
A Asynchronous Process is one which you call and need not
wait for the response before proceeding further. You may just initiate the
Asynchronous process and receive the response when you require it as a part of
your process, hence you are not forced to wait for response.
In an asynchronous interaction, a client sends a request to
a service and waits until the service replies.
Asynchronous services have two port types. Each port type
performs a one-way operation
(Asynchronous BPEL process is having two Port Types and each
of them supports single operation.)
· One port
type responds to the asynchronous process
· The other
calls back the client with the asynchronous response
Invoking
an Asynchronous Web Service
As discussed before Asynchronous Web Service is one which
sends a request to other web service and waits for the response.
Ex: we have created the Asynchronous BPEL Process which
has a receive activity to accept the request from the user. The assign activity
further assigns values to the different elements in the request.
Next, the invoke activity invokes the HelloWorld
Application which sends the response simultaneously and that is captured in
receive activity.
Further, we have the callback activity which finally
generates output and sends response asynchronously.
If you double-click
the receiveInput or callbackClient, you will see each of them
has only one variable.
receiveInput → inputVariable
callbackClient → outputVariable
How does
a async request run in the backend?
The sequence of events involved in the delivery of invoke
messages is as follows:
· The
client posts the message to the delivery service.
· The
delivery service saves the invocation message to the invoke_message table.The
initial state of the message is 0 (undelivered).
· The
delivery service schedules a dispatcher message to process the invocation
message asynchronously.
· The
dispatcher message is delivered to the dispatcher through the afterCompletion()
call. Therefore, the message is not delivered if the JTA transaction fails.
· 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.
· 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.
· MDB
fetches the invocation message from the dispatcher.
· 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.
Q) WS-Addressing
in an Asynchronous Service
There can be many active instances at any time, the server
must be able to direct web service responses to the correct BPEL process
service component instance. You can use WS-Addressing to identify asynchronous
messages to ensure that asynchronous callbacks locate the appropriate client.
Understanding
WS-Addressing
"WS-Addressing plays a very important role in Oracle
BPEL Process Manager's architecture for asynchronous processes. "
When an asynchronous BPEL process is invoked, you can
specify the callback information using WS-Addressing headers.
When BPEL has to make a callback to deliver the asynchronous
response, it will inspect those headers
and use the specified value to send the response.
async process in which the request is received in a one-way
fashion.
As determined by the architecture, the client does not get
an immediate response;
instead, the client is later stimulated by the called
process to receive the response via what is known as a "callback," two
bindings will be available, one for the request and one for the callback.
Q) What is the
difference between Async and Sync activity on wsdl level?
· Async wsdl-It has only input
messages for the operation and it has 2 operations one for sending the request
and other for call back.
· Sync wsdl-It has 2 messages input and output
messages for the wsdl operation.
Q) While creating BPEL Process what all pattern is available?
synchronous
Asynchronous
One Way
BPEL Process
Creates a process with a one-way call interface definition.
Define
Service Later
Select to create an empty BPEL process service component
with no activities.
Base on a
WSDL
Creates a BPEL process with an interface defined by an
existing WSDL file. You must specify the WSDL Uniform Resource Locator (URL),
port type, and callback port type to use.
Subscribe
to Events
Creates a BPEL process in which you can subscribe to a
business event. After selecting this option, the dialog refreshes to display an
event table. Click the Add icon to select an event to which to
subscribe. Your selection is then displayed in the event table. You can then
select the consistency level and whether to publish this event. You can also
click the Filter icon to create a filter expression for the selected
event. This selection launches the Expression Builder dialog.
Q) There are two types of request
Inbound: something which is coming from outer world toward us.
It will be always implicit (we need not to be initiated)
Outbound: where we r sending
It will be always explicit (need to be initiated)
Q) What is
Service Component?
All prebuilt components BPEL , Mediator, Business
Rules, Human Task and Spring known as service components.
Q) Can we
have more than one service component in one composite?
Yes, we can have as many as service components in one
composite but it is not recommended, we should not have all the components in
one composite itself.
Q) How
these Service Components works?
Each service component is hosted in its own service
engine container. E.g. Any logic added in BPEL components will be handled by
BPEL service engine only.
Service need to maintain state
Service requires complex transaction management
Requires multiple transactions
Compensation logic (if anything fails, something goes wrong)
required on rollback
Short or longed lived process (human task)
Exception handling required human workflow
Service need to handle asynchronous callback reliably
Composite is a combination of services , components, adapter
and wire.
Q) what is direct binding?
Direct binding enables Java clients to directly invoke composite services, bypassing the intermediate conversion to XML required with web service binding.
Inbound direct binding
The direct service binding component allows an external client to send messages using the Direct Binding Invocation API, where the Direct Binding Invocation API takes the JNDI connection parameters and creates a connection object on behalf of the client.
Outbound direct binding (or direct reference binding)
The direct reference binding component provides support for sending SOA messages directly to external services over RMI. These external services must implement the SOA invocation API, the same as the direct inbound invocation API.
SOA-DIRECT provides native connectivity between Oracle Service Bus and Oracle SOA Suite service components.
Q) What is
binding component?
As name
suggest, this component is used to bind composite application to external
world. i.e. we use these components to link composite with source and target system.
Q)
What are the types of Binding Components?
Binding components are of two types as mentioned
below.
1. Service Binding: With the help of this binding we connect
composite to source or client system or we can say this is entry point of
composite.
2. Reference Binding: This binding helps composite to
connect to target or reference systems or we can say it is exist point of the
composite.
Q)
Can we more than one Service & Reference binding in one composite?
Yes, we can
more than one service & reference binding in one composite, that means we
can have more than one entry & exist point for composite.
Q) What can
be scenario where we have two service binding in one composite?
When a composite can be initiated either by direct
call or by consuming the same message from JMS queue, in this scenario we have
two entry point for same composite.
Q) What can
scenario where we have two reference binding in one composite?
Composite
needs to send the message to first target by JMS queue and to other target by
writing the file, in this scenario we have two exist for composite.
Q) How can you
make a request dynamic?
"If you are on the lookout to send a request to a
variety of services that have the same value of WSDL, then the application has to
make in a dynamic manner. You can make the requested dynamic by making use of
the addressing schema. In this manner, the desired objectives can be met in an
efficient way."
Q) Partner
Link
It defines a relationship between two services.
Q) Partner
Links and Service Invocation
Service invocation is achieved using invoke activity of a
BPEL Process.
In invoke activity, we select required operations of the partner link and input/output variables.
Q) A BPEL
Process can have two type of partner link:
Q) How do you
create a partner link BPEL? How to make partner link dynamically ?
You can dynamically configure a partner link at runtime in
BPEL.
This is useful for scenarios in which the target service
that BPEL wants to invoke is not known until runtime
The most important point to be remembered when using dynamic
partnerlinks is that you need to ensure each process that you wish to call has
to be based on exactly the same WSDL
The message types, namespaces, port types, bindings etc…
Everything have to be same just the endpoint URL will be different
Dynamic partner links are only supported in BPEL 1.1
projects
Q) Each
partner link has WSDL file with following details:
2. Roles: which describe the port type.
3. Port type: which associate with a operations and message structure required to perform this operation.
Q) How can we
make a partner link dynamic?
If we have to send the request to different service which
has the same wsdl then dynamic partner link will be used and using addressing
schema we can set the endpoint dynamic to send the request to the desired
service.
Q) What are
transient and durable BPEL processes?
Durable:-It is
long running process and initiated through a one-way invocation and do incur
one or more dehydration points in the database during execution.
Durable processes have one or more midprocess breakpoint or
idempotent activities. Causing it to stop and wait for some event in the middle
of the process.
Durable process tend to be long-lived.
Ex: Asynchronous
Transient:-
Transient process do not have any midprocess breakpoint and
idempotent activities. They do not stop and wait for any event in the middle of
the process.
It is short-lived process, request-response style processes
and do not incur dehydration during their process execution Ex: Synchronous.
Note:
If there are any breakpoint activities, the process is
durable otherwise, the process is transient.
Q) How do we
handle transactions in BPEL?
Property needs to be defined to start the new transaction/to
continue with the same transactions
Property Name: Transaction and if this has value as required then the BPEL process will be
continued in the same transaction where as if the value is defined as requiresnew then it will start the new
transaction.
bpel.config.transaction property.
bpel.config.transaction=required
The caller's transaction is joined (if there is one) or a new transaction is created (if there is not one)
Invoked messages are processed using the same thread in the same transaction.
bpel.config.transaction=requiresNew
A new transaction is always created and an existing transaction (if there is one) is suspended.
Q) What is a
XA datasource? How it differs from a non-XA datasource?
An XA transaction involves a coordinating transaction manager, with one or more databases (or other resources, like JMS) all involved in a single global transaction.
Non-XA transactions have no
transaction coordinator, and a single resource is doing all its transaction
work itself (this is sometimes called local transactions).
Q) What do you
mean by non-idempotent activity? Which all activities are non-idempotent by
default?
Activities like Pick, Wait, receive, reply and checkpoint()
are called non-Idempotent activity and during the execution of the process
whenever these activities are encountered then it gets dehydrated to the
dehydration store.
Q) Dehydration
Saves current state of long running information. (Such as
when a process is waiting for asynchronous call back) in a dehydration
database.
It saves last state of the BPEL Process instance.
Q) What is
Dehydration store?
Dehydration store is the database where the instances get
stored when it gets dehydrated by the process on the occurrence of
non-idempotent activities and also stores the information on the long running
processes.
Q) Dehydrate
Activity
By default, dehydration points are set on activities such as
a receive, onMessage, onAlarm, and wait.
This activity acts as a dehydration point to automatically
maintain long-running asynchronous processes and their current state
information in a database while they wait for asynchronous callbacks.
Q) When does
dehydration occurs?
These are the three case when dehydration occurs.
è
When the BPEL instance encounters a midprocess
breakpoint activity,(excluding the initial receive). This only occurs to
durable and nontransient process.
è
When the BPEL instance encounters a
nonidempotent activity(such as invoke). On recovery from a crash, The BPEL
engine retires only the idempotent activities. Therefore, dehydration occurs
when the engine encounters a nonidempotent
activity."
è
When the BPEL instance finishes, The BPEL engine
saves the process instance to the dehydration
store, unless t is configured not to do so. This occurs to durable and
transient processes."
By default, all the BPEL process are dehydrated whether they
are synchronous or asynchronous.
"However, if a synchronous process does not need to be
durable, you can turn off dehydration mechanism by setting the properties (in
the BPEL Process deployment descriptor):"
inMemoryOptimization = true
copletionPersistPolicy = faulted/off
No comments:
Post a Comment