Starting out with Oracle SOA CS – my first steps on a fairly advanced PaaS service

One of the platform offerings in the Oracle Public Cloud is the SOA Cloud Service. This service offers various flavors of SOA Suite 12c (Service Bus, SOA Suite, Technology Adapters) and API Manager 12c, automatically provisioned on the cloud. This service builds on top of a pre-existing DBaaS instance and Storage CS container and implicitly creates a JCS instance and several compute nodes on IaaS Compute CS – as shown in the figure to the right.

This article describes my first steps in getting started with SOA CS. In less than two hours, I had my first simple Service Bus project running on the SOA CS instance. From SoapUI on my local laptop, I could run a load test against the service exposed by the Service Bus, accessed via the automatically provisioned Load Balancer. The average response time was 60 ms, consisting to a large extent of the network latency from my laptop to Oracle’s data center.

Preparation

Before you can request provisioning of a SOA CS instance, you need to have gone through some preparations (also see documentation):

• you need a (trial) subscription to SOA CS
• you need a running DBaaS instance – a database instance that will host the SOA Infra schema, the MDS schema and other SOA Suite components (see this article about preparing such as DBaaS instance)
• you need a (trial) subscription to Storage Cloud Service and you need to prepare a storage container on this service – to host the back ups of the SOA CS instance
• you need to have prepared an SSH public/private key pair (which you also need to do for the DBaaS instance) and have access to the public key

Additionally, you need to decide what kind of environment you want to have provisioned: just SOA [SCA engine} or just Service Bus – or both? A single node environment or a multi-node cluster? Do you also [or only] need API Manager? The provision wizard will ask you for the answers to these questions.

The starting situation before running the provision wizard is shown here:

 

I have navigated to the Service Console for the SOA CS service in my identity domain. It would list all my instances – if I had any. Since I do not, all I can do is press the Create button to start a request to have an instance provisioned for me:

The first step is the selection of the Domain Type. The options are self explanatory.

The next step is the selection of the Software Image. Right now, only 12.1.3 is available. Somewhere in February or March I would expect 12.2.1 to be also listed.

The Details page is where it gets interesting. Here is where you need to provide important details such as:

• Instance Name and Compute Shape
• Public Key of the SSH key pair
• Definition for the administrator account for SOA CS & JCS (here called weblogic)
• Reference to the existing DBaaS instance that is to be used for creating the required database schema
• Configuration of the Load Balancer
• Reference to the storage container that has been prepared to hold backups from this SOA CS instance

See the next figure to get an impression:

Press Next to go to the Summary.

Then press Create to get things in motion. Once you press Create, the request is underway and the environment will be provisioned.

Now you can do nothing more – for this SOA CS instance – than sit back and wait.

And perhaps check on the progress from time to time:

Pretty soon, the Compute nodes are prepared and can be inspected:

And the provisioning continues:

and

Until finally: it is done.

 

Provisioning and Beyond

After running the provision wizard the instance will be prepared, forcing you to wait for a while. After about an hour and a half, the instance is provisioned, prepared and active. This next figure displays what has been created – and linked – during provisioning:

 

 

You will note the JCS instance – SOA1213ACED-jcs – that has been created automatically to host the SOA Suite. Three compute nodes are created on the Compute Cloud Service, one for the Load Balancer and two for the two managed servers on which Service Bus and SOA SCA engine (and the technology adapters) run. In addition to the storage containers already prepared for the DBaaS instance and the SOA CS backup, additional storage containers have been created automatically to support the compute nodes.

Multiple JDCB data sources have been created on the JCS instance – that refer to various database schemas in the PDB1 pluggable database in the DBaaS instance MyJCSDB. These schemas were generated and populated during the provisioning process. Using  SQL Developer and a connection to the SYS user on the PDB I can learn about these schemas:

 

I have not yet been able to figure out which default password was used during provisioning of SOA CS for these database schemas.

At this point, I can access various consoles directly for the newly created instance – such as Fusion Middleware Control, WebLogic Admin Console, SOA Composer and the Service Bus Console.

Through the latter, I can create service implementations directly on the cloud. Alternatively, I use JDeveloper to do local development of SOA composites and Service Bus projects and deploy those to the SOA CS instance.

The services on SOA CS can be scheduled for execution – using Enterprise Scheduling Services – and can be invoked within my identity domain – for example from Java applications running on my JCS instance -and from the public internet through the public IP address of the Load Balancer for the cluster. Inbound adapters – such as JMS and Database – can be triggered by events elsewhere in the identity domain (such as data manipulation in an DBaaS instance or JMS messages published in the JCS instance. The SOA CS instance can only access on premises systems if these are somehow exposed to the public internet. Shortly, Oracle is expected to make an Agent available to bridge the great divide between on premises systems and cloud based integration solutions that would allow interactions from cloud to on premises without opening up ports in firewalls.

A quick glance at the consoles:

Logging in to FMW Control – with the weblogic user specified in the provision wizard:

The opening page for the FMW Control:

The Service Bus Console:

And the WLS Admin Console (with the JDBC Data Sources to the SOA Infra and other database schemas in the DBaaS instance):

These consoles look the same as you are used to on premises. It is the same software after all – the only differences or points of interest are found in connection details and other configuration settings.

Deploying and Running the first Service Bus project to SOA CS

I wrote the Oracle SOA Suite 12c Handbook that was published in September 2015 by Oracle Press. This book describes not only SOA Suite and Service Bus but also the case of the imaginary airport Saibot (in Lexville). The sources for the book can be found on GitHub (soasuitehandbook). These are a good test case for me to see whether the SOA CS instance can be used.

I have taken almost the simplest example in the book: the ConversionService described in Chapter 3. This service exposes an interface through which various unit conversions are provided: temperature, distance, weight, speed – to bridge the gap between metric Europe and other continents on one side and the not so metric other parts of the world on the other. The temperature conversion is implemented locally in the pipeline; the distance conversion is delegated to an external web service (http://www.webservicex.net/length.asmx).

The project overview looks like this in JDeveloper:

I have exported the Service Bus project to a JAR file. At this point, the local environment is of no consequence. Note that I did not use a local SOA Suite instance.

Next, I go to the Service Bus Console on the SOA CS instance.

After logging in, I click on Create [a change session]:

Then, I click on the Import icon:

The import popup dialog appears. Select the JAR file (from the browser on the local end of the world) to which the SB project was exported:

Click Next to upload and inspect the JAR file:

Click Import if all seems okay – which it does.

The confirmation is shown of the import action.

Click Close to stop importing resources.

Next, click on Activate to well, activate the change sessions and publish the Proxy Service in this project:

Confirm the activation:

by clicking Activate.

Select the ConversionServicePS proxy service in the navigator tree. Then click on the play or invoke service icon:

The internal Service Bus Web Service Tester appears. Select the operation to invoke and fill in some meaningful request value:

Press the Execute button. At this point, the Proxy Service is invoked:

The response is shown with the converted temperature value.

This tester runs locally, within the Service Bus managed server. More interesting is a call from the outside, for example from SoapUI running locally on my laptop.

To make this call, I need to determine the endpoint for the WSDL. It can be found as follows:

the public IP address for the Load Balancer (from the Service Console for the SOA CS instance)

the default SSL port (443)

the endpoint for the proxy service as specified on the Transport tab in the Service Bus Console:

The endpoint to use in SoapUI is now: https://<public IP Load balancer>:443/utility/ConversionService?wsdl

or directly the WSDL in the local browser:

Making a call from SoapUI is now pretty straightforward:

And creating load tests for two operations – distance and temperature – is dead easy:

The quite substantial difference in average response times is caused by the fact that to convert the distance, the service on Service Bus makes a call out to an external web service, outside of the Oracle Public Cloud – as we can tell from the transport tab for the Business Service that is called from the pipeline in case of a distance conversion:

This shows that calling out from a service implementation to a service outside of the Oracle Public Cloud infrastructure – on the public internet – can be done just like that. As you would expect, but as is also nice to have confirmed.

Next Steps

Some obvious next steps to take from here:

Managing Users and Roles – allow other users to access the SOA CS – using their own user account within the identity domain and with limited privileges. See documentation.

Configure Technology Adapters to access local (within the identity domain) systems such as the DBaaS instance, Java applications and JMS destinations on JCS and perhaps ICS, DCS and others; see documentation

Set up an SSH tunnel from the on premises environment to the compute node running the SOA CS instance to allow connectivity between Oracle SOA Cloud Service adapters and on-premises applications (perhaps the ICS Agent can be used with SOA CS as well at some point); see documentation.

Make use of the Cloud Adapters. The cloud adapters are automatically included with Oracle SOA Suite Cloud Service.

Conclusion

SOA CS offers a very convenient way to very quickly get going with a shared, somewhat managed Oracle SOA Suite 12.1.3 environment, accessible to any number of users from virtually any location. For many training, development and testing situations, this can be of immediate benefit, especially considering the sometimes excruciatingly long processes in many organizations to request environments and have them provisioned. With the option to quickly get going (just a few hours, hardly any specialist platform administration knowledge required) on SOA CS, projects at least don’t have to come to a complete standstill because environments are not available.

Of course many SOA initiatives revolve around integrations with on premises systems; development work on SOA CS may require a number of mock representations of these systems to be created on the cloud:

• database schemas almost without  data but with the proper table structures, type definitions and PL/SQL program units
• Java and Service APIs that can be invoked but always return the same fixed response
• queues that can be published to (but that are not subscribed to by consuming systems)

Working with stubs and mock implementations during development is a good approach for many development activities on premises by the way – to reduce the complexity of dependencies and differences in planning between teams.

 

Resources