Implementing Asynchronous communication with Oracle Service Bus

Its a more prevalent requirement to design asynchronous web services when dealing with long running business process and its well known fact that Oracle SOA suite has got a very robust implementation support using WS-Addressing under the hoods.

But there aren't many examples available which depicts how the same can be implemented through technologies like Oracle Service Bus. There are couple of well-defined patterns available like

Using JMS for example to decouple the request and callback

Using SOA-Direct / SB Transport binding - Using WS-Addressing internally.

But there may be situations like:

• The architecture doesn't allow using proprietary transport bindings 
• Using JMS is a overkill. 
• Require better fault management requirement.

For these situation fortunately, we can still use WS-Addressing in OSB to decouple request/response albeit with additional extra work.

The suggested pattern is shown below :

The WS-Addressing has been forwarded to the external system using a customer header to decouple the pattern logic from the external system. I will try to explain the implementation with a much simpler example.

WS-Addressing purpose is to provide a standard way to specify where a message is going and where to send the response (or) the fault back. The below wsdl specifies the contract for Hello World Asynchronous service with the request sent using 'sayHello' operation and the response/fault is retrieved through 'sayHelloResponse' (or) 'sayHelloFaultResponse' respectively.

Schema

<?xml version="1.0" encoding="UTF-8" ?><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://techsamples.fmw/v1/HelloWorldAsync"
    targetNamespace="http://techsamples.fmw/v1/HelloWorldAsync" elementFormDefault="qualified" xmlns:flt="http://techsamples.fmw/v1/FaultObject">
    <xsd:import schemaLocation="../xsd/techsamples.fmw.cmn.FaultObject.xsd" namespace="http://techsamples.fmw/v1/FaultObject"></xsd:import>
    <xsd:element name="sayHello" type="tns:SayHelloType"/>
    <xsd:complexType name="SayHelloType">
        <xsd:sequence>
            <xsd:element name="name" type="xsd:string"/>
        </xsd:sequence>
    </xsd:complexType>
    
    <xsd:element name="sayHelloResponse" type="tns:SayHelloResponseType"/>
    <xsd:complexType name="SayHelloResponseType">
        <xsd:sequence>
            <xsd:element name="result" type="xsd:string"/>
        </xsd:sequence>
    </xsd:complexType>
    
    <xsd:element name="sayHelloFaultResponse" type="tns:SayHelloFaultResponseType"/>
    <xsd:complexType name="SayHelloFaultResponseType">
        <xsd:sequence>
            <xsd:element ref="flt:faultObject"/>
        </xsd:sequence>
    </xsd:complexType></xsd:schema>

WSDL Contract

