Thursday, 3 May 2012

Spring and C24 iO - Part 1 C24 Spring Core


During very early stages of data processing software flows, it’s often necessary to take some type of raw data and parse it into a specific application software language construct in order that the application can progress that raw data through the business towards a conclusion. With XML being used extensively throughout software applications, and Java a very popular programming language, a good example of this would be a process that results in XML being available as Java objects. This process is often known as binding but is sometimes referred to as transformation. In an attempt to maintain common ground and maintain clarity, the process shall be referred to throughout these articles as a binding-transform.

The XML/Java binding-transform is an interesting example, popular technologies for performing such actions are JAXB & Castor; amongst a large cast of others. However, the specific value that C24 iO adds in this regard is that it’s not tied to any specific input data type such as XML - in fact iO models are strictly decoupled from input and output data types in order that you can freely choose or interchange between them when appropriate. 


C24 iO models represent business objects. As a developer you can choose a number of input data types to use to populate those objects with business data, CSV, XML, SWIFT, JSON, FpML, Columnar etc. The same is also true for output, you can choose a data format for those business objects when you’re ready to perform a reverse of the bind-transform should you need to dispatch data downstream in a specific format. The facility to do this binding-transform, and the reverse, is provided by C24 iO, out-of-the-box - no additional development is necessary.

In order to build a C24 iO model an understanding of your business object is necessary. The iO model can be built automatically from a sample message in many formats or from an external model such as an XSD. Alternatively, if you wish to maintain your business model using C24 iO, you can use iO Studio to build it from scratch. Model building terminology should seem familiar and intuitive, due mainly to the language that’s used for constituent parts, most people understand elements, attributes, simple and complex types or will quickly learn the difference when using this graphical tool.

The one remaining piece of the puzzle is the mechanism that allows these models to be used in application software at runtime. Once models have been created and tested in iO Studio, a triggering of code generation produces a Jar file that contains everything necessary to read data into the business model (from various source data types), interact with it through intuitively named methods and write it out again (into various target data formats). 

Each business object generated from an iO model is automatically part of a type hierarchy known as a Complex Data Object (CDO). Any standard or custom model that you use or build within C24 iO Studio will generate code that will implement the CDO type.

The c24-spring-core namespace provides capability to use CDOs as Spring beans either within applications using the Spring framework or as Spring beans within applications using the Spring Integration framework.

The namespace is http://schema.c24.biz/spring-core, the XSD is located at http://schema.c24.biz/spring-core.xsdUsing the c24-spring-core namespace within your Spring application means defining an interest in that namespace and location using something like the following configuration:

xmlns:c24="http://schema.c24.biz/spring-core"
xsi:schemaLocation="http://schema.c24.biz/spring-core 
http://schema.c24.biz/spring-core.xsd"


Once the namespace configurations have been completed, a namespace construct can be used to generate a C24 iO bean and use it within a Spring application. Those readers familiar with SWIFT FIN messages will recognise this example as a message model representing a securities trade message, an MT541.

<c24:model id="mt541Model" base-element="biz.c24.io.swift2011.MT541Element"/>


Once the Spring container is loaded with this bean, the developer is at liberty to interact with this business object in the same way that you would when using it outside of the Spring container. The benefit gained here is that it now has a lifecycle controlled by the Spring container and can be used by other beans within the same context, this will be explored further in the next part of the series.


The motivation for Part 1 of this series was an introduction to C24 iO, a brief explanation of some of it's basic capability and an introduction to iO models used as Spring beans.

Spring and C24 iO - Accelerating Enterprise Data Services Deployment


The focus for this series of blog articles is to explore the coupling between SpringSource's Spring Integration framework and C24s Integration Objects (iO) product. The primary driver for this showcase of two technologies is to demonstrate a significant potential time-to-market advantage for building, delivering and deploying Enterprise Data Services solutions.

SpringSource's Spring Integration is a framework and extension of the de facto standard EIP patterns described by Gregor Hohpe & Bobby Woolf [Enterprise Integration Patterns, ISBN 0321200683, Addison-Wesley, 2004]. Spring Integration also provides a veneer (via XML namespacesor Java code) over common Spring Core APIs and significantly, a messaging capability within and between applications.

C24 Integration Objects (iO) is a high-performance integration tool that, through model construction, supports Java binding capability and through transformation construction, supports transformations between models. C24 is a strategic SpringSource partner and well recognised in the finance industry as a leading integration tool provider - due primarily to the vast array of financial messaging models supported, low latency processing and the graphical modelling capability of C24 iO Studio. Furthermore, C24 iO models can be constructed as semantically rich components in order to employ strict validation against customisable rules that go far beyond capabilities of technologies such as the XML Schema Definition (XSD) language constraint model.

Together with C24, SpringSource have built two custom namespaces for C24's iO product that together, provide capability for a closely-coupled integration between Spring, Spring Integration and iO. The first namespace, c24-spring-core provides a facility to use C24 iO models directly within any Spring or Spring Integration application. The second namespace, c24-spring-integration, provides a facility to use C24 iO models within Spring Integration flows. This brings a time-to-market advantage for clients who wish to take advantage of C24 iO and a robust integration framework - in many cases, very little custom Java code is necessary to get operational flows deployed.

The focus of the following series of articles is to present key aspects of Spring Integration and C24 iO as high-performance, key, integration technologies. Additionally, and most significantly, an exploration will be undertaken of capabilities of the two technologies (Spring & iO) coupled together in order to deliver a client integration solution that forms the basis of a financial application installation.

A single sample project is used through the series, mainly to demonstrate code and configuration around a single business theme. This sample project is based on an operational flow built to process SWIFT FIN messages, all of the source code and configuration will be made available in the set of references that will appear as the last article in the series. 

Part 1 in the series provides some background information regarding C24 iO as a tool, it's core capabilities and relationship with the Spring container.

Part 2 details the capabilities that have been provided by C24 iO for building integration flows and, through example, explores the use of C24 iO within those flows.

Part 3 demonstrates a typical Spring Integration based solution that uses C24 iO to provide binding-transform and transformation capability. Because this flow is not contrived, it demonstrates many of the issues that have to be tackled during design and implementation of integration projects that use the Spring Integration framework.

Part 4 is all about testing integration flows. After having used Mockito on several large projects to test Spring Integration flows, an interesting testing strategy is presented.

Part 5 is a short post and is really a container for all of the reference material used and a guide to the sample project available from Github.