Oracle SOA 12c Features

Oracle has released SOA Suite 12c and lots of new features are introduced in this release. Below is list of some of the new features.

Single Installer: Oracle Suite 12c comes as single installer for developers that means you only need to install only one setup (SOA Suite 12c), DB/Weblogic/SOA will get installed, you need to install it separately. Oracle SOA 12c use Java Derby database, which is file based and that makes it really fast.

Single IDE: In Oracle SOA 12c Jdeveloper is used as IDE for all designs. For OSB development we need not to use different IDE (Eclipse) anymore, we can develop OSB application in Jdeveloper itself.

Debugger: This is new feature in Oracle SOA 12c, debugger is introduced to debug SOA and OSB applications. With the help of debugger we can debug our code before deploying it; this saves lot of development efforts. We can also change message text while debugging it.

Graphical MDS: In Oracle SOA 12c graphical tool is provided to publish, search and consume filed from MDS and OER.

SOA Templates: With the introduction of templates sharing of code between teams become earlier and development efforts reduced. There are three types of templates introduced.

• Project Template
• Component Template
• Custom Activity Template

BPEL Sub-process: Sub-process is introduced in this launch which helps to reduce redundancy. Suppose we need to update database table 3 times in one flow so instead of add 3 different invoke to same BPEL, create sub-process which update the database table and use that sub-process 3 times in that BPEL. There are two types of sub-processes.

• Standalone sub-process
• Inline sub-process

Re-sequencing in OSB: In 11g this feature was available in Mediator, in Oracle SOA 12c this features added to service bus also, with the help of this feature we able to process the request message in proper sequence.

Adapter: Coherence, LDAP and cloud adapter are introduced in this release.

Xquery Mapper: In this release Xquery mapper is introduced which provide XQuery support.

Enterprise Service Scheduler: ESS is out of box scheduler. By using this we can schedule the services.

Translate Activity: Translate activity is also introduced which is used for Native to XML and XML to Native transformation.

MDS support for OSB: In 11g version MDS support was not there for OSB but in 12c MDS support is provided for OSB.

SOA Design Principles

Design Related Terms:

• Design Characteristic
• Design Principle
• Design Paradigm
• Design Pattern
• Design Standard
• Best Practice

Design Principle
Becoming proficient with the concepts and principles of service-orientation equips you with an understanding of what is and is not considered "service-oriented" within the world of solution design. This understanding leads to a clear comprehension of how to shape solution logic specifically in support of the strategic goals and benefits associated with SOA and service-oriented computing.

• Service Abstraction
• Service Autonomy
• Service Composability
• Service Discoverability
• Service Loose Coupling
• Service Reusability
• Service Statelessness
• Service-Orientation and Interoperability
• Standardized Service Contract

Specifically, the potential relationship between service-orientation design principles and patterns can be summarized as follows:

• Design principles are applied collectively to solution logic in order to shape it in such a manner that it fosters key design characteristics that support the strategic goals associated with service-oriented computing.
• Design patterns provide solutions to common problems encountered when applying design principles-and-when establishing an environment suitable for implementing logic designed in accordance with service-orientation principles.

In many ways, design principles and patterns are alike. Both provide design guidance in support of achieving overarching strategic goals. In fact, it would not be unreasonable to think of the eight service-orientation principles as super patterns

Service-orientation design principles have another role in that they collectively define service-orientation as a design paradigm. Ultimately, it is best to view design patterns as providing support for the realization of design principles and their associated goals.

SOA Design Patterns and Design Granularity

• Service Granularity - The overall quantity of functionality encapsulated by a service determines the service granularity. A service's granularity is determined by its functional context, which is usually established during the service modeling phase.
• Capability Granularity - The quantity of functionality encapsulated by a specific service capability determines the level of corresponding capability granularity.
• Data Granularity - The quantity of data exchanged by a specific service capability determines the level of its data granularity.
• Constraint Granularity - The extent of validation logic detail defined for a given service capability within the service contract determines the capability's level of constraint granularity. Generally, the more specific the constraints and the larger the amount of constraints, the more fine-grained the capability's constraint granularity is.

The effect of design patterns on service-related design granularity can vary. For example, when applying multiple patterns (or compound patterns) to the same service, the end-levels of design granularity may be distinctly defined by that combination of patterns (and they may fluctuate between the application of one pattern to another).

DB Adapter Singleton behaviour in High Availability Environment

We faced a problem in high availability environment (clustered).

We had one Integration between Oracle Ebiz and third party system in which we get the data from Oracle Ebiz and send it to third party application. This integration was running fine till the time our server environment upgraded for high availability means clustered ones...

We had two clusters which were configured to be synchronous to idealize HA situation. But this causes a design issue.

The issue started in our DB Adapter. Cluster1 and Cluster2 starts initiating DB Adapter instances which polling the Staging Table(OEBS) in parallel. If the clusters increased in future from 2 to 10 then 10 instances of pooling components will be created and will hit the third party application in parallel. This could be a problem for the target system if it doesn't supports parallel processing.

The solution to this problem is Singleton property in our pooling component / DB Adapter.

To enable this feature in high availability environment for a given inbound adapter endpoint, one must add the singleton JCA service binding property in the element within the composite.xml and set it to true as shown below:

Singleton Property in composite.xml

I hope this will help.