Skip to main content

Digital Experience

Building an ESB Capability

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

Solution 1

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.

Java EE Spring Framework
Architecture Component Design Component(s) Development Task Effort / Hr.
Message Gateway Http Inbound Gateway XML wiring http Inbound Adapter 6.5
Http Namespace Support XML wiring of Spring Component 6.5
Timeout Handling XML wiring of Spring Component 6.5
Http Server Apache / Jetty Build Web Server instance 12
Exception Handling Error Handling XML wiring of Spring Component 12
Message Transformer XsltPayloadTransformer XML wiring of Spring Component 13
Transformation Templates Build XML Transformation Template 12
Results Transformer XML wiring of Spring Component 13
Chanel Adaptor (Direct Channel) XML wiring Outbound Gateway 2.5
Build Attribute Reference File 12
Estimation hrs
96
Estimation of Duration (Days) 15

DataPower SOA appliance with standard configuration components.

DataPower Appliance
Architecture Component Design Component(s) Development Task Effort / Hr.
Message Gateway Multi-protocol Gateway Name and Configure MPG 3
XML Manager Name and Configure XML Manager
Message Transformer Multi-Step Transform Action Build XSLT Transformation Code 13
Chanel Adapter (Direct Channel) MQ Manager Object Name and Configure MQ Manager 2
Estimation 18
Estimation of Duration (Days) 3

Architecture – Architectural Tradeoff Analysis

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.

DataPower Services

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

Solution 2

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

Java EE Spring Framework
Architecture Component Design Component(s) Development Task Effort / Hr.
SQL Data Access JDBC Message Store XML wiring of Spring Component 6.5
Stored Procedure Inbound XML wiring of Spring Component 8
Configuration Attributes XML wiring of Spring Component 3
Stored Procedure parameters XML wiring of Spring Component 3
Process SQL Validation/Processing  of SQL DataSet 9
Estimation 28.5
Estimation of Duration (Days) 5

DataPower SOA appliance with standard configuration components

DataPower Appliance
Architecture Component Design Component(s) Development Task Effort / Hr.
SQL Data Access SQL Resource Manager Configure Db Resource 2
Process SQL XSLT Transformer – Database Build XSLT Transformation Code 10
Estimation 12
Estimation of Duration (Days) 2

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.