<?xml version="1.0" encoding="UTF-8" ?><wsdl:definitions targetNamespace="http://techsamples.fmw/v1/HelloWorldAsync" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
    xmlns:tns="http://techsamples.fmw/v1/HelloWorldAsync" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
    xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    xmlns:flt="http://techsamples.fmw/v1/FaultObject">
    <wsdl:types>
        <xsd:schema>
            <xsd:import schemaLocation="techsamples.fmw.ebm.HelloWorldAsync.xsd"
                namespace="http://techsamples.fmw/v1/HelloWorldAsync"/>
            <xsd:import schemaLocation="../xsd/techsamples.fmw.cmn.FaultObject.xsd" namespace="http://techsamples.fmw/v1/FaultObject"></xsd:import>            
        </xsd:schema>
    </wsdl:types>
    <wsdl:message name="serviceFault">
        <wsdl:part name="serviceFault" element="flt:faultObject"/>
    </wsdl:message>
    <wsdl:message name="sayHello">
        <wsdl:part name="sayHello" element="tns:sayHello"/>
    </wsdl:message>
    <wsdl:message name="sayHelloResponse">
        <wsdl:part name="sayHelloResponse" element="tns:sayHelloResponse"/>
    </wsdl:message>
    <wsdl:message name="sayHelloFaultResponse">
        <wsdl:part name="sayHelloFaultResponse" element="tns:sayHelloFaultResponse"/>
    </wsdl:message>
    
    <wsdl:portType name="HelloWorldAsync.PortType">
        <wsdl:operation name="sayHello">
            <wsdl:input message="tns:sayHello"/>
        </wsdl:operation>
    </wsdl:portType>
    <wsdl:portType name="HelloWorldAsyncCallback.PortType">
        <wsdl:operation name="sayHelloResponse">
            <wsdl:input message="tns:sayHelloResponse"/>
        </wsdl:operation>
        <wsdl:operation name="sayHelloFaultResponse">
            <wsdl:input message="tns:sayHelloFaultResponse"/>
        </wsdl:operation>
    </wsdl:portType>
    
    <wsdl:binding name="HelloWorldAsync.Binding" type="tns:HelloWorldAsync.PortType">
        <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
        <wsdl:operation name="sayHello">
            <soap:operation soapAction="sayHello" style="document"/>
            <wsdl:input name="sayHello">
                <soap:body use="literal"/>
            </wsdl:input>
        </wsdl:operation>
    </wsdl:binding>
    
    <wsdl:binding name="HelloWorldAsyncCallback.Binding" type="tns:HelloWorldAsyncCallback.PortType">
        <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
        <wsdl:operation name="sayHelloResponse">
            <soap:operation soapAction="sayHelloResponse" style="document"/>
            <wsdl:input name="sayHelloResponse">
                <soap:body use="literal"/>
            </wsdl:input>
        </wsdl:operation>
        <wsdl:operation name="sayHelloFaultResponse">
            <soap:operation soapAction="sayHelloFaultResponse" style="document"/>
            <wsdl:input name="sayHelloFaultResponse">
                <soap:body use="literal"/>
            </wsdl:input>
        </wsdl:operation>
    </wsdl:binding>
    <wsdl:service name="HelloWorldAsync.Service">
        <wsdl:port binding="tns:HelloWorldAsync.Binding" name="HelloWorldAsync.Port">
            <soap:address location="http://@@osb.target.address@@/techsamples.fmw/HelloWorldAsync"/>
        </wsdl:port>
    </wsdl:service>
    <wsdl:service name="HelloWorldAsyncCallback.Service">
        <wsdl:port binding="tns:HelloWorldAsyncCallback.Binding" name="HelloWorldAsyncCallback.Port">
            <soap:address location="http://@@osb.target.address@@/techsamples.fmw/HelloWorldAsyncCallback"/>
        </wsdl:port>
    </wsdl:service></wsdl:definitions>

Artefacts

• HelloWorldAsync.Proxy - Proxy to handle the HelloWorldAsync.Binding(sayHello operation)
• HelloWorldAsyncCallback.Proxy - Proxy for the callback wsdl binding(sayHelloResponse & sayHelloFaultResponse operations). The expectation is that the response will always flow through this proxy. In this example, there is no external service,so HelloWorldAsync.proxy will directly send the callback response via this proxy. 
• HelloWorldAsyncClientCallback.biz - Abstract business service representing the actual callback client whose endpoint & the operation(action) are set at runtime using WS-Addressing.
• HelloWorldAsync Client BPEL Process - Client BPEL Process - The client process which call the HelloWorldAsync.sayHello operation and waiting for the callback.

HelloWorldAsync.Proxy

The SetCallbackURI assign activity in the CommonInitializationPipelinePair determines the recipient for the actual route(ideally this would be that of the external service) but for the simplicity we are setting it to the callback proxy directly. The xquery would look like something below:

