Maven

Testing Oracle Service Bus components


Testing Approach with OSB

I have been having a thought about what’s the best way forward with automating unit tests with OSB

First of all there are 2 things here…

One is Unit testing and the Second bit is automating them…

UNIT TESTING with OSB

A customer of mine was very keen on unit testing and automation and this is what I explained to them. There isn’t that much of an issue in adding unit tests to all services just that it means we do some additional work mocking services.
For SOAP Services it’s simply a case of writing SOAPUI web services test cases.
However since most of the integrations at the customer weren’t synchronous SOAP Services we will have to write test cases for JMS messages. Again this can be done via SOAPUI or we can also use something like citrus.
Citrus is an integration testing framework written in Java that tests your software application to fit into your customer’s environment. The tool simulates surrounding systems across various transports (e.g. Http, JMS, TCP/IP, SOAP …) in order to perform automatic end-to-end use case testing.

For JMS based Messaging services again we can have SOAPUI test cases as we did for the earlier phases of the project.

Also see http://www.soapui.org/JMS/working-with-jms-messages.html

However the bit where we might struggle or may be have to tweak things a bit is when it comes to proxy chaining which isn’t SOAP or JMS… eg. Local protocol provided by OSB  i.e. proxies that can’t be executed from the outside world…

SO for these we have the following options
1.       Do nothing i.e. don’t unit test them just test with other services… which may not be that bad as they are like internal services.
2.       Change the protocol in Dev environments allowing them to be tested individually however that might also come with other complications like there is a difference in how transactions work in local proxies etc… also the headers are different in SOAP over HTTP from JMS and the same for local.. so further analysis really needs to go into this but most likely we will have to break these down on a case by case basis and would end up with 3-4 different scenarios based on the blueprints.

3.       Also looking at some blogs people are talking about adding SOAP based wrappers for such services. Which we can consider, just that I am not a big fan of adding code that isn’t really part of your project but with careful governance we can take this approach…

 Another aspect you want to consider is how we test transformations

Xquery Transformations:

Eclipse lets you unit test them from the IDE and can also be tested from the OSB console.

Eclipse Xquery

 

xquery test

 

I haven’t tested it using any tool before but can see people have written java code to automate this. http://osbutils.googlecode.com/svn/tags/XQTestFramework-v0.2/src/com/oracle/uk/ocs/osb/xqtest/XQAbstractTest.java might be worth testing it.

In addition another approach commonly used and documented by some fellow bloggers is that we can wrap Transformations and simple services without much overhead which allows them to be easily tested along with other services using SOAPUI for example.

So all in all we can have unit tests for OSB just that we need to identify all the scenarios i.e. soap calls, jms services, adapters, sync, XQuery transforms one way services etc… Also Queues and we should be able to unit test them…
There is a very useful post on Eric’s site regarding how to use Citrus framework which can plug with maven to provide automation of unit tests.
http://www.xenta.nl/blog/2010/04/12/eaioracle-service-bus-testing-with-citrus-framework-part2/
http://www.citrusframework.org/index.html

Part 2 AUTOMATING Unit Tests

If we want to initiate the entire unit tests and plug them with the Continuous integration

I think the biggest challenge is that normally unless you have a dedicated environment which only contains the mocks you would struggle to do that. In a normal integration environment we will need to first either automate creation of a session executing a Customization file which switches the endpoints to mocks and then executes the requests (all this is doable using maven and automation scripts – just not desirable)….. The good thing is with OSB you can undo a session so may be post execution the changes to endpoints in rolled back.
Preferred solution: would be to have a dedicated Unit test environment with all the mocks running on this environment, which can be used with CI. As soon a developer checks the code in the CI kicks in and checks the code out, performs the build, executes all the test cases and provide you the report about the test coverage. This can work with Bamboo as it has worked with Continuum and some other tools which I have tried in the past, I might be looking to hook this will Bamboo in the coming few days for one of our customers.
Test coverage Reports using SOAP UI

run-sample-testsuite

create-sample-report

a web service testing result report created with soapUI Pro

testsuite-coverage

Test Coverage using Citrus

Oracle Service Bus testing with Citrus

Other thing that just came to mind was maybe we can be using dynamic routing to switch between mock or real endpoints based on the input message but in that case the mock business services will have to live on the server as well…again you wont want these to progress through the environments so you will have to have a strong governance model around how to ignore certain files from deployments…. Or may be how to ignore all files sitting in the Unit test folder of the project….  Again more thought needs to go into each of these options…

References: http://eelzinga.wordpress.com/2010/04/12/eaioracle-service-bus-testing-with-citrus-framework-part2/
http://www.citrusframework.org/index.html
http://www.slideshare.net/gschmutz/best-practices-for-testing-soa-suite-11g-based-systems

Continuous Integration with OSB – http://redstack.wordpress.com/2013/05/02/building-osb-projects-with-maven-and-removing-the-eclipse-dependency/

http://soa-java.blogspot.co.uk/2011/12/continuous-integration-for-oracle-osb.html

These are the just the various options I have considered so far for the Testing Approach with OSB and how it plugs into CI… Further analysis may be needed for some of these to ensure they are the best possible solution for your organisation.

I would be interested to know what your views are on some of these?

Advertisements

Singleton Design Pattern


If we are talking about Design Patterns, One of the most common pattern that crosses your mind is Singleton Design Pattern.

The underlying definition of the same is “Ensure a class only has one instance, and provide a global point of access to it.”

Even though it is simple and most of you might already know this, but at times it gets confusing, And as there is No right or wrong approach to it, I will discuss a few of the most common approaches in this post.

Approach 1
In this approach we create a static final variable which will hold our unique instance.
Next we make sure that no can access the constructor to create a new instance, So we make the constructor private.
Now in order to allow access to this instance we create a public Static method which returns you the uniquely created instance of our class.

public class Nitin {

private static final Nitin singletonInstance = new Nitin(); // my unique instance

// Private constructor prevents instantiation from other classes
private Nitin() {
}

public static Nitin getInstance() {

return singletonInstance;
// returns you the same instance we created
}
}
}

Approach 2 – using a static block of code to instantiate.


private static Nitin singletonInstance = null; // instance has not been
// created yet.

// Private constructor prevents instantiation from other classes
private Nitin() {
}

static {
singletonInstance = new Nitin();
// ensures that the instance is only created when it is first needed.
}

}

Approach 3 – we can check in the getInstance method if the instance was created. It ensures that your instance is only created when it is needed.

public class Nitin {

private static Nitin singletonInstance = null; // instance not created yet

// Private constructor prevents instantiation from other classes
private Nitin() {
}

public static Nitin getInstance() {

if (singletonInstance == null) {
singletonInstance = new Nitin(); // my unique instance
}
return singletonInstance;
}
}

Well as we say that there is always a way out 🙂 If you want to break something then no one can stop you…

There is a crack to singleton implementation which I came across recently. Even though you should not try that on someone’s code but there is no harm if you just did for fun,

class CrackingSingleton {

public static void main(String[] args) throws IllegalArgumentException,
InstantiationException, IllegalAccessException,
InvocationTargetException, ClassNotFoundException {

Class clazz = Class.forName("Nitin"); // loads the class

Constructor[] cons = clazz.getDeclaredConstructors();
// gets the constructors

cons[0].setAccessible(true); // changes the access rights

Nitin noMoreSingleton = (Nitin) cons[0].newInstance();

// we have our new instance

}
}

[ad]

Installing Continuum


 

Apache Continuum is an enterprise-ready continuous integration server with features such as automated builds, release management, role-based security, and integration with popular build tools and source control management systems. Whether you have a centralized build team or want to put control of releases in the hands of developers, Continuum can help you improve quality and maintain a consistent build environment.

System Requirements

JDK

1.5 or above

Memory

No minimum requirement

Disk

The Continuum application package is less than 30MB but will use more disk space when it’s checking out and building sources

Operating System

No minimum requirement. Tested on Windows XP, Debian, Fedora Core, Solaris and Mac OS X

 

Installing Continuum Standalone

  • Download the standalone version from the Download page
  • Extract the file
  • Set a JAVA_HOME environment variable which use a jdk >= 1.5

Defining JNDI Resources

Mail server configuration

Before to start Continuum, you must configure your SMTP configuration for mail notification. The configuration to do is in $CONTINUUM_HOME/conf/jetty.xml:

<New id=”validation_mail” class=”org.mortbay.jetty.plus.naming.Resource”>

<Arg>mail/Session</Arg>

<Arg>

<New class=”org.mortbay.naming.factories.MailSessionReference”>

<Set name=”user”></Set>

<Set name=”password”></Set>

<Set name=”properties”>

<New class=”java.util.Properties”>

<Put name=”mail.smtp.host”>localhost</Put>

</New>

</Set>

</New>

</Arg>

</New>

Databases configuration

By default, Continuum use an embedded Derby database. If you want to use another database, you can modify the JNDI configuration in $CONTINUUM_HOME/conf/jetty.xml:

<!– continuum database –>

 

<New id=”continuum” class=”org.mortbay.jetty.plus.naming.Resource”>

<Arg>jdbc/continuum</Arg>

<Arg>

<New class=”org.apache.derby.jdbc.EmbeddedDataSource”>

<Set name=”DatabaseName”><SystemProperty name=”appserver.base” default=”..”/>/data/databases/continuum</Set>

<Set name=”user”>sa</Set>

<Set name=”createDatabase”>create</Set>

</New>

</Arg>

</New>

 

<New id=”continuumShutdown” class=”org.mortbay.jetty.plus.naming.Resource”>

<Arg>jdbc/continuumShutdown</Arg>

<Arg>

<New class=”org.apache.derby.jdbc.EmbeddedDataSource”>

<Set name=”DatabaseName”><SystemProperty name=”appserver.base” default=”..”/>/data/databases/continuum</Set>

<Set name=”user”>sa</Set>

<Set name=”shutdownDatabase”>shutdown</Set>

</New>

</Arg>

</New>

 

<!– Users / Security Database –>

 

<New id=”users” class=”org.mortbay.jetty.plus.naming.Resource”>

<Arg>jdbc/users</Arg>

<Arg>

<New class=”org.apache.derby.jdbc.EmbeddedDataSource”>

<Set name=”DatabaseName”><SystemProperty name=”appserver.base” default=”..”/>/data/databases/users</Set>

<Set name=”user”>sa</Set>

<Set name=”createDatabase”>create</Set>

</New>

</Arg>

</New>

 

<New id=”usersShutdown” class=”org.mortbay.jetty.plus.naming.Resource”>

<Arg>jdbc/usersShutdown</Arg>

<Arg>

<New class=”org.apache.derby.jdbc.EmbeddedDataSource”>

<Set name=”DatabaseName”><SystemProperty name=”appserver.base” default=”..”/>/data/databases/users</Set>

<Set name=”user”>sa</Set>

<Set name=”shutdownDatabase”>shutdown</Set>

</New>

</Arg>

</New>

 

Installing as a Windows Service

  • Go to $CONTINUUM_HOME/bin/ and run the following command:

    continuum.bat install

  • Edit the ‘Apache Continuum’ service
    • To see the services that are on your computer go to Start|Run and enter ‘services.msc’.
  • Select the ‘Startup Type’
  • Go to the ‘Log On’ tab and select a real user. A real user is required because you’ll need a home directory for maven repository and some other things
  • Validate your changes