Building ESB Capability Java EE -vs- Configuring a Datapower SOA Appliance

Implementing a Java network infrastructure solution versus network appliance configuration

It’s not unusual for a seasoned Java implementer, when exposed to an IBM Datapower appliance for the first time to question the technological advantage of a configurable network device. I feel this question is best examined from an application architecture perspective.

Fundamentally, every implementation is the realization of a prescribed software architecture pattern and approach. From this viewpoint I’ll use a lightweight architectural tradeoff analysis technique to analyze the suitability of a particular implementation from the perspective of two technology stacks. The Java Spring framework combined with Spring Integration extensions and the IBM DataPower SOA appliance.

In this tradeoff analysis I will show the advantage of rapidly building and extending a bus capability using a configurable platform technology, versus Spring application framework components and the inversion of control container.

High-Level Requirements

The generic Use Case scenario: receive an XML message over a http, transform the XML input message  into SOAP/XML format, and deliver the payload to a client over an MQ channel.

Proposed Solution Architecture

Using an EIP pattern to provide a conceptual architecture and context lets consider the following ESB type capability. This solution calls for a message gateway, message format translator, and a channel adapter.

Assumptions

1. The initial release will not address the supplemental requirements, such as logging, persistent message delivery and error back-out.
2. This next release will be extended to include a data access feature, as well as the supplemental requirements.
3. Message end-points, message formats, queue configurations, database access and stored procedure definitions have all been fully documented for this development life-cycle sprint.

Architectural Definition

• To receive messages over HTTP you need to use an HTTP Inbound Channel Adapter or Gateway.
• The Channel Adapter component is an endpoint that connects a Message Channel to some other system or transport.
  • Channel Adapters may be either inbound or outbound.
• The Message Transformer is responsible for converting a message’s content or structure and returning or forwarding the modified message.
• IBM MQ 7.x has been supplied as part of the messaging infrastructure capability.

Technology Stack Requirements

Spring / Java SE Technical Reference – Standards Information Base

• Spring 4.0.x
• Java SE 6 or 7
• Spring Extension: Spring Integration Framework 4.1.x
• Spring Extension: XML support for Spring Integration
• Apache tomcat 7.x.x
• Spring run-time execution environment (IoC container)
• Eclipse for Spring IDE  Indigo 3.7 / Maven

DataPower XI/XG Appliance Technical Reference – Standards Information Base

• Configurable Multi-protocol gateway (XG45 7198 or or XI52 – 7199)
• XSLT editor- XMLSpy (Optional)
• Eclipse for Spring IDE  Indigo 3.7 (Optional)

Architecture Tradeoff – Analysis Criteria  

For the application architectural analysis I will use following architecture “illities”

• Development velocity
  • In terms of code base, development task, unit testing.

Development Velocity Analysis – Design and Implementation Estimates

Assumptions

1. Development environments, Unit Test cases / tools, have been factored into the estimates.
2. Run-time environments must be fully provisioned
3. Estimates based on 6.5 hour work day
4. 2 development resources for the implementation (1 Development Lead and 1 Developer)

Java SE using Spring Framework and Spring Integration Extensions.

DataPower SOA appliance with standard configuration components.

Architecture – Architectural Tradeoff Analysis

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

In terms of development velocity a DataPower implementation requires approximately 70% less effort. This is primarily due to DataPowers’ Service Component Architecture design and the forms based WebGUI tool that is used to enable configuration features and input required parameters for the service components.

The Java development velocity may be improved by adding development resources to Java implementation, however this will increase development cost and complexity to the overall project. Efforts around XML transformations are for the most part equal, the Spring framework and DataPower will use XSLT templates to implement this functionality.

Use Case Description for next release

In the next development iteration, our new Use Case calls for additional data from a legacy business application. Additionally, a supplemental requirement for persistent messaging with MQ Backout for undelivered messages on the channel.

Extended Solution Architecture

Development Extension Analysis – Design and Implementation Estimates

Assumptions

1. Message end-points, message formats, queue configurations, database access and stored procedures have all been defined documented for the development life-cycle.

Architectural Definition

• Must access a stored procedure from legacy relational database.
• Must support Message Channel to which errors can be sent for processing.

Java SE using Spring Framework and Spring Integration Extensions

DataPower SOA appliance with standard configuration components

Architecture Tradeoff – Analysis Criteria  

For the application architectural analysis I will use following architecture “illities”

• Extensibility
  • Adding persistent messaging on the channel with back-out functionality.
  • Adding data access and stored procedure execution from legacy database.

Architecture – Architectural Tradeoff Analysis

In terms of development extensibility the DataPower implementation requires approximately 50% less effort. This is primarily because, extending DataPower for these new requirements will not require additional programming for the data access functionality.

Again for this additional functionality the processing of the SQL stored procedure Dataset will require a programming effort for both implementations. The primary difference for Spring is the addition of 3 new components versus the configuration of a database access component on the DataPower appliance.

In terms of adding persistent messaging with back-out functionally. DataPowers’ built-in queue management service requires the implementer to enter the defined queue parameters. This is a net zero programming capability.

Conclusion

Undoubtedly the Spring framework along with Spring integration and the inversion of control (IoC) container, provides the Java developer with powerful application framework with functions that are essential in messaging or event-driven architectures.

However, the DataPower appliance offers this functionality as a purpose built non-disruptive network device out-of-the-box. In short DataPower is the concrete implementation of much of what Spring and the Integration Framework offers programmatically.

As cross-cutting concerns and non-functional requirements around security and webservice integration emerge the configuration capability of the appliance will become even more apparent.