Deploying OSB projects from DevCS to SOACS

This blog is a companion to David Craft’s excellent series on using DevCS with SOACS to deploy SOA composites to a SOACS instance.


There are several challenges in deploying OSB from DevCS to SOACS.

  • Typically a self-signed certificate environment. Unless otherwise configured, SOACS defaults to a generated self-signed certificate. Because non-SSL communication is usually locked down in Oracle’s cloud offerings, this presents a challenge when trying to talk to cloud instances.
  • Attacks against SSL cause hardening which is incompatible with the default SSL client stack. You should disable the SSLv2Hello handshake, but doing so can cause problems with the SSL stack of clients trying to connect to the server.
  • The SOACS configuration may not be quite correct for t3s connections via the NAT layer in front of the SOACS virtual machine. This will require a configuration change to resolve it.


You should have a maven deploy task already configured which can deploy your OSB project from the command line to a local instance. Here is an example pom.xml which will be able to build and deploy OSB. It needs the common “” pom.xml in a parent directory.

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="" xmlns="" xmlns:xsi="">

      <name>Remote DevCS Maven repository for Demo</name>
      <url><!-- fill in --></url>
      <name>Remote DevCS Maven repository for Demo</name>
      <url><!-- fill in --></url>


You will need to create a java keystore holding the self-signed certificate of the SOACS server as a trusted certificate. This should be made available either in the repository containing the OSB code to deploy, or as an artifact in DevCS for download by a task prior to the maven task.

Server URLs and configuration

SOACS runs in a virtualized environment and uses NAT based networking to connect a public IP address (visible from the internet) to the private IP address (what you’ll see on the actual SOACS instance). The weblogic server is typically only aware of the private IP address, in the 10.x.x.x range, and the DNS name of this private IP (of the form -wls-<n>.compute-<identitydomain>.oraclecloud.internal). You need to configure the external address of the WebLogic server to the public DNS name of the server. This will be of the form oc-<hyphen-separated-ip-address> Note that this is not the listen address entry – there is a separate entry for the external address under the advanced section.

This will also constitute the URL you will use for accessing the service for deployment: https://oc-<hyphen-separated-ip-address>

Maven bug

There is a bug in the OSB maven plugin which means that it won’t be able to use SSL by default. The bug #20550440 should contain a fix. Apply it to a convenient copy of the maven artifacts, and redeploy the maven artifacts to DevCS after patching to fix it.

Note: this bug may be fixed for your specific version of the environment.

DevCS job setup


The deploy task typically needs several parameters:

  • oracleHome : this is the Oracle Home on the DevCS server. Typically this is available as the environment parameter ORACLE_HOME.
  • oracleServerUrl : this is the URL of the server we’re trying to deploy to. This should be an HTTPS URL. It should use the external hostname of the SOACS instance you’re trying to connect to.
  • oracleUsername : a valid username on the weblogic instance we’re trying to deploy to, with permission to deploy. (Typically, the weblogic identity would work here)
  • oraclePassword : the password of the user identity above.

These credentials should be supplied as parameters to the DevCS build task, as they will then become properties for the maven environment. By parameterizing these, the same job could arguably be used to deploy to different environments.

Maven Job

The maven execution job will need some customization.

Additional parameters:

  • This is the keystore from above. We’re telling the weblogic SSL layer about it as an additional trust store.
  • This is the password for the trust store above. It defaults to changeit.
  • -DuseSSL=true This is a flag to force the OSB maven task to use SSL. This is the bug fix from the bug discussion above.
  • -Dhttps.protocols=TLSv1.2 We want to use TLSv1.2 for SSL communication
  • -Djdk.tls.client.protocols=TLSv1.2 Yup, we definitely want to use TLSv1.2
  • Yup, we definitely want to use TLSv1.2
  • How many ways do we have to say we want TLSv1.2? This many ways.
  • We don’t want those pesky SSLv2Hello messages, please (modern servers should reject anything where one of these is present, rightly so)
  • Don’t validate hostnames. Yes, this is arguably a man in the middle risk, but the names don’t always align due to configuration. It shouldn’t be necessary in a perfect configuration.

Putting it together

If you have put everything together correctly, then you should be able to execute a deployment from DevCS to OSB on the cloud.

Inspecting the console log in DevCS, you should see something similar to the following:

clean pre-integration-test -DuseSSL=true -Dhttps.protocols=TLSv1.2 -Djdk.tls.client.protocols=TLSv1.2

Add Your Comment