if(fn:exists($inbound/ctx:transport/ctx:request/tp:headers/http:Host)) then
(
 <Callback>{fn:concat("http://",$inbound/ctx:transport/ctx:request/tp:headers/http:Host/text()[normalize-space(.)],"/techsamples.fmw/HelloWorldAsyncCallback")}</Callback>
)
else
(
 if($header/*:To/text()[normalize-space(.)]!='') then
 ( 
  <Callback>{fn:concat("http://",fn:substring-before(fn:substring-after($header/*:To/text()[normalize-space(.)],"http://"),"/"),"/techsamples.fmw/HelloWorldAsyncCallback")}</Callback> 
 )
 else
 (
  <Callback/> 
 )
)

the below image shows the routing part which sets the WS-Addressing for the callback to forward the response to the actual client.

Similar to the response callback, if there are any faults in the processing, it will managed by 'MainErrorHandler' and the fault is dispatched to the callback proxy as a fault response:

Also, note that on the call back proxy, you can decide the operational branch selection based on the WS-Addressing as well as shown below: HelloWorldAsyncCallback.Proxy Now the callback's responsibility is to forward the response back to the client that is waiting for the response. Firstly we capture the final destination from the WS-Addressing header:-


The routing below shows the response is forwarded to the HelloWorldAsyncClientCallback business service, which in turn sends the response to the Callback Client using WS-Addressing.

HelloWorldAsyncClientProcess The below client bpel process invokes the 'sayHello' operation in the HelloWorldAsync proxy and waits for the response or fault via the callback ports:



Lets run the client process and see the outcome ...



Lets throw a dummy error from the proxy mimicking a fault from the external service and see how the fault is propagated to the client.

That' all.. In the next instalment I will try to put a sample to implement the same scenario using jaxws web services.

Simple Script to switch jdk in mac

With the Oracle FMW 12c version release, one of the normal requirement is to switch between multiple jdk versions for 12c & 11g build environments in mac. Below is a simple script which can help you to do that:

function switchjdk() {  
  if [ -z $1 ]; then
 echo "please provide with the right jdk version to switch"
  else
 echo "switching to jdk version --- $1"
 export PATH=$(echo $PATH | sed -E -e "s;:$JAVA_HOME/bin?;;" -e "s;$JAVA_HOME/bin:?;;")
 export JAVA_HOME=$(/usr/libexec/java_home -v $1)
 export PATH=$JAVA_HOME/bin:$PATH
 echo $(java -version)
  fi  
 }  
switchjdk $1

Oracle Service Bus Deployment - Offline export of Config jar

With PS6, Oracle Service Bus provides the utility jar (com.bea.alsb.tools.configjar.ant.ConfigJarTask) to export the OSB configuration jar without requiring OEPE.

A sample ant task as provided by the Oracle documentation is given below:

<project name="ConfigExport" default="usage" basedir=".">

    <property environment="env" /> 
    <property name="mw.home" location="${env.MW_HOME}" /> 
    <property name="wl.home" location="${env.WL_HOME}" /> 
    <property name="osb.home" location="${env.OSB_HOME}" /> 

    <taskdef name="configjar" 
             classname="com.bea.alsb.tools.configjar.ant.ConfigJarTask" /> 

    <target name="init">
       <property name="task.debug" value="false" /> 
       <property name="task.failonerror" value="true" /> 
       <property name="task.errorproperty" value="" /> 
    </target>

    <target name="run" depends="init">
       <fail unless="settingsFile"/>
       <configjar debug="${task.debug}" 
                  failonerror="${task.failonerror}" 
                  errorProperty="${task.errorproperty}" 
                  settingsFile="${settingsFile}" />
    </target>
</project>

The task expects a mandatory settingsFile parameter, which dictates the rules (files inclusion/exclusion) with regards to OSB project that needs to be exported.

A sample settingsFile as provided by the Oracle documentation is given below:

<configjarSettings xmlns="http://www.bea.com/alsb/tools/configjar/config">
    <source>
        <project dir="/scratch/workspaces/myworkspace/projectX"/>
        <project dir="/scratch/workspaces/myworkspace/projectY"/>
        <extensionMapping>
            <mapping type="Xquery" extensions="xquery,xq,xqy"/>
            <mapping type="XML" extensions="toplink"/>
        </extensionMapping>
    </source>
    <configjar jar="/scratch/workspaces/myworkspace/sbconfig.jar">
        <resourceLevel/>
    </configjar>
</configjarSettings>

The source element defines the source artefacts that needs to be picked up during the load phase and the configjar element defines the details about the configuration jar and what projects/resources it should include.

In this post we will take a look at how this task can be mavenized and the settingsFile can be externalized, so that we don't need to explicitly create different settingsFile for each deployment unit.

The first step is to create the custom settingsFile and load the same into the maven repository.

osb-project-settings.xml

<?xml version="1.0" encoding="UTF-8" ?>
<p:configjarSettings xmlns:p="http://www.bea.com/alsb/tools/configjar/config">
    <p:source>
        <p:project dir="@@osb.project.dir.path@@"/>
        <p:fileset>
            <p:exclude name="*/.settings/**" />
            <p:exclude name="*/import.*" />
            <p:exclude name="*/pom.xml" />
            <p:exclude name="*/target/**" />
            <p:exclude name="*/security/**" />
            <p:exclude name="*/import.*" />
            <p:exclude name="*/alsbdebug.xml" />
            <p:exclude name="*/configfwkdebug.xml" />
            <p:exclude name="*/*settings.xml" />
            <p:exclude name="*/@@osb.project.export.jar@@" />
        </p:fileset>
    </p:source>
    <p:configjar jar="@@osb.project.export.jar@@">
        <p:projectLevel includeSystem="@@osb.include.system@@">
            <p:project>@@osb.project.name@@</p:project>
        </p:projectLevel>
    </p:configjar>
</p:configjarSettings>

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
    http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion> 
    <parent>
        <groupId>techsamples.fmw</groupId>
        <artifactId>parent</artifactId>
        <version>1.0</version>
    </parent>
    <groupId>techsamples.fmw</groupId>
    <artifactId>osb-build-config</artifactId>
    <packaging>jar</packaging>
    <version>1.0</version>
    <name>osb-build-config</name>
    <!-- copy osb-project-settings.xml  & osbImport.py files -->
    <build>
        <resources>
            <resource>
                <directory>${project.basedir}</directory>
                <includes>
                    <include>osb-project-settings.xml</include>
                    <include>osbImport.py</include>
                </includes>
            </resource>
        </resources>
    </build>
</project>

Now lets load the osb-project-settings-file into the maven repository

The osb-project-settings.xml file will be unpacked from the repository as part of the deployment process and all the tokens are substituted during runtime with the osb project specific details. This way we don't need to have different settings file for each project.

Below are the plugin details for

• Unpacking the settings file
• Replacing the tokens in the settings file
• Export/Deploy the osb configuration jar 

<plugin>
    <artifactId>maven-dependency-plugin</artifactId>
    <dependencies>
        <dependency>
            <groupId>techsamples.fmw</groupId>
            <artifactId>osb-build-config</artifactId>
            <version>1.0</version>
        </dependency>
    </dependencies>
    <executions>
        <execution>
            <id>unpack-osb-build-config-files</id>
            <phase>process-resources</phase>
            <goals>
                <goal>unpack</goal>
            </goals>
            <configuration>
                <artifactItems>
                    <artifactItem>
                        <groupId>techsamples.fmw</groupId>
                        <artifactId>osb-build-config</artifactId>
                        <version>1.0</version>
                        <overWrite>true</overWrite>
                        <outputDirectory>${project.build.directory}</outputDirectory>
                        <includes>
                            *
                        </includes>
                    </artifactItem>
                </artifactItems>
                <overWriteReleases>true</overWriteReleases>
                <overWriteSnapshots>true</overWriteSnapshots>
            </configuration>
        </execution>
    </executions>
</plugin>
<plugin>
    <groupId>com.google.code.maven-replacer-plugin</groupId>
    <artifactId>replacer</artifactId>
    <version>1.5.3</version>
    <executions>
        <execution>
            <id>replace-tokens</id>
            <phase>process-resources</phase>
            <goals>
                <goal>replace</goal>
            </goals>
        </execution>
    </executions>
    <configuration>  
        <includes>  
            <include>${project.build.directory}/osb-project-settings.xml</include>    
        </includes>  
        <replacements>
            <replacement>
                <token>@@osb.project.export.jar@@</token>
                <value>${project.artifactId}-${project.version}.jar</value>
            </replacement>
            <replacement>
                <token>@@osb.project.dir.path@@</token>
                <value>${basedir}/${project.artifactId}</value>
            </replacement>
            <replacement>
                <token>@@osb.project.name@@</token>
                <value>${project.artifactId}</value>
            </replacement>
            <replacement>
                <token>@@osb.include.system@@</token>
                <value>${osb.include.system}</value>
            </replacement>
        </replacements>
    </configuration>
</plugin>
<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>exec-maven-plugin</artifactId>
    <version>1.2.1</version>
    <executions>
        <execution>
            <id>export-sbconfigjar</id> 
            <phase>package</phase>
            <goals>
                <goal>exec</goal>
            </goals>
            <configuration>
                <executable>java</executable>
                <commandlineArgs>-Dosb.home=${osb.product.home} -Dweblogic.home=${wls.product.home} -classpath ${osb.classpath} com.bea.alsb.tools.configjar.ConfigJar -settingsfile ${project.build.directory}/osb-project-settings.xml</commandlineArgs>
                <removeAll>true</removeAll>
            </configuration>
        </execution>
        <execution>
            <id>deploy</id>
            <phase>deploy</phase>
            <configuration>
                <executable>java</executable>
                <commandlineArgs>
                    -Dosb.home=${osb.product.home} -Dweblogic.home=${wls.product.home} -classpath ${osb.classpath}
                    -Dwls.deploy.userid=${wls.deploy.userid}
                    -Dwls.deploy.password=${wls.deploy.password}
                    -Dadmin.target.serverURL=t3://${admin.target.address}
                    -Dosb.project.name=${project.artifactId}
                    -Dosb.project.export.jar=${project.build.directory}/${project.artifactId}-${project.version}.${project.packaging}
                    -Dosb.project.customizationFile=${project.basedir}/${project.artifactId}/${project.artifactId}-customizationFile.xml
                    weblogic.WLST ${project.build.directory}/osbImport.py</commandlineArgs>
                
            </configuration>
            <goals>
                <goal>exec</goal>
            </goals>
        </execution>
    </executions>
</plugin>

SOA 12c - Accessing soainfra database

SOA12c has been bundled into a single installation package to provide a quick start for everyone to use it easily without the hassles like running rcu.. but it does mean that as a developer you are not directly exposed to the soa-infra schema, if you want to play with the underlying tables and how the data is being created behind the scenes.

When you set up the integration domain for SOA12c, internally a JavaDB(Apache Derby DB) database 'soainfra' gets created. To give a bit of background on what a JavaDB is - It is a RDBMS primarily aimed for embedded java applications where in the client-server model & clustering is not the main priority.

The JavaDB is included as part of the JDK installation and can be accessed via either EmbeddedDriver(org.apache.derby.jdbc.EmbeddedDriver) for the embedding application (or) via the Derby Network Server drivers(org.apache.derby.jdbc.ClientDriver, org.apache.derby.jdbc.ClientXADriver) for other clients.

Lets see how we can setup the clients to access the soainfra db for SOA 12c.

JavaDB has a built-in interactive SQL client - 'ij' which can be used to query the schemas/tables in the database. Below image shows how to use the tool -

The other easy option is to use the JDeveloper to setup an IDEConnection to the soa-infra database as shown below:

Enter the soainfra db details for building the custom jdbc url.

Click on the Library search icon to verify the right version of the library for the driver.

Test the connection

Now we can query the soainfra schema :)

Unfortunately, I think currently the SQL Developer doesn't have the support for JavaDB and hence cannot use it.

Maven Support for Oracle Fusion Middleware 12c - SOA/OSB/Coherence

I am sure you are one among many who have been waiting for Oracle to provide native support for building their various technology artefacts through maven. In a way they started doing it from 11gR2, but the support really lacked in terms of built-in plug-in / archetype support for building applications for technologies like SOA,OSB,ADF,Coherence etc.. The main problem was to find a way to describe the dependencies to compile,build & package the artefacts for different projects that are part of the above listed technologies.

With the release of 12c, things have been changing and when SOA 12c was released late last week, I couldn't resist myself to check the maven support as the first thing. 

Oracle Maven Synchronization Plug-in
Oracle Maven Synchronization plug-in provides a mechanism for Oracle to handle library dependencies & technology plug-ins from a Oracle Home perspective (i.e) it allows us to populate the repository for a Oracle Home and any patching going forward will allow us to sync the repository for that particular environment without affecting other installations.

It is shipped with Oracle weblogic server, Jdeveloper & Oracle coherence installation bundles and to install/deploy into a repository, you should provide the Oracle Home details as well to manage the synchronization going forward. When we install the plug-in, it looks for all the maven artefacts in the Oracle Home & installs them in the specified Maven repository. This ensures that the version numbers would match exactly at the binary level ensuring the consistency.

Installation Process
In my laptop, I have a maven local repository and also configured 'Artifactory' as the remote repository. Below shows the remote repository configuration in the maven settings.xml file.

#Maven settings.xml configurations
<servers>
    <server>
      <id>lib-snapshot</id>
      <username>admin</username>
      <password>{jbf3GAd5kk8H/zUwaYzA2dDzabrj+jrSVwN76oM3FZ4=}</password>
    </server>
    <server>
      <id>lib-release</id>
      <username>admin</username>
      <password>{jbf3GAd5kk8H/zUwaYzA2dDzabrj+jrSVwN76oM3FZ4=}</password>
    </server>
    <server>
      <id>plugin-release</id>
      <username>admin</username>
      <password>{jbf3GAd5kk8H/zUwaYzA2dDzabrj+jrSVwN76oM3FZ4=}</password>
    </server>
    <server>
      <id>plugin-snapshot</id>
      <username>admin</username>
      <password>{jbf3GAd5kk8H/zUwaYzA2dDzabrj+jrSVwN76oM3FZ4=}</password>
    </server>
  </servers>
<profile>
      <id>artifactory</id>
      <repositories>
        <repository>
          <snapshots><enabled>false</enabled></snapshots>
          <id>lib-release</id>
          <name>Repository for library release</name>
          <url>http://localhost:8081/artifactory/libs-releases-local</url>
          <layout>default</layout>
          </repository>
        <repository>
          <snapshots></snapshots>
          <id>lib-snapshot</id>
          <name>Repository for snapshots</name>
          <url>http://localhost:8081/artifactory/libs-snapshots-local</url>
          <layout>default</layout>
        </repository>
        <repository>
          <snapshots></snapshots>
          <id>ext-snapshot</id>
          <name>Repository for external snapshots</name>
          <url>http://localhost:8081/artifactory/ext-snapshots-local</url>
          <layout>default</layout>
        </repository>
        <repository>
          <snapshots></snapshots>
          <id>ext-release</id>
          <name>Repository for external release</name>
          <url>http://localhost:8081/artifactory/ext-releases-local</url>
          <layout>default</layout>
        </repository>
      </repositories>
      <pluginRepositories>
        <pluginRepository>
          <snapshots>
            <enabled>true</enabled>
          </snapshots>
          <id>plugin-release</id>
          <name>Plugin Repository for release</name>
          <url>http://localhost:8081/artifactory/plugins-releases-local</url>
        </pluginRepository>
        <pluginRepository>
          <snapshots>
            <enabled>true</enabled>
          </snapshots>
          <id>plugin-snapshot</id>
          <name>Plugin Repository for snapshot</name>
          <url>http://localhost:8081/artifactory/plugins-snapshots-local</url>
        </pluginRepository>
      </pluginRepositories>
    </profile>

    <activeProfiles>
      <activeProfile>artifactory</activeProfile>
    </activeProfiles>

Script to install oracle sync plugin into the local & remote repository.

# setEnv.sh
export M2_HOME=/u01/apps/maven3.1.1
export MW_HOME=$HOME/Oracle/12c/Middleware/Oracle_Home
export JAVA_HOME=$(/usr/libexec/java_home -v 1.7)
export ARTIFACTORY_HOME=/u01/apps/artifactory-2.0.1
export PATH=$JAVA_HOME/bin:$M2_HOME/bin:$ARTIFACTORY_HOME/bin:$PATH

#install_oracle_maven_sync_plugin.sh

#Provisioning the environment variables
sh ./setEnv.sh

#Installing the oracle maven sync plugin to the local repository
mvn -X install:install-file -DpomFile=$MW_HOME/oracle_common/plugins/maven/com/oracle/maven/oracle-maven-sync/12.1.3/oracle-maven-sync-12.1.3.pom 
-Dfile=$MW_HOME/oracle_common/plugins/maven/com/oracle/maven/oracle-maven-sync/12.1.3/oracle-maven-sync-12.1.3.jar -DoracleHome=$MW_HOME

#Pushing all the libraries into the local repository
mvn -X com.oracle.maven:oracle-maven-sync:push -DoracleHome=$MW_HOME -Doracle-maven-sync.testingOnly=false

#Rebuilding the archetype catalog
mvn archetype:crawl -Dcatalog=$HOME/.m2/archetype-catalog.xml

#Deploying all the libraries into a remote repository
mvn -X deploy:deploy-file -DpomFile=$MW_HOME/oracle_common/plugins/maven/com/oracle/maven/oracle-maven-sync/12.1.3/oracle-maven-sync-12.1.3.pom 
-Dfile=$MW_HOME/oracle_common/plugins/maven/com/oracle/maven/oracle-maven-sync/12.1.3/oracle-maven-sync-12.1.3.jar -Durl=http://localhost:8081/artifactory/plugins-releases-local 
-DrepositoryId=plugin-release

#Pushing all the libraries into the remote library release repository
mvn -X com.oracle.maven:oracle-maven-sync:push -DoracleHome=$MW_HOME -Doracle-maven-sync.serverId=lib-release

The terminal output shows that the plugin was successfully deployed to the remote repository.














Artifactory console showing the successful upload of plugins/libraries.

With all the technology specific plug-ins now loaded, lets describe them one by one:

Service Bus Plug-in

mvn help:describe -DgroupId=com.oracle.servicebus.plugin
-DartifactId=oracle-servicebus-plugin -Dversion=12.1.3-0-0

SOA Suite Plug-in

mvn help:describe -DgroupId=com.oracle.soa.plugin -DartifactId=oracle-soa-plugin -Dversion=12.1.3-0-0

Oracle Coherence Plug-in

mvn help:describe -DgroupId=com.oracle.coherence -DartifactId=maven-gar-plugin -Dversion=12.1.3-0-0

Oracle Weblogic Plug-in

 mvn help:describe -DgroupId=com.oracle.weblogic -DartifactId=weblogic-maven-plugin -Dversion=12.1.3-0-0

Generating Service Bus project from Maven Architype

Now that we have deployed the oracle sync plugin and reloaded the maven archetypes, we can create service bus,soa,coherence projects using them. The below example shows how to generate a service bus application using the built-in archetype

In the New Gallery Select -> Maven -> Generate from Archetype

Click on the Maven Architype LOV to select the servicebus archetype

Search by text 'servicebus' and select the appropriate archetype populated from the local repository.

The Service Bus application has been successfully created using the archetype.

There are two different kinds of project archetypes available for a service bus application. They are :

<groupId>com.oracle.servicebus.archetype</groupId>
<artifactId>oracle-servicebus-project</artifactId>
<version>12.1.3-0-0</version>
<name>Oracle Service Bus - Project Archetype</name>

<groupId>com.oracle.servicebus.archetype</groupId>
<artifactId>oracle-servicebus-system</artifactId>
<version>12.1.3-0-0</version>
<name>Oracle Service Bus - System Resources Archetype</name>

The first one is for the actual service bus project and the second is for the System resources (we will see more about this in coming blog posts). The system resources are a way of sharing resources like JNDI, SMTP & Proxy servers across different service bus projects.

Lets build & package the application..

Build output...

References -
http://docs.oracle.com/middleware/1212/core/MAVEN/introduction.htm#MAVEN8755
http://docs.oracle.com/middleware/1213/osb/develop/osb-maven.htm