BPEL Performance Tuning Properties – 11g

Oracle SOA 11g 11. 1.1.6 Performance Tuning of BPEL Processes

BPEL Properties Set Inside a Composite

All the properties set in this section affect the behavior of the component containing the BPEL process only. Each BPEL process can be created as a component of a composite. These properties can be modified in composite.xml or in the System MBean Browser of Oracle Enterprise Manager Fusion Middleware Control. 

Some Concepts First

As a general practice, it is better to design your BPEL processes as transient instead of durable if performance is a concern. Note that this may not always be possible due to the nature of your process, but keep the following points in mind.

The dehydration store is uses to maintain long-running asynchronous BPEL instances storing state information as they wait for asynchronous callbacks. This ensures the reliability of these processes in the event of server or network loss. Oracle BPEL Process Manager supports two types of processes; transient and durable.

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

 inMemoryOptimization

This property indicates to Oracle BPEL Server that this process is a transient process and dehydration of the instance is not required. When set to True, the completionPersistPolicy is used to determine persistence behavior. This property can only be set to True for transient processes or processes that do not contain any dehydration points such as receive, wait, onMessage and onAlarm activities. The inMemoryOptimization property is set at the BPEL component level. When set to False, dehydration is disabled which can improve performance in some use cases.
Values:
This property has the following values:

• False (default): instances are persisted completely and recorded in the dehydration store database.
• True: The completionPersist policy is used to determine persistence behavior. 

completionPersistPolicy

This property configures how the instance data is saved. It can only be set at the BPEL component level.The completionPersistPolicy property can only be used when inMemoryOptimization is set to be True (transient processes). Note that this parameter may affect database growth and throughput (due to reduced I/O).

Value	Description
On (default)	The completed instance is saved normally
Deferred	The completed instance is saved, but with a different thread and in another transaction.
Faulted	Only the faulted instances are saved. Note: When an unhandled fault occurs, regardless of these flags, audit information of the instance is persisted within cube_instance table.
Off	No instances of this process are saved.

<component name="BPELProcess">
   <implementation.bpel src="BPELProcess.bpel" />

   <property name="bpel.config.completionPersistPolicy">faulted</property>
   <property name="bpel.config.inMemoryOptimization">true</property>
   ...
</component>

auditLevel

You can set the audit level for a BPEL process service component. This setting takes precedence over audit level settings at the SOA Infrastructure, service engine, and SOA composite application levels.

Set the bpel.config.auditLevel property to an appropriate value in the composite.xml file of your SOA project as shown in the example below:

<component name="BPELProcess">
<implementation.bpel src="BPELProcess.bpel" />
<property name="bpel.config.auditLevel">Off</property>
</component>

Value	Description
Inherit	Inherits the audit level from infrastructure level.
Off	No audit events (activity execution information) are persisted and no logging is performed; this can result in a slight performance boost for processing instances.
Minimal	All events are logged; however, no audit details (variable content) are logged.
Error	Logs only serious problems that require immediate attention from the administrator and are not caused by a bug in the product. Using this level can help performance.
Production	All events are logged. The audit details for assign activities are not logged; the details for all other activities are logged.
Development	All events are logged; all audit details for all activities are logged.

Partner Link Property

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 following Partner Link properties can be tuned for performance:

idempotent

An idempotent activity is an activity that can be retried (for example, an assign activity or an invoke activity). Oracle BPEL Server saves the instance after a nonidempotent activity. This property is applicable to both durable and transient processes.

Values:

This property has the following values:

• False: Activity is dehydrated immediately after execution and recorded in the dehydration store. When idempotent is set to False, it provides better failover protection, but may impact performance if the BPEL process accesses the dehydration store frequently.
• True (default): If Oracle BPEL Server fails, it performs the activity again after restarting. This is because the server does not dehydrate immediately after the invoke and no record exists that the activity executed. Some examples of where this property can be set to True are: read-only services (for example, CreditRatingService) or local EJB/WSIF invocations that share the instance's transaction.

A BPEL invoke activity is by default an idempotent activity, meaning that the BPEL process does not dehydrate instances immediately after invoke activities. Therefore, if idempotent is set to true and Oracle BPEL Server fails right after an invoke activity executes, Oracle BPEL Server performs the invoke again after restarting. This is because no record exists that the invoke activity has executed. This property is applicable to both durable and transient processes.

If idempotent is set to false, the invoke activity is dehydrated immediately after execution and recorded in the dehydration store. If Oracle BPEL Server then fails and is restarted, the invoke activity is not repeated, because Oracle BPEL Process Manager sees that the invoke already executed.

When idempotent is set to false, it provides better failover protection, but at the cost of some performance, since the BPEL process accesses the dehydration store much more frequently. This setting can be configured for each partner link in the bpel.xml file.

nonBlockingInvoke

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.

Note:

Invocations to the same partner link will happen in sequence and not in parallel. If you invoke different partner links each time with nonBlockingInvoke set to True, then each link will work in parallel even if all of the partner links point to the same source.

Values:

• True: Oracle BPEL Server spawns a new thread to execute the invocation.
• False (default): Oracle BPEL Server executes the invoke activity in the single process thread.

validateXML

Enables message boundary validation. Note that additional validation can impact performance by consuming extra CPU and memory resources.

Values:

• True: When set to True the engine validates the XML message against the XML schema during <receive> and <invoke> for this partner link. If the XML message is invalid thenbpelx:invalidVariables run time BPEL Fault is thrown. This overrides the domain level validateXML property.
• False (default): Disables XML validation.

General Recommendations:

1. If your Synchronous process exceed, say 1000 instances per hour, then its better to set inMemoryOptimization to true and completionPersistPolicyto faulted, So that we can get better throughput, only faulted instances gets dehydrated in the database, its goes easy on the purge (purging historical instance data from database)

2. Do not include any settings to persist your process such as (Dehydrate, mid process receive, wait or Onmessage)

3. Have good logging on your BPEL Process, so that you can see log messages in the diagnostic log files for troubleshooting.

What should you do?

• If the design of the process allows it, design your BPEL processes as short-lived, synchronous transactions.
• If the design of the process allows it, avoid the activities listed above.

Any time your process is dehydrated to the dehydration store, this naturally impacts the performance of the process, and becomes a concern particularly in high volume environments.

Oracle SOA 11g 11.1.1.6 Performance Tuning of BPEL Processes:BPEL Threading Model

Oracle SOA 11g 11.1.1.6 Performance Tuning of BPEL Processes:BPEL Threading Model

When the dispatcher must schedule a dispatch message for execution, it can enqueue the message into a thread pool. Each dispatch set can contain a thread pool (java.util.concurrent.ThreadPoolExecutor). The BPEL thread pool implementation notifies the threads when a message has been enqueued and ensures the appropriate number of threads are instantiated in the pool.

Dispatcher System Threads

The dspSystemThreads property specifies the total number of threads allocated to process system dispatcher messages. System dispatcher messages are general clean-up tasks that are typically processed quickly by the server (for example, releasing stateful message beans back to the pool). 

