Dehydration/internal schemas in SOA 10g and SOA11g

One of the queries that I got recently was about the differences in the dehydration/internal schemas used from SOA 10g and SOA11g. So today’s blog is on what changed from 10g to 11g as far as dehydration/internal schemas are concerned. In SOA 10g BPEL engine used orabpel schemas extensively for storing the process as well as the instance audit details. ESB engine used oraesb schema for all its internal communications by using different topics (ERROR, CONTROL, MONITOR etc) as well as important server parameters. In the case of SOA 11g since the entire architecture has been revamped, the internal schemas were refactored so as to fit in the scheme of things.

In SOA11g BPEL and Mediator engine requires MDS repository and SOA Service Infrastructure database to start and run properly. MDS stand out as one of the new features in 11g. BPEL & Mediator uses MDS as process metadata store. During deployment of a composite, all the process metadata will be stored on to MDS. BPEL engine uses SOA infrastructure database for persisting the BPEL process state, audit information and instance details where as Mediator engine uses it to persist the messages and message states.

During startup of the soa-infra application, BPEL and Mediator engines are initialized and after that it will load all the composites from the MDS repository. If the composite contains any BPEL processes, it targets those individual components to the BPEL engine. If the composite contains any Oracle Mediator components, it targets them to the Oracle Mediator engine. Hope this helps