This post is all about how to access the SOAP headers using the mediator component in the oracle soa suite 11g.

Before looking at the steps to be followed to access the SOAP headers, first we need to understand the following things.

• SOAP Message structure (This is required to understand where actually the SOAP body message and SOAP headers reside in the entire message).
• Constructing WSDL to specify that SOAP headers will be accessed. (Without this jdeveloper design time cannot help you to build expressions using which you can access SOAP headers at run time).
• Way to populate the SOAP headers ( We will be using BPEL component to achieve this)
• Accessing the SOAP header value (We will be suing the Mediator component to achieve this).

 SOAP message structure
A SOAP message is made of an envelope and zero or more attachments..

A SOAP envelope is made of optional header and mandatory body parts..

Headers are always handled (or processed) by the intermediaries...and the
body is always handled (or processed) by the ultimate receiver..

The header is generally used for providing some contextual information, like, providing authentication related information, or providing transaction related information  etc...
 
Headers are used to represent that some special processing is required. Most of the WS-* standards use the header section to represent the special processing required . For example WS-Addresssing using this header section to represent where the ReplyTo message has to be sent.

Constructing WSDL


The following video shows how to construct the WSDL..It uses the jdeveloper tool to create and edit the WSDL file.

Way to populate SOAP headers


The following video shows how to use BPEL component to populate SOAP headers in the SOAP message.

Accessing SOAP header values
The following video shows how to access the SOAP header values in mediator.

http://jobinesh.blogspot.com/2011/03/overriding-rowqualifies-for-in-memory.html

Just run the following plsql block.

BEGIN
  FOR c IN
  (SELECT c.owner, c.table_name, c.constraint_name
   FROM user_constraints c, user_tables t
   WHERE c.table_name = t.table_name
   AND c.status = 'ENABLED'
   ORDER BY c.constraint_type DESC)
  LOOP
    dbms_utility.exec_ddl_statement('alter table ' || c.owner || '.' || c.table_name || ' disable  constraint ' || c.constraint_name|| ' cascade');
  END LOOP;
END;
/

What is the fail over feature provided by the Application Module?

The fail over feature decides when and how often passivation happens. When this feature is turned on, the application module state is turned on everytime an application module instance is returned back to the AM pool by the data control.

The advantage of this feature is that the user application state (model state), remains intact.

When should this feature be enabled/used?
This feature should be enabled only in the applications where its absolutely critical not to lose the data entered by the users at any cost.
Mostly it should be enabled, when we are dealing with a clustered environment.

When should we keep away from using this feature?
When this feature is enabled, passivation/activation happens for every request. This brings down the performance of the system . So in applications where its not critical to lose data, do no enable this feature. Especially when we are not dealing with a clustered environment then do not enable this feature.

How to enable/disable it?
This feature can be enabled or disabled by selection appropriate properties in the application module configuration on the Pooling and Scalability tab of the Business Components Configuration dialog.

 What is the default configuration?
This feature is disabled by default.

To create or clone a new partition in a MDS repository look into the following documentation
http://download.oracle.com/docs/cd/E14571_01/core.1111/e10105/repos.htm#CIHIDABJ

13.3.6.1 Cloning a Partition

In many cases you might want to group the soa composites so that it is easy to identify the required composite.
The best way to do this is to create a new partition and deploy the related soa composites to this partiton.

By default , if you don't speciy the partition name, all the composites are deployed to the "default" partition.

This blog shows how to create a new partition using the oracle fusion middleware enterprise manager console.

1.  Log into the em console
2.  Expand the SOA node  on the Left hand side navigation pane.
3.  Select the "soa-infra (server name)" node .
4.  On the Righthand side select the "soa-infrastructure"  related menu and select the menu "Manage Partitions"
5.  Now Create a new partition using the "create" icon.

EJB's and Exceptions
From an EJB method, if any unchecked excpetion is thrown, then it will be encapsulated in EJBException object...All checked exceptions are propagated without getting encapsulated by any other exception..

This is true for both Stateful and Stateless EJB's

Session Beans  and Exceptions
Whenever an EJB method throws any uncheked exception, then the container invalidates the EJB instance...During this process the container does'nt call the lifecycle listener method marked with PreDestroy...
When a checked exception is thrown, then the EJB instance is not invalidated...

When we say invalidated, it can mean many things..Its exactly implementation depends on the Application Server...However, the main thing to know is that, all further EJB method calls will be dealt by a different EJB instance...Some servers, might destroy the EJB completely...while some servers, return the instance to the EJB instance pool...

For Stateful Bean also when an Unchecked exception is thrown, the EJB Bean is completely destroyed...So we cannot call any other methods of the stateful EJB bean once an Uncheked exception is thrown (In case of stateful EJB, we can continue calling EJB methods, as a new EJB instance will be assigned for each method invocation)...For Checked exception, there is no problem...just like in stateless EJB..

@PreDestroy lifecycle callback method

The @PreDestroy method may not be called in all situations...When a Bean (stateful or stateless) is invalidated  then the method marked with the annotation "PreDestroy" does'nt get called...When the session bean timesout, the server may not call this lifecycle method (You have to contact the server doc for this)..

When a stateful bean has a method that is marked with the @Remove annotation and when the client calls this method, then the method marked with the annotation @PreDestroy will be called...

NOTE: When a method is marked with @Remove and @PreDestroy, then the method will be called twice when a client invokes the method once...