Typically, only a small number of threads are required to handle the number of system dispatch messages generated during run time.

The minimum number of threads for this thread pool is 1 and it cannot be set to 0 a or negative number.

The default value is 2. Any value less than 1 thread is changed to the default.

Dispatcher Invoke Threads

The dspInvokeThreads property specifies the total number of threads allocated to process invocation dispatcher messages. Invocation dispatcher messages are generated for each payload received and are meant to instantiate a new instance.
If the majority of requests processed by the engine are instance invocations (as opposed to instance callbacks), greater performance may be achieved by increasing the number of invocation threads. Higher thread counts may cause greater CPU utilization due to higher context switching costs.

The minimum number of threads for this thread pool is 1 and it cannot be set to 0 a or negative number.
The default value is 20 threads. Any value less than 1 thread is changed to the default.

Dispatcher Engine Threads

The dspEngineThreads property specifies the total number of threads allocated to process engine dispatcher messages. Engine dispatcher messages are generated whenever an activity must be processed asynchronously. If the majority of processes deployed are durable with a large number of dehydration points (mid-process receive, onMessage, onAlarm, and wait activities), greater performance may be achieved by increasing the number of engine threads.


Note that higher thread counts can cause greater CPU utilization due to higher context switching costs.

The minimum number of threads for this thread pool is 1 and it cannot be set to 0 a or negative number.
The default value is 30 threads. Any value less than 1 thread is changed to the default.

Dispatcher Maximum Request Depth

The dspMaxRequestDepth property sets the maximum number of in-memory activities to process within the same request. After processing an activity request, Oracle BPEL Process Manager attempts to process as many subsequent activities as possible without jeopardizing the validity of the request. Once the activity processing chain has reached this depth, the instance is dehydrated and the next activity is performed in a separate transaction.
If the request depth is too large, the total request time can exceed the application server transaction time out limit.This process is applicable to durable processes.

The default value is 600 activities.

Oracle SOA 11g 11.1.1.6 Performance Tuning of BPEL Processes:Audit

AuditLevel

The auditLevel property sets the audit trail logging level. This configuration property is applicable to both durable and transient processes. This property controls the amount of audit events that are logged by a process. Audit events result in more database inserts into the audit_trail table which may impact performance. Audit information is used only for viewing the state of the process from Oracle Enterprise Manager Console.

Value	Description
Inherit	Inherits the audit level from infrastructure level.
Off	No audit events (activity execution information) are persisted and no logging is performed; this can result in a slight performance boost for processing instances.
Minimal	All events are logged; however, no audit details (variable content) are logged.
Error	Logs only serious problems that require immediate attention from the administrator and are not caused by a bug in the product. Using this level can help performance.
Production	All events are logged. The audit details for assign activities are not logged; the details for all other activities are logged.
Development	All events are logged; all audit details for all activities are logged.

AuditDetailThreshold

The auditdetailthreshold property sets the maximum size (in kilobytes) of an audit trail details string before it is stored separately from the audit trail. If an audit trail details string is larger than the threshold setting, it is not immediately loaded when the audit trail is initially retrieved; a link is displayed with the size of the details string. Strings larger than the threshold setting are stored in theaudit_details table, instead of the audit_trail table.

The details string typically contains the contents of a BPEL variable. In cases where the variable is very large, performance can be severely impacted by logging it to the audit trail.

The default value is 50000 (50 kilobytes).

AuditStorePolicy

This property specifies the strategy to persist the BPEL audit data.

Value	Description
syncSingleWrite (default)	AuditTrail and dehydration are persisted to DB in one transaction.
syncMultipleWrite	AuditTrail and dehydration are persisted in the same thread but separate transactions.
async	AuditTrail and dehydration are persisted by separate threads and separate transactions.

By default, audit messages are stored as part of the main BPEL transaction. A BPEL instance holds on to the audit messages until the flow reaches dehydration. In some use cases, for example when you have a large loop, and there is no dehydration point in the loop, a large number of audit logs are accumulated. This could lead to an out-of-memory issue and BPEL main transaction can experience timeout errors. You may consider using syncMultipleWrite or async to store the audit message separately from the main transaction.
When you use syncMultipleWrite and async auditStorePolicy, there are a few other properties that need to be considered. Please see the sections below.

AuditFlushByteThreshold

This property controls how often the engine should flush the audit events, basically after adding an event to the current batch, the engine checks to see if the current batch byte size is greater than this value or not.
Consider tuning this property when async or syncMultipleWrite audit strageties are used. This size needs to be tuned based on the application.

AuditFlushEventThreshold

This property controls how often the engine should flush the audit events, basically when it reaches this limit of the number of events, the engine would trigger the store call.
Consider tuning this property when async or syncMultipleWrite audit strageties are used. This size needs to be tuned based on the application.

Oracle SOA 11g 11.1.1.6 Performance Tuning of BPEL: Significant Tips

OneWayDeliveryPolicy

The oneWayDeliveryPolicy is from the Oracle 10g configuration property deliveryPersistencePolicy.

The new configuration property name is bpel.config.oneWayDeliveryPolicy.

The oneWayDeliveryPolicy property controls database persistence of messages entering Oracle BPEL Server. By default, incoming requests are saved in the delivery service database tabledlv_message. These requests are later acquired by Oracle BPEL Server worker threads and delivered to the targeted BPEL process. This property persists delivery messages and is applicable to durable processes.
When setting the oneWayDeliveryPolicy property to async.cache, if the rate at which one-way messages arrive is much higher than the rate at which Oracle BPEL Server delivers them, or if the server fails, messages may be lost. In addition, the system can become overloaded (messages become backlogged in the scheduled queue) and you may receive out-of-memory errors. Consult your own use case scenarios to determine if this setting is appropriate.
One-way invocation messages are stored in the delivery cache until delivered. If the rate at which one-way messages arrive is much higher than the rate at which Oracle BPEL Server delivers them, or if the server fails, messages may be lost.

Value	Description
async.persist (Default)	Delivery messages are persisted in the database. With this setting, reliability is obtained with some performance impact on the database. In some cases, overall system performance can be impacted.
async.cache	Incoming delivery messages are kept only in the in-memory cache. If performance is preferred over reliability, this setting should be considered.
sync	Directs Oracle BPEL Server to bypass the scheduling of messages in the invoke queue, and invokes the BPEL instance synchronously. In some cases this setting can improve database performance.

MaximumNumberOfInvokeMessagesInCache

This property specifies the number of invoke messages that can be kept in the in-memory cache. Once the engine hits this limit, it would push the message to dispacther in-memory cache, instead it would save the message in the db and these saved messages can be recovered using recovery job. You can use value -1 to disable.
The default value is 100000 messages.

StatsLastN

The StatsLastN property sets the size of the most-recently processed request list. After each request is finished, statistics for the request are kept in a request list. A value less than or equal to 0 disables statistics gathering. To optimize performance, consider disabling statistics collection if you do not need them.
This property is applicable to both durable and transient processes.
The default value is -1.

