Testing-Concepts and Considerations in a SOA landscape that uses the Oracle Service Bus Framework


Due to the ever growing complexity and multiple dependencies of software components in an enterprise landscape, “Automated Testing” is no longer an optional feature of the software development process but a crucial ingredient of the development process and plays a significant role in every successfully launched software project.

Software Development in a SOA environment has its own challenges that differ from, let’s say, purely Java components. One reason is the fact that software testing needs invariant laboratory conditions; but exactly this is hard to achieve in a complex service landscape. So when designing tests it is very important to determine isolation conditions to meet these requirements. Another point worth keeping in mind is the fact that frameworks -like Oracle Fusion Middleware- follow a declarative development approach; this means that testing is possible only after the deployment and never before (because the services are de-facto built up during the deployment). Some artifacts can be tested before the deployment but we get to it later.

In this article focusing on Oracle Service Bus we outline a feasible testing strategy that allows us to implement automated testing of arbitrary complexity; starting from simple service-testing up to end-to-end tests that involve a whole service chain spread over one or more domains.

Test Categories

We assume that the reader is familiar with service classification concepts like “elementary services” or “composite services”. We also assume that the basic concepts of OSB like XQueries, Proxy and business services are well known concepts as well.

Let us focus for the moment on transformation logic. The tools offered by OSB are XQueries and XSLT transformations. These files describe, roughly speaking, how a certain XML structure should be transformed to another one, or how a piece of information can be extracted from it. Hence they can be regarded as functions that receive an XML structure as input and provide another XML structure or simple data as an output. These artifacts can be tested by java Junit means before deployment. One might consider of it as an unnecessary testing step; but it is enormous important, because it guarantees us  that no side effects would remain undetected in case e.g. a namespace or a structural modification in a XML schema has to  be carried out.

So keeping these points in mind, one can make the following distinction:

Pre-deployment Tests

These are tests mainly using Junit techniques and may be considered as “low-level” or basic tests. They should guarantee that basic transformation logic of data structures meets the requirements. Testing the XQuery components help us ensure the XQuery language correctness as well and help us avoid namespace inconsistency and confusion.

Post-deployment Tests

These tests can be performed after the deployment of the OSB artifacts has been accomplished and can be distinguished in two main categories.

  1. Tests that affect a single service. They usually consist of a single call to a service provided by the OSB server and the analysis of the response.
  2. End-to-end Tests; these are much more complex and require mock-services in order to simulate a whole service landscape and perform Lab conditions.


Figure 1 Testing Pyramid

Let us focus now in the testing processes themselves.

Simple Service Tests

These tests guarantee that a given a certain input the service responses in the expected way.


Figure 2 Simple Service Tests

Complex End-To-End Tests

These tests define in general a dedicated entry point and a dedicated exit point where the assertions have to be performed. Everything in the middle can be considered as a “black box”.

Further on, in order to guarantee the so called laboratory conditions i.e. avoid side effects the assertion point such as one or more services in the middle has to be replaced by mock services.


Figure 3 Complex End-To-End Tests

Implementation schema

In the following we briefly outline the main implementation schema.

The Java test-process can be separated in the following steps:

  1. Via JMX the java Test application connects to the OSB server and manipulates the end point of a certain business server.
  2. The client-side establishes a Java mock-service having all the required characteristics of the OSB-service that has to be mocked.
  3. The test is initiated i.e. the test-request is send
  4. The service established by Step2 is waiting for a request from the OSB service that has been replaced by a mockup in Step1.
  5. All the designed assertions are made
  6. All changes made in OSB Artifacts are rollbacked.


Figure 4 End-To-End Tests

The whole testing process can be automatized using a deployment server e.g. Jenkins. In order to enable the system to perform the tests both deployment server and weblogic-managed-servers (OSB Server or cluster) has to be accessible to each other.



The testing framework might need quite a lot of implementation efforts in order to cover the entire requirement that arise from a complex SOA environment. However we emphasize that all the implementation efforts will be well rewarded in terms of quality and stability.

2 thoughts on “Testing-Concepts and Considerations in a SOA landscape that uses the Oracle Service Bus Framework”

Kommentar verfassen


%d Bloggern gefällt das: