Architecture to ‘probe’ components of an end-to-end application

By: Robert van Mölken and Tim Askamp

An end-to-end application usually consists of multiple components that are one-way or another decoupled. A component can be an ADF frontend, OSB proxy, SOA Suite Composite, Database package or JAXWS web service. For maintaining all the components of an end-to-end application the components need to be checked individually to know if everything is in working order. So if there is for example a performance issue with the application there is no simple task to checked which component in the chain is responsible for this.

For one of our clients we’ve developed a ‘Probe’ application. The reason was that maintenance needed a simple way to determine if the SOA and Database environment: was running, configured as required and the basics where functioning. So basically we needed to mimic service operations that use the following components: OSB, SOA Suite, JAX-WS and ADF Business Components. Executing this functionality should lead to a traceable path of the used components. In this blog we will explain the solution we developed.

The architecture

The figure below describes the architectural diagram of the solution:

Architecture diagram of probe application

Each component uses a web service / SOAP binding. All components use the same service definition (WSDL). The service definition describes three operations; ping, deepPing and checkProcess (a.k.a. process).

As you can see In the diagram all components are coupled together in a chain by calling the same operation of the next component within that chain. For this specific implementation there are six components involved in the chain; two OSB proxies, a SOA composite, a Database adapter, a JAX-WS web service and an ADF Business component.

The ping operation

This operation is the simplest of the three operations, each component individually implements this. The only functionality it contains is an echo back with or without the DateTime from the request, depends if value is given, and the servers current DateTime.

Request:

<PingRequest xmlns="nl.amis.messages/probeservice/v1">
  <!--Optional:-->
  <DateTimeRequest>2013-07-08T11:59:53.415+02:00</DateTimeRequest>
</PingRequest>

Response:

<PingResponse xmlns="nl.amis.messages/probeservice/v1">
  <DateTimeRequest>2013-07-08T11:59:53.415+02:00</DateTimeRequest>
  <DateTimeResponse>2013-07-08T11:59:53.756+02:00</DateTimeResponse>
</PingResponse>

The deepPing operation

This operation calls all subsequent components to inventory the route that the request travels and to report that route. There is a parameter in the request that determines how many components/levels deep that requests needs to call. For example if you give this parameter the value “1” and call the deepPing operation on the OSB service endpoint, the proxy will call the SOA Suite service which will reply back to the OSB service without calling any deeper services. The result is always a stack trace of the called components. If an error arises in any of the components an error message is added to the component in the stack trace, no error means the component is responding correctly.

Request:

<DeepPingRequest xmlns="nl.amis.messages/probeservice/v1">
  <!--Optional:-->
  <DateTimeRequest>2013-07-08T11:59:53.415+02:00</DateTimeRequest>
  <AmountOfLevels>2</AmountOfLevels>
</DeepPingRequest>

Response:

<DeepPingResponse xmlns="nl.amis.messages/probeservice/v1">
  <DateTimeRequest>2013-07-08T12:45:00.988+02:00</DatumTijdVerzoek>
  <DateTimeResponse>2013-07-08T12:45:01.813+02:00</DateTimeResponse>
  <Route>
    <Component>
      <Name>ProbeService</Name>
      <DateTimeResponse>2013-07-08T12:45:01.813+02:00</DateTimeResponse>
      <Route>
        <Component>
          <Name>ProbeServiceSOASuite</Name>
          <DateTimeResponse>2013-07-08T12:45:01.730+02:00</DateTimeResponse>
          <Route>
            <Component>
              <Name>ProbeServiceOSBProxy</Name>
              <DateTimeResponse>2013-07-08T12:45:01.580+02:00</DateTimeResponse>
            </Component>
            <Component>
              <Name>ProbeServiceDBAdapter</Name>
              <DateTimeResponse>2013-07-08T12:45:01.000+02:00</DateTimeResponse>
            </Component>
          </Route>
        </Component>
      </Route>
    </Component>
  </Route>
</DeepPingResponse>

Response with fault:

<DeepPingResponse xmlns="nl.amis.messages/probeservice/v1">
  <DateTimeRequest>2013-07-08T13:08:56.772+02:00</DatumTijdVerzoek>
  <DateTimeResponse>2013-07-08T13:08:58.983+02:00</DateTimeResponse>
  <Route>
    <Component>
      <Name>ProbeService</Name>
      <DateTimeResponse>2013-07-08T13:08:58.983+02:00</DateTimeResponse>
      <Route>
        <Component>
          <Name>ProbeServiceSOASuite</Name>
          <DateTimeResponse>2013-07-08T13:08:58.899+02:00</DateTimeResponse>
          <Route>
            <Component>
              <Name>ProbeServiceOSBProxy</Name>
              <DateTimeResponse>2013-07-08T13:08:56.832+02:00</DateTimeResponse>
            </Component>
            <Component>
              <Name>ProbeServiceDBAdapter</Name>
              <DateTimeResponse>2013-07-08T13:08:58.898+02:00</DateTimeResponse>
              <ErrorOccured>
                The configured database is not responding, check the status of the database. 
                Exception Description: Cannot acquire data source [jdbc/ProbeDataSource].
                Internal Exception: javax.naming.NameNotFoundException: Unable to resolve 
                'jdbc.ProbeDataSource'. Resolved 'jdbc'; remaining name 'ProbeDataSource'
              </ErrorOccured>
            </Component>
          </Route>
        </Component>
      </Route>
    </Component>
  </Route>
</DeepPingResponse>

The checkProcess operation

This operation is similar to the deepPing operation, only this operation call all subsequent components and it checks if a component is also working at a functional level. This operation processes the given request values and concatenates all the values to a single string. Each component also adds a unique value/identifier to the output string on the way back (response). Looking at the final response value an administrator should determine if all components processed the input values of that an component raised an error. It is also easy to recognize that the service calls are not cached.

Request:

<CheckProcessRequest xmlns="nl.amis.messages/probeservice/v1">
  <ProcessString>SoapUI</ProcessString>
  <ProcessNumber>23</ProcessNumber>
  <ProcessDate>2013-07-01</ProcessDate>
</CheckProcessRequest>

Response:

<CheckProcessResponse xmlns="nl.amis.messages/probeservice/v1">
  <ProcessedResponse>
    ProbeService: String=SoapUI, Number=23, Date=2013-07-01 
    => ProbeServiceSOASuite: String=SoapUI, Number=23, Date=2013-07-01 
    => ProbeServiceDBAdapter: DB SysDate=2013-07-08 13:56:49, String=SoapUI, Number=23, Date=2013-07-01 
    => ProbeServiceOSBProxy: String=SoapUI, Number=23, Date=2013-07-01 
    => ProbeServiceJAXWS: DB SysDate=2013-07-08 13:56:48, String=SoapUI, Number=23, Date=2013-07-01
  </ProcessedResponse>
</CheckProcessResponse>

Response with fault:

<CheckProcessResponse xmlns="nl.amis.messages/probeservice/v1">
  <ProcessedResponse>
    ProbeService: String=SoapUI, Number=23, Date=2013-07-01 
    => ProbeServiceSOASuite: String=SoapUI, Number=23, Date=2013-07-01 
    => ProbeServiceDBAdapter: DB SysDate=2013-07-08 13:56:49, String=SoapUI, Number=23, Date=2013-07-01 
    => ProbeServiceOSBProxy: HTTP/1.1 404 Not Found 
    => ProbeServiceJAXWS: DB SysDate=2013-07-08 13:56:48, String=SoapUI, Number=23, Date=2013-07-01
  </ProcessedResponse>
</CheckProcessResponse>

Sample Implementation

Tim and I created a implementation for the client, but we want to share it with you, so I created a generic reference implementation. The implementation consists of two OSB proxy services (80% identical), one SOA Composite application and one JAXWS web service with an ADF-BC to connect to a database. This blog will not write about the internals of the reference implementation, but one of the download links below will provide a basic installation. Besides the sources the download links also include deployable archives.

– Probe Application Sources
– Probe Application Deployables
– Probe Installation Manual NL
– Probe Installation Manual EN

Test Implementation

For testing purposes I also created an SoapUI project with a testsuite and some testcase per operation, including properties, groovy scripting and xpath matches. The endpoints that are used right now are using the precompiled VM from Oracle and its hostname i.g. soabpm-vm. Just at the hostname to your hostfile and point it to the right IP address of your running VM.

– Zipped ProbeService SoapUI project