LargeDocumentThreshold

The largedocumentthreshold property sets the large XML document persistence threshold. This is the maximum size (in kilobytes) of a BPEL variable before it is stored in a separate table from the rest of the instance scope data.
This property is applicable to both durable and transient processes.
Large XML documents impact the performance of the entire Oracle BPEL Server if they are constantly read in and written out whenever processing on an instance must be performed.
The default value is 10000 (100 kilobytes).

Validate XML

The validateXML property validates incoming and outgoing XML documents. If set to True, the Oracle BPEL Process Manager applies schema validation for incoming and outgoing XML documents. Nonschema-compliant payload data is intercepted and displayed as a fault.
This setting is independent of the SOA composite application and SOA Infrastructure payload validation level settings. If payload validation is enabled at both the service engine and SOA Infrastructure levels, data is checked twice: once when it enters the SOA Infrastructure, and again when it enters the service engine
CAUTION: Enabling XML payload validation can impact performance.
This property is applicable to both durable and transient processes.
The default value is False.

SyncMaxWaitTime

The SyncMaxWaitTime property sets the maximum time the process result receiver waits for a result before returning. Results from asynchronous BPEL processes are retrieved synchronously by a receiver that waits for a result from Oracle BPEL Server.
The default value is 45 seconds.

InstanceKeyBlockSize

The InstanceKeyBlockSize property controls the instance ID range size. Oracle BPEL Server creates instance keys (a range of process instance IDs) in batches using the value specified. After creating this range of in-memory IDs, the next range is updated and saved in the ci_id_range table.
For example, if instanceKeyBlockSize is set to 100, Oracle BPEL Server creates a range of instance keys in-memory (100 keys, which are later inserted into the cube_instance table as cikey). To maintain optimal performance, ensure that the block size is larger than the number of updates to the ci_id_range table.
The default value is 10000.

MaxRecoverAttempt

You can configure the number of automatic recovery attempts to submit in the same recoverable instance. The value you provide specifies the maximum number of times invoke and callback messages are recovered. Once the number of recovery attempts on a message exceeds the specified value, a message is marked as nonrecoverable.
When a BPEL instance makes a call to another server using invokeMessage, and that call fails due to a server down, validation error, or security exception, the invokeMessage is placed in a recovery queue and BPEL attempts to retry those messages. When there are many messages, and a majority of them are being sent to the same target, the target can become overloaded. Setting the appropriate value of MaxRecoveryAttempt will prevent excessive load on servers that are targeted from BPEL web service calls.

SOA Suite 11g - Transaction(s) boundaries and Threads

As we added new/updated components I figured it'd be wise to post a little bit about transaction semantics in 11g - and how they can be used to leverage the underlying JTA infrastructure that is backing the execution of components.

a) Mediator:
On the inbound side, when mediator is invoked via binding.ws it will create an manage a new transaction, otherwise (e.g. if invoked through an adapter it will inherit the existing transaction)

In more generic terms:
If a transaction is present, Mediator participates in that existing transaction. If transaction is not present, Mediator starts the transaction

In case of sync (aka sequential) routing rules, they will be all executed in the same transaction, and if an error occurs, a rollback will be issued.
Note: in this case even a fault policy that is configured against a mediator fault will NOT trigger.

In case of async routing rules, each rule will be executed in a new transaction, and if errors occur, a rollback will happen, and a fault policy can be configured to react to it.

b) BPEL:
By default (as in previous releases) BPEL will create a new transaction on request basis - that is if one already exists, it will be suspended, and a new one created. Upon completion of the child, the master one resumes.
However, if the request is async (that is one-way) we either inherit the transaction for the insert into the dehydration store (that is dlv_message in this case) or if one exists enlist transparently into it. So we guarantee you zero message loss. Either the invocation message is in the dehydration store, to be processed, or otherwise the consumer is notified via a fault.

In 10.1.3 we had a couple of flags that one could set on the consuming process (that is the partnerlink) as well as on the providing one, to chain an execution into a single global transaction. Namely, on the consumer side, one had to set transaction=participate on the partnerlink binding in bpel.xml, and on the providing side transaction=participate in the <configurations> section of bpel.xml.
In 11g BPEL - we adopted a more j(2)ee alike concept - and one only needs to set the (new) transaction flag on the calee bpel component. This can be done in the composite editor's source by adding bpel.config.transaction into a bpel component - as shown below

  <component name="InternalWarehouseService">

    <implementation.bpel src="InternalWarehouseService.bpel"/>

    <property name="bpel.config.transaction" 

         many="false" type="xs:string">required | requiresNew</property>

  </component>

The two possible values are required, which makes BPEL inherit the tx that is already there, or if not creating a new one (required), or suspending one if exists, and ALWAYS create a new one (requiresNew).

What are the implications of setting the above (the default is requiresNew)?

Case one - BPELCaller calls BPELCallee (the latter has requiresNew set)
a) BPELCallee replies (that is uses <reply>) with a fault: BPELCallee transaction is saved, BPELCaller get's the fault and can catch it
b) BPELCallee throws (that is uses <throw>) a fault, that is NOT handled: BPELCallee tx get's rolled back, BPELCaller get's the fault and can catch it
c) BPELCallee replies back with a fault (FaultOne), and then throws a fault (FaultTwo): BPELCallee tx get's rolled back, and BPELCaller get's FaultOne
d) BPELCallee throws (that is uses <throw>) a bpelx:rollback fault: BPELCallee tx get's rolled back, BPELCaller get's a remote fault

Case two - BPELCaller calls BPELCallee (the latter has required set)
a) BPELCallee replies (that is uses <reply>) with a fault: BPELCaller get's the fault and can catch it, BPELCaller owns the transaction - hence if he catches it - tx is committed, if BPELCaller does not handle it - global rollback.
b) BPELCallee throws (that is uses <throw>) a fault BPELCaller get's the fault and can catch it
c) BPELCallee replies back with a fault (FaultOne), and then throws a fault (FaultTwo): BPELCaller get's FaultOne
d) BPELCallee throws (that is uses <throw>) a bpelx:rollback fault: BPELCaller tx get's rolled back, no way to catch it.

So with the above in place - one thing that I usually have people try when they are in my 11g courses is to create two processes (BPELMaster and BPELChild), both sync, each using the same db adapter reference that inserts the same record (and hence causes a PK violation). (And of course has set xADatasourceName)

So what happens in the default (that is without bpel.config.transaction property set). Once the fault occurs, and is not handled - the BPELChild will rollback. If the BPELMaster has a catch block his transaction will commit, so you end up with the record from the Master in the db.

If you don't catch the fault in the master as well - you get a second rollback - two different transactions though :-)

The second exercise is to set the bpel.config.transaction to required, and run the testcase again. If no fault handlers are in place - the whole tx will rollback, based on the BPELMaster's unhandled fault.

Now add a fault handler in the BPELMaster to catch the Fault from the BPELClient - and throw up a rollback fault. Globally the tx will rollback as well.

With this in place - you can really control transaction boundaries and model end2end transactional flows (if your source / targets are transactional as well of course)

Here is the second post - this time on one-way invocations:

Usually a one way invocation (with a possible callback) is exposed in a wsdl as below

    <wsdl:operation name="process">

        <wsdl:input message="client:OrderProcessorRequestMessage"/>

    </wsdl:operation>

This will cause the bpel engine to split the execution into two parts. First, and always inside the caller transaction, the insert into the dlv_message table (in 10.1.3.x that is into the inv_message), and secondly the transaction & new thread that executes the workitems, and creates a new instance.

This has several advantages in terms of scalability - because the engine's threadpool (invoker threads) will execute when a thread is available. However, the disadvantage is that there is no guarantee that it will execute immediately.

If one needs to have a sync-type call based on a one way operation - then they can use onewayDeliveryPolicy, which is a forward port of deliveryPersistPolicy in 10.1.3.

This property can be set by specifying bpel.config.oneWayDeliveryPolicy in a bpel component of composite.xml. Possible values are "async.persist", "async.cache" and "sync". If this value is not set in composite.xml, engine uses the oneWayDeliveryPolicy setting in bpel-config.xml

async.persist => persist in the db
async.cache => store in an in-memory hashmap
sync => direct invocation on the same thread

Below is the matrix based on the usecase.

onewayDeliveryPolicy!=sync (default, callee runs in separate thread/treansation)

throw any fault
caller doesn't get response because message is saved in delivery service. The callee's transaction will rollback if the fault is not handled.

throw bpelx:rollback
caller doesn't get response because message is saved in delivery service. It will rollback on unhandled fault.

-------
onewayDeliveryPolicy=sync, txn=requriesNew (callee runs in the same thread, but different transaction)

throw any fault
caller gets FabricInvocationException. Callee transaction rolls back if the fault is not handled.

throw bpelx:rollback
caller gets FabricInvocationException. Callee transaction rolls back.

-------
onewayDeliveryPolicy=sync, txn=required (callee runs in the same thread and the same transaction)

throw any fault
Callee faulted. Caller gets FabricInvocationException. Caller has a chance to handle the fault.

throw bpelx:rollback
whole transaction rollback.

AIA Error Handling Email Notification explored

I will cover the steps required to enable/send error notifications in this post. AIA Error handling framework has out-of-the-box error email functionality. Incase of partner link errors like remote/binding faults the fault-policy.xml file should take care of sending the error notification/email. Incase of non-partner link error the AIAAsyncErrorHandlingBPEL process is called from catch-all block which inturn sends out the error email.

A sample fault-policy.xml file is shown below

<!--?xml version='1.0' encoding='UTF-8'?-->
<faultpolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy">
<faultpolicy version="3.0" id="CustomAIAPolicy" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.oracle.com/bpel/faultpolicy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<conditions>
<faultname xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:bindingFault">
<condition>
<action ref="aia-ora-java">
</action></condition>
</faultname>
<faultname xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:remoteFault">
<condition>
<action ref="ora-retry">
</action></condition>
</faultname>
</conditions>
<actions>
<action id="ora-retry">
<retry>
<retrycount>3</retrycount>
<retryinterval>2</retryinterval>
<exponentialbackoff>
<retryfailureaction ref="aia-ora-java">
</retryfailureaction></exponentialbackoff></retry>
</action>
<action id="ora-terminate">
<abort>
</abort></action>
<action id="default-replay-scope">
<replayscope>
</replayscope></action>
<action id="default-rethrow-fault">
<rethrowfault>
</rethrowfault></action>
<action id="default-human-intervention">
<humanintervention>
</humanintervention></action>
<action id="aia-ora-java">
<javaaction classname="oracle.apps.aia.core.eh.CompositeJavaAction" defaultaction="ora-terminate">
<returnvalue value="REPLAY" ref="ora-terminate">
<returnvalue value="RETHROW" ref="ora-rethrow-fault">
<returnvalue value="ABORT" ref="ora-terminate">
<returnvalue value="RETRY" ref="aia-ora-retry">
<returnvalue value="MANUAL" ref="ora-human-intervention">
</returnvalue></returnvalue></returnvalue></returnvalue></returnvalue></javaaction>
</action>
</actions>
<properties>
</properties></faultpolicy>
</faultpolicies>

In above file, the oracle.apps.aia.core.eh.CompositeJavaAction class file gets invoked when remote/binding fault occurs and takes care of sending the error notification to AIAIntegrationAdmin user.

A sample code for populating EBM Header in catch-all block is shown below

1. First create a variable named EBM_HEADER
<variable name="EBM_HEADER" element="ns3:EBMHeader"/>

ns3 here refers to corecom namespace.

2. Make sure your ABM_to_EBM.xsl or EBM_to_ABM.xsl are populating the EBM header section correctly (eg. EBMID, EBOName etc...)

3. In catch-all block make sure you are populating the EBM_HEADER before invoking the AIAAsyncErrorHandlingBPELProcess

<assign name="Assign_Fault">
           <copy>
            <from expression="ora:processXSLT('xsl/EBM_to_Fault.xsl',bpws:getVariableData('EBM_HEADER'))"/>
            <to variable="Invoke_AIAAsyncErrorHandlingBPELProcess_initiate_InputVariable"
                part="FaultMessage" query="/ns3:Fault"/>
          </copy>
          <copy>
            <from expression="ora:getFaultAsString()"/>
            <to variable="Invoke_AIAAsyncErrorHandlingBPELProcess_initiate_InputVariable"
                part="FaultMessage" query="/ns3:Fault/ns3:FaultNotification/ns3:FaultMessage/ns3:Text"/>
          </copy>
          <copy>
            <from expression="xpath20:current-dateTime()"/>
            <to variable="Invoke_AIAAsyncErrorHandlingBPELProcess_initiate_InputVariable"
                part="FaultMessage" query="/ns3:Fault/ns3:FaultNotification/ns3:ReportingDateTime"/>
          </copy>
          <copy>
            <from expression="ora:getProcessId()"/>
            <to variable="Invoke_AIAAsyncErrorHandlingBPELProcess_initiate_InputVariable"
                part="FaultMessage" query="/ns3:Fault/ns3:FaultNotification/ns3:FaultingService/ns3:ID"/>
          </copy>
          <copy>
            <from expression="'BPEL'"/>
            <to variable="Invoke_AIAAsyncErrorHandlingBPELProcess_initiate_InputVariable"
                part="FaultMessage" query="/ns3:Fault/ns3:FaultNotification/ns3:FaultingService/ns3:ImplementationCode"/>
          </copy>
          <copy>
            <from expression="ora:getInstanceId()"/>
            <to variable="Invoke_AIAAsyncErrorHandlingBPELProcess_initiate_InputVariable"
                part="FaultMessage" query="/ns3:Fault/ns3:FaultNotification/ns3:FaultingService/ns3:InstanceID"/>
          </copy>
          <copy>
            <from expression="ora:getECID()"/>
            <to variable="Invoke_AIAAsyncErrorHandlingBPELProcess_initiate_InputVariable"
                part="FaultMessage" query="/ns3:Fault/ns3:FaultNotification/ns3:FaultingService/ns3:ExecutionContextID"/>
          </copy>
        </assign>
      <invoke name="Invoke_AIAAsyncErrorHandlingBPELProcess" inputVariable="Invoke_AIAAsyncErrorHandlingBPELProcess_initiate_InputVariable"
              partnerLink="AIAAsyncErrorHandlingBPELProcess"
              portType="ns10:AIAAsyncErrorHandlingBPELProcess"
              operation="initiate"/>

Apart from this there are certain configurations which need to be done for successfully sending error emails.

1. Set the email driver properties from EM Console :

OutgoingMailServer :
OutgoingMailServerPort :
OutgoingMailServerSecurity :
OutgoingDefaultFromAddress:

2. In AIA_HOME/aia_instances/Instance_name/AIAMetaData/config/AIAConfigurationProperties.xml file , below properties should be set

<Property name="EH.INVOKE.NOTIFY">true</Property>
<Property name="FROM.EMAIL.ID">Email:AiaAdmin@oracle.com</Property>
<Property name="EH.DEFAULT.ACTOR.ROLE">AIAIntegrationAdmin</Property>

3. In User Messaging Preferences console (http://:/sdpmessaging/userprefs-ui) add email Id for user AIAIntegrationAdmin. Login to this console with AIAIntegrationAdmin/welcome1.

NOTE: Message channels are meant to be a single email address or phone number etc.But you can refer to an email distribution list if you want to send these emails to multiple persons.

4. Upload the AIAConfigurationProperties.xml file to MDS and Reload the configuration from AIA Console setup page.Make sure when you update UpdateMetaDataDP.xml for loading the AIAConfigurationProperties.xml into MDS it should look something like below:

<fileset dir="${AIA_HOME}/aia_instances/instance_name/AIAMetaData">
<include name="config/AIAConfigurationProperties.xml" />
</fileset>

Also if the Go buttons are not enabled on AIA Console Setup page, make sure the weblogic user has the role AIAApplicationUser associated with it. You can associate roles on the Weblogic Admin Console under Security Realms.

5. Also set Notification mode to 'Email' from 'SOA Administration' -> 'Workflow Notification Properties' in EM Console.

Learning About SOA through the Interview Questions

 What is SOA?

SOA stands for service oriented architecture. Before we define SOA let's first define a service. In the real world, a service is what we pay for and we get the intended service. For instance you go to a restaurant and order food. Your order first goes to the counter and then it goes to the kitchen where the food is prepared and finally the waiter serves the food.

Figure: Restaurant and services

So in order to order an item from a restaurant you need three logical departments / services to work together (counter, kitchen, and waiter).

In the same manner in software world, these services are termed as business services. They are self contained and logical. So let’s first define a business service, SOA definition will be just an extension of that.

Definition of business service: It’s a logical encapsulation of a self contained business functionality.

For instance the figure ‘order system’ shows a simple ordering system which is achieved by different services like payment gateway, stock system, and delivery system coming together. All the services are self contained and logical. They are like black boxes. In short we do not need to understand the internal details of how the business service works. For the external world it’s just a black box which takes messages and serves accordingly. For instance the ‘payment gateway’ business service takes the message ‘check credit’ and gives out output: does the customer have credit or not. For the ‘order system’ business service ‘payment gateway’ service is a black box.

Figure: Order system

Now let’s revise some bullet points of SOA before we arrive to the definition of SOA.

• SOA components are loosely coupled. When we say loosely coupled that means every service is self contained and exists alone logically. For instance we take the ‘payment gateway’ service and attach it to a different system.
• SOA services are black boxes. In SOA, services hide there inner complexities. They only interact using messages and send services depending on those messages. By visualizing services as black boxes, services become more loosely coupled.
• SOA service should be self defined: SOA services should be able to define themselves.
• SOA services are maintained in a listing: SOA services are maintained in a central repository. Applications can search the services in the central repository and use them accordingly.
• SOA components can be orchestrated and linked to achieve a particular functionality: SOA services can be used/orchestrated in a plug and play manner. For instance, the figure ‘Orchestration’ shows two services ‘Security service’ and ‘Order processing service’. You can achieve two types of orchestrations from it: one you can check the user first and then process the order, or vice-versa. Yes, you guessed right, using SOA we can manage a workflow between services in a loosely coupled fashion.

Figure: Orchestration

So let's define SOA.

SOA is an architecture for building business applications using loosely coupled services which act like black boxes and can be orchestrated to achieve a specific functionality by linking together.

(I) In SOA do we need to build systems from scratch?

No. If you need to integrate or make an existing system as a business service, you just need to create loosely coupled wrappers which will wrap your custom systems and expose the systems functionality in a generic fashion to the external world.

(I) Can you explain business layers and plumbing layers in SOA?

In SOA we can divide any architecture in two layers. The first which has direct relevance to the business as it carries out business functions. The second layer is a technical layer which talks about managing computer resources like database, web server, etc. This division is needed to identify a service. Consider the figure ‘Simple order system’. It has various components which interact with each other to complete the order system functionality.

Figure: Simple order system

The simple order system can be divided in to two layers (see figure 'business and plumbing layer' - one which is business related and second which is more technical related). You can see the plumbing layer consisting of data access layer, AJAX, and yes more technical stuff.

Figure: Business layer and plumbing layer

(I) What’s the difference between services and components?

Services are logical grouping of components to achieve a business functionality. Components are implementation approaches to make a service. The components can be in Java, C#, C++ but the services will be exposed in a general format like Web Services.

(A) Can you describe the complete architecture of SOA?

Figure ‘Architecture of SOA’ shows a complete view of an SOA. Please note this architecture diagram is not tied up with implementations of Microsoft, IBM etc. It’s a general architecture. Any vendor who implements SOA needs to fulfill the below SOA components. How they do it is completely their own technological implementation.

Figure: Architecture of SOA

The main goal of SOA is to connect disparate systems. In order that these disparate systems work they should message each other. ESB (Enterprise Service Bus) acts like a reliable post office which guarantees the delivery of messages between systems in a loosely coupled manner. ESB is a special layer which delivers messages between applications. In the figure we have shown a huge plump pipe. It’s not hardware or some wire etc. It’s a group of components/software which helps you send and receive messages between the disparate applications. Do not try to code your own ESB, you can think of buying one from Microsoft, IBM, Oracle, Progress, etc.

• SOA registry is like a reference database of services. It describes what each service does, where they are located, and how they can communicate. It’s a central reference of meta-data for services.
• SOA workflow allows us to define a work flow using services in the SOA registry. We will read more about BPM in further questions.
• Service broker reads the work flow and takes services from the SOA registry and ties them together. Service brokers are normally middleware like EAI (Enterprise application Integration) products. You can get a list of decent EAI from Sun, Microsoft, and IBM etc.

Process manager is nothing but a collection of SOA registry, SOA workflow, and service broker.

SOA supervisor is a traffic cop ensuring that services do not have issues. It deals mainly with performance issues of the system so that appropriate service levels are met. If any of the services have performance problems it sends messages to the proper infrastructure to fix the issue.

Note: The above explanation is of the general architecture for SOA. Any vendor (Microsoft, IBM, SUN, etc.) who gives a solution for SOA should have the above components in some or the other manner. As this is a software architecture book, we will not be covering specific vendor implementations. We would advise the reader to map this to their vendor products for a better understanding.

(I) Can you explain a practical example in SOA?

(I) What are ends, contract, address, and bindings?

These are the three terminologies on which SOA service stands. Every service must expose one or more ends by which the service can be made available to the client. The End consists of three important things: where, what, and how:

• Contract (What): Contract is an agreement between two or more parties. It defines the protocol how clients should communicate with your service. Technically, it describes parameters and return values for a method.
• Address (Where): An Address indicates where we can find this service. Address is a URL, which points to the location of the service.
• Binding (How): Bindings determine how this end can be accessed. It determines how communication is done. For instance, you expose your service, which can be accessed using SOAP over HTTP or binary over TCP. So for each of these communication mediums, two bindings will be created.

Below figure show the three main components of the end. You can see the stock ticker is the service class, which has an end hosted on www.soa.com with HTTP and TCP binding support and using the Stock Ticker interface type.

Figure: Endpoint Architecture

Note: You can also remember the end point by ABC where A stands for Address, B for bindings, and C for Contract.

(I) Are web-services SOA?

SOA is a thinking, it’s an architectural concept, and web service is one of the technical approaches to complete it. Web services are the preferred standards to achieve SOA.

• In SOA we need services to be loosely coupled. A web service communicates using the SOAP protocol which is XML based, which is very loosely coupled. It answers the what part of the service.
• SOA services should be able to describe themselves. WSDL describes how we can access the service.
• SOA services are located in a directory. UDDI describes where we can get the web service. This is nothing but the implementation of the SOA registry.

Above is the extract taken from 'codeproject' website.

Thank You codeproject for sharing the context.

------------------------------------------------------------------------------------------------------------------------

What are the main benefits of SOA ?

• SOA helps create greater alignment between IT and line of business while generating more flexibility - IT flexibility to support greater business flexibility. Your business processes are changing faster and faster and global competition requires the flexibility that SOA can provide.
• SOA can help you get better reuse out of your existing IT investments as well as the new services you’re developing today. SOA makes integration of your IT investments easier by making use of well-defined interfaces between services. SOA also provides an architectural model for integrating business partners’, customers’ and suppliers’ services into an enterprise’s business processes. This reduces cost and improves customer satisfaction

What is a reusable Service?

• It is an autonomous, reusable, discoverable, stateless functionality that has the necessary granularity, and can be part of a composite application or a composite service.
• A reusable service should be identified with a business activity described by the service specifications (design-time contract).
• A service’s constraints, including security, QoS, SLA, usage policies, may be defined by multiple run-time contracts, multiple interfaces (the WSDL for a SOAP Web Service), and multiple implementations (the code).
• A reusable service should be governed at the enterprise level throughout its entire lifecycle, from design-time through run-time. Its reuse should be promoted through a prescriptive process, and that reuse should be measured.

Talking about Service identification, which approach between top-down and bottom-up methodologies encourages re-use and maintenance ?

Since the top-down approach is business-driven it can be practical to separate the different concerns of business and IT on different plans, providing a common ground in between. So in most situations it the most appropriate if you want to improve reuse and ROI in the medium/long term. Anyway

How can you achieve loose coupling in a soa ?

One strategy for achieving loose coupling is to use the service interface (the WSDL for a SOAP Web Service) to limit this dependency, hiding the service implementation from the consumer. Loose coupling can be addressed by encapsulating the service functionality in a manner that limits the impact of changes to the implementation on the service interface. However, at some point you will need to change the interface and manage versioning without impacting service consumers, in addition to managing multiple security constraints, multiple transports, and other considerations

Do you recall any pattern which could be used to leverage loose coupling ?

The Mediation pattern, using an enterprise service bus (ESB), will help in achieving this.

Mediation will take loose coupling to the highest level. It will establish independence between consumers and providers on all levels, including message formats, message types (including SOAP, REST, XML, binary) and transport protocols (including HTTP, HTTPS, JMS).

Architecturally speaking this means the separation of concerns between consumers and providers on the transport, message type, and message format levels.

The Service of a SOA should be engineered as stateless or stateful ?

Service should be stateless. It may have a context within its stateless execution, but it will not have an intermediary state waiting for an event or a call-back. The retention of state-related data must not extend beyond a request/response on a service. This is because state management consumes a lot of resources, and this can affect the scalability and availability that are required for a reusable service.

What is composition of a Service ?

Composition is the process by which services are combined to produce composite applications or composite services. A composite application consists of the aggregation of services to produce an enterprise portal or enterprise process. A composite service consists of an aggregation of services that produces another reusable service. It’s just like combining electronic components to create a computer motherboard, and then using that motherboard in a computer. Think of the motherboard as a reusable composite service that is a component of the computer, and of the computer as the composite application.

How do I integrate my Legacy applications with SOA ?

Legacy applications are frequently at the core of your IT environment. With the right skills and tools, you need to identify discrete elements within your legacy applications and “wrap” them in standards-based interfaces and use them as services within your SOA.

How does the ESB fits in this picture ?

The Enterprise Service Bus is a core element of any SOA. ESBs provide the “any to any” connectivity between services within your own company, and beyond your business to connect to your trading partners. But SOA does not stop at just implementing an ESB. Depending on what your goals are, you may want to use an ESB to connect other services within your SOA such as information services, interaction services and business process management services. Additionally, you will need to consider development services and IT service management services. The SOA reference architecture can help you lay out an SOA environment that meets your needs and priorities. The ESB is part of this reference architecture and provides the backbone of an SOA but it should not be considered an SOA by itself.

The concept of SOA is nothing new, however why everyone started to talk about SOA only in the last years ?

Yes I agree the basic concept of SOA aren’t new, however some technology technology changes in the last 10 years made service-oriented architecture more practical and applicable to more organizations than it was previously. Among this:

• Universally-accepted industry standards such as XML, its many variants, and Web-services standards have contributed to the renewed interest in SOA.
• Data governance frameworks, which are important to a successful SOA implementation, have well test and refined over the years.
• A variety of enabling technologies and tools (e.g., modeling, development, infrastructure/middleware, management, and testing) have matured.
• Understanding of business and business strategies has grown, shifting attention from technology to the people, cultural changes, and process that are key business success factors.

What is the most important skill you need to adopt SOA ? technical or cultural ?

Surely cultural. SOA does require people to think of business and technology differently. Instead of thinking of technology first (e.g., If we implement this system, what kinds of things can we do with it?), practitioners must first think in terms of business functions, or services (e.g., My company does these business functions, so how can I set up my IT system to do those things for me most efficiently?).It is expected that adoption of SOA will change business IT departments, creating service-oriented (instead of technology-oriented) IT organizations.

Is SOA really needed on your opinion?

SOA is not for everyone. While SOA delivers significant benefits and cost savings, SOA does require disciplined enforcement of centralized governance principals to be successful. For some organizations, the cost of developing and enforcing these principals may be higher than the benefits realized, and therefore not a sound initiative.

Extracted from 

http://www.javagyan.com/preparing-for-an-interview/soa-interview-questions

------------------------------------------------------------------------------------------------------------

Questions for 3-5 years of Experience Candidates.

Question: What is role of Mediator?
Answer: Oracle Mediator provides a lightweight framework to mediate between various components within a composite application. Oracle Mediator converts data to facilitate communication between different interfaces exposed by different components that are wired to build a SOA composite application.


Question:Difference between Mediator & OSB?
Answer: OSB is all together different tool which is used for integration like SOA but the main purpose of OSB is to route the information and same we can do with mediator. The main difference two is, we go for Mediator when we want to route information between different components inside composite and go for OSB when we want to route the information between composites. Mediator is used light weight mediation and OSB is used for heavy weight mediation.


Question: What is echo in Oracle Mediator?
Answer: The purpose of the echo option is to expose all the Oracle Mediator functionality as a callable service without having to route it to any other service. For example, you can call an Oracle Mediator to perform a transformation, a validation, or an assignment, and then echo the Oracle Mediator back to your application without routing it anywhere else.

For synchronous operations with a conditional filter, the echo option does not return a response to the caller when the filter condition is set to false. Instead, it returns a null response.

The echo option is available for asynchronous operations only if the Oracle Mediator interface has a callback operation. In this case, the echo is run on a separate thread.

Question: What is re-sequencing in Mediator ?
Answer: The re-sequencing feature of the Oracle Mediator reorders sets of messages that might arrive to the Oracle Mediator in the wrong sequence. You can define re-sequencing for all operations in an Oracle Mediator or for a specific operation.

Question: Re-sequencing options available in mediator?
Answer:
Standard (based on input Id)
FIFO(based on time)
Best Efforts

Question: What is Schema-tron Validation?
Answer: Schema-tron is an XML schema language, and it can be used to validate XML contents in an XML payload.


Question: Types of routing exist in Mediator?
Answer: Static & Dynamic Routing.


Question: What is Dynamic Routing in Mediator ?
Answer: A dynamic routing rule lets you externalize the routing logic to an Oracle Rules Dictionary, which in turn enables dynamic modification of the routing logic in a routing rule. When you choose to create dynamic routing rule then it creates a new business rule service component that is wired to the Oracle Mediator service component within the SOA composite of the Oracle Mediator service component. The business rule service component includes a rule dictionary. The rule dictionary is a metadata container for the rule engine artifacts, such as fact types, rulesets, rules, decision tables and so on. Inside routing rules, you need to set endpoint URI.



Question: Types of Static Routing rules?
Answer: Sequential & Parallel.



Question: Difference between Sequential & Parallel static routing rules ?
Answer:

A routing rule can be executed either in parallel or sequentially. To specify an execution type for a routing rule, select the Sequential or Parallel execution type in the Routing Rules section.

Basic Principles of Sequential Routing Rules

Oracle Mediator processes sequential routing rules based on the following principles:

• Oracle Mediator evaluates routings and performs the resulting actions sequentially. Sequential routings are evaluated in the same thread and transaction as the caller.
• Oracle Mediator always enlists itself into the global transaction propagated through the thread that is processing the incoming message. For example, if an inbound JCA adapter invokes an Oracle Mediator, the Oracle Mediator enlists itself with the transaction that the JCA adapter has initiated.
• Oracle Mediator propagates the transaction through the same thread as the target components while executing the sequential routing rules.
• Oracle Mediator never commits or rolls back transactions propagated by external entities.
• Oracle Mediator manages the transaction only if the thread-invoking Oracle Mediator does not already have an active transaction. For example, if Oracle Mediator is invoked from inbound SOAP services, Oracle Mediator starts a transaction and commits or rolls back the transaction depending on success and failure.

Basic Principles of Parallel Routing Rules

Oracle Mediator processes routing rules in parallel based on the following principles:

• Oracle Mediator queues and evaluates routings in parallel in different threads.
  The messages of each Oracle Mediator service component are retrieved in a weighted, round-robin fashion to ensure that all Oracle Mediator service components receive parallel processing cycles. This is true even if one or more Oracle Mediator service components produce a higher number of messages compared to other components. The weight used is the message priority set when designing an Oracle Mediator service component. Higher numbers of parallel processing cycles are allocated to the components that have higher message priority.
  You can set the Priority field in the Mediator Editor to indicate the priority of an Oracle Mediator service component. Priorities can range from zero to nine, with nine being the highest priority. The default priority is four.
  
  Note:

  The Priority property is applicable only to parallel routing rules.
• Oracle Mediator initiates a new transaction for processing each parallel rule. The initiated transaction ends with an enqueue to the Oracle Mediator parallel message dehydration store.
  For example, if an Oracle Mediator service component has one parallel routing rule, one message is enqueued on the Oracle Mediator parallel message dehydration store. The parallel message dispatcher to the store then initiates a transaction, reads the message from the database store, and invokes the target component or service of this routing rule. The transaction initiated by the listener thread is a completely new transaction and is propagated to the target components.
  
  Note:

  Dehydrating of messages means storing the incoming messages in a database for parallel routing rules so they can be processed later by worker threads.
• Oracle Mediator commits or rolls back transactions because it is the initiator of these transactions.

If an operation or event has both sequential and parallel routing rules, first sequential routing rules are evaluated and actions are performed, and then parallel routings are queued for parallel execution.

Note:

If an Oracle Mediator service component with a request-response interface has only parallel routing rules, the Oracle Mediator service component does not send a response back to the caller. Though you can create this type of Oracle Mediator service component, the caller of the Oracle Mediator service component does not receive a response at runtime.

Question: Which static routing rule support fault policy ?
Answer: Parallel rules only.



==============================================================Part1==========================================

Oracle SOA Interview Questions Part - 1

Question: What is WSDL ?
Answer : WSDL stands for Web Services Description Language

WSDL is a document written in XML. The document describes a Web service. It specifies the location of the service and the operations (or methods) the service exposes.

Question: Explain elements/tags of WSDL ?
Answer : 
types
A container for abstract type definitions defined using XML Schema
message
A definition of an abstract message that may consist of multiple parts, each part may be of a different type
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 

binding
A concrete protocol and data format specification for a particular portType
service
A collection of related endpoints, where an endpoint is defined as a combination of a binding and an address (URI)


Question: Difference between Abstract and Concrete WSDL ?
Answer : Abstract WSDL contains only messages and operations. Abstract WSDL is
used by SOAP Server.

Where as concrete WSDL contains messages, operations and transport
specific information (JMS or Http). This is used by SOAP client.

Question : What is SOAP ?
Answer : SOAP is a simple XML-based protocol to let applications exchange information over HTTP.
Or more simply: SOAP is a protocol for accessing a Web Service.

Question : What is XML Schema ?
Answer : An XML Schema describes the structure of an XML document.

Question : Difference between Include and Import in context to XML schema ?
Answer : The fundamental difference between include and import is that you must use import to refer to declarations or definitions that are in a different target namespace and you must use include to refer to declarations or definitions that are (or will be) in the same target namespace.

Question : What is targetNamespace's function?
Answer :
<schema xmlns="http://www.w3.org/2001/SchemaXML         targetNamespace="http://www.example.com/name" xmlns:target="http://www.example.com/name">

The targetNamespace declares a namespace for other xml and xsd documents to refer to this schema. The target prefix in this case refers to the same namespace and you

would use it within this schema definition to reference other elements, attributes, types, etc. also defined in this same schema definition.


==============================Part2================================================================================

Oracle SOA Interview Questions Part- 2
Question : How to refer another XSL from main XSL file ?
Answer :  The <xsl:import> element is a top-level element that is used to import the contents of one style sheet into another.

Note: This element must appear as the first child node of <xsl:stylesheet> or <xsl:transform>.
Syntax: <xsl:import href="URI"/>


Question: Why we use Call-template inside XSL ?
Answer : Call-template works similar to the apply-template element in XSLT. Both attach a template to specific XML data. This provides formatting instructions for the

XML. The main difference between the two processes is the call function only works with a named template. You must establish a 'name' attribute for the template in

order to call it up to format a document.

<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
< xsl:call-template name="myTemplate">
< !-- Content: xsl -->
< /xsl:call-template>
< stylesheet>


Question: Difference between XA & Non-XA transaction ?
Answer:
Non-XA (Local Transaction):  It involves only one resource. When you use Non-XA transaction then you can’t involve multiple resources (different databases, Queues,application servers etc), you can rollback or commit transaction for only one resource. There is no transaction manager for this transaction as we are dealing with only one resource at a time.
XA (Global Transaction): It involves more than one resource (different databases, queues, application servers) all participate in one transaction. It uses two-phase commit to ensure that all resources either all commit or rollback any particular transaction. When you have scenario like you need to connect to two different databases, JMS Queue and application server, in this case you will use XA transaction that means all resource participate in one transaction only.


Question: What is inline schema ?
Answer: Inline schema are XML schema definitions included inside XML instance documents. Like external schema documents, inline schema can be used to validate that the instance matches the schema constraints.


Question: what is the use of Pick Activity?
Answer: 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 multiple events occur, 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.

Question: Design patterns in SOA ?

Question: Difference between Synchronous Process and Asynchronous Process ?

Question: Use of Config Plans?


Qn. What is a wsdl? Explain its structure.
Ans. WSDL is a xml based language for describing web services and how to access them. The major elements in wsdl are.
       <types> the data types used by the WS
       <message> the messages used by the WS
       <porttype> operations performed by the WS
       <binding> the communication protocols used by the WS.
eg:-  <message name ="getTermRequest">
           <part name = "term" type ="xs:string">
        </message>
        <message name ="getTermResponse">
           <part name = "value" type ="xs:string">
        </message>
        <portType>
           <operation name ="getTerm">
            <input message = "getTermRequest"/>
            <output message = "getTermResponse"/>
           </operation>
       </portType>

Qn. What is SOA? What is a Service?
           SOA provides an enterprise architecture that supports building connected enterprise applications to provide solutions to business problems.
          A service is a distinct unit of business functions.


Oracle Mediator


Qn.  Difference between SOA suite 10g and 11g?
Ans: Basically all the SOA components like BPEL, ESB (Called Mediator in 11g), & OWSM are brought into one place in 11g using SCA composite concept.
The major difference between 10g & 11g would be the app server container. 10g by default runs on OC4J while 11g runs on Weblogic Server. 


Qn. What is the role of Oracle Mediator?
Ans: Oracle Mediator provides a lightweight framework to mediate between various components within a composite application. Oracle Mediator converts data to facilitate communication between different interfaces exposed by different components that are wired to build a SOA composite application.
  
Qn.What is resequencing and dynamic routing in mediator?
Ans: The resequencing feature of the Oracle Mediator reorders sets of messages that might arrive to the Oracle Mediator in the wrong sequence. You can define resequencing for all operations in an Oracle Mediator or for a specific operation.
A dynamic routing rule lets you externalize the routing logic to an Oracle Rules Dictionary, which in turn enables dynamic modification of the routing logic in a routing rule.


Qn. What is echo in Oracle Mediator?
You can also echo source messages back to the initial caller after any transformation, validations, assignments, or sequencing operations are performed. An echo can only be specified if the Oracle Mediator component has a synchronous or asynchronous interface. Whether the echo is synchronous or asynchronous depends on the WSDL file of the caller. The echo option is only available for inbound service operations and is not available for event subscriptions.

The purpose of the echo option is to expose all the Oracle Mediator functionality as a callable service without having to route it to any other service. For example, you can call an Oracle Mediator to perform a transformation, a validation, or an assignment, and then echo the Oracle Mediator back to your application without routing it anywhere else.

Qn. What is schematron validation?
Ans: You can specify Schematron files for validating an inbound message and its various parts. Schematron version 1.5 is the supported version.
Schematron is an XML schema language, and it can be used to validate XML.

Qn. Difference between OSB and Mediator?
Ans:  Mediator:

• Light weight intra composite mediation
• Domain Value mapping and Xref(cross referencing) support.
• Capability to create data type assertions in XML trees
• Message transformation using XSLT.
• Development within Jdeveloper

OSB

• Larger,more heavy weight inter composite enterprise service bus
• Serves as a logical proxy to physical services effectively providing service virtualization
• Message throttling, service pooling and reliable messaging.
• Message transformation using XQuery and XSLT.
• Eclipse or web console based development

File Adapter:-

Qn. What is file debatching?
Ans: When a file contains multiple messages, you can choose to publish messages in a specific number of batches. This is referred to as debatching. During debatching, the file reader, on restart, proceeds from where it left off in the previous run, thereby avoiding duplicate messages. File debatching is supported for files in XML and native formats. 

Qn. What is sync read option in file adapter? How is it different from read?

Ans: Sync Read option in BPEL file adapter allows us to read the file from the middle of the process, this is different from the Read option which polls for the new files and is the start of the BPEL process.

As we design the file adapter for sync read it asks for the file name whcih is static, this means that only file with this given name will be read.

BPEL Activites:-

Qn. Compensate Activity

Ans: This activity invokes compensation on an inner scope activity that has successfully completed. This

activity can be invoked only from within a fault handler or another compensation handler. Compensation

occurs when a process cannot complete several operations after completing others. The process must return

and undo the previously completed operations.

Qn. Pick Activity

Ans:  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 multiple

events occur, 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.

Qn. Replay Activity

Ans: This activity enables you to reexecute the activities inside a selected scope