Skip to Main Content
Forums

Integration

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

why is OSB called Stateless?

PruthviRaj KFeb 12 2016 — edited Feb 12 2016

Hi team,

I often hear this "OSB is stateless and BPEL is stateful", but never got a supporting explanation for the same. I have gone through this blog, again the same is mentioned here, but no theory on it. Can I get some possible Information on this?

Thanks in advance,

Pruthvi.
This post has been answered by AnatoliAtanasov on Feb 12 2016
Jump to Answer

Comments

AnatoliAtanasov
Answer

Hi Pruthvi,

I will try to give you my explanation on this. 

The main difference between the two components of Oracle SOA Suite (OSB and SOA Infrastructure service engines) is that SOA Infrastructure service engines, i.e. BPEL, Mediator, Business Rules, Human Workflow heavily uses the underlying database called SOA Infrastructure metadata store. For instance whenever you call a synchronous service developed in BPEL the service engine BPEL and the SOA infrastructure do a number of inserts in the SOA INFRA db. This process is also named as dehydration. Things get more complicated when we have asynchronous service - then we have both dehydration - storing the state of an application in the dehydration store (the SOA Infrastructure metadata store) and later restoring (rehydration) the state back in the server memory for further execution.

OSB on the other hand does not use such dehydration store, i.e. the OSB acts as a proxy which passes through (with some intermediate processing) the requests from service consumers to service producers. 

That is why OSB is stateless (it does not store the intermediate state of OSB application executions) as opposed to SOA which stores the application states in the dehydration store.

There are some cases when a SOA composite application can be configured as stateless which will prevent the SOA to store its state in the dehydration store.

Hope you will find my answer helpful and reasonable!

Regards,

A.

Marked as Answer by PruthviRaj K · Sep 27 2020
1 person found this helpful
PruthviRaj K

Thanks A, for clarifying me on this.

957742

Hi Pruthvi,

Adding to what Anatoli has mentioned earlier, the name itself says " Service Bus " which is used as a Virtualization layer to facilitate the transmission through to downstream/real services. Incase if something goes wrong dirting the transmission , there is no way you could store/log the messages within service bus. You need to look into out of box approaches to achieve this functionality. 

This is one of the main reasons as to why OSB is highly performance reliant because of its stateless nature. SOA on the other hand is a suite of components used for orchetration purposes and you could achieve asynchronous functionality as database support is provided within the product and dehydration feature allows to replay back the errored messages.

Hope it helps.

1 person found this helpful
1 - 3
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Mar 11 2016
Added on Feb 12 2016
#bpel, #soa-process-management, #soa-suite-discusssions
3 comments
2,173 views