Introduction

This page lists the frequently asked questions and their answers.

Is IkasanEIP a kind of ESB?

Yes, although Ikasan originally started life back in 2001 as a closed application on a commercial integration platform when EAI (Enterprise Application Integration) was the more usual term. The architecture of Ikasan has been refined, but not really changed too much out of its original scope (although we are starting to build out more service based endpoints) of decoupled integration through discreet components to provide a highly robust (transactional in terms of guaranteed integrity rather than high volume) solutions.

We believe that Ikasan distinguishes itself through providing this high level of guarantee and automated recovery. In addition the intention of Ikasan is to provide commoditised solutions to integration requirements rather than another framework within which developers have to build again. Additionally, Ikasan is firmly focused and proven in Financial services so we are also focused on building out third-party trade connectors. We are really focusing on closing the gap between the commercial side of financial services and the Open Source community as we feel this has benefits for all.

Does Ikasan support request/response, publication & subscription messaging?

Yes. Ikasan can support all of these and the flows can be configured to support request/response both synchronously or asynchronously. One of our medium term goals is to provide synchronous wrappers around asynchronous solutions to allow client invocations to take advantage of either as their requirements dictate. Again with particular focus on guaranteed data integrity and recovery.

Does Ikasan use a neutral format for messages?

At present Ikasan uses JMS as the messaging backbone – we are looking to abstract this for other wire protocols in the future, so at present these JMS messages are mapped messages. We do not use Ikasan native object serialisation on the wire. The content of the messages is based on two interfaces – Ikasan Payload which has a simple provision for content and some meta-data aspects of that content; and Ikasan Event which provides a wrapper around one or more payloads for synchronous transport of payloads as a single atomic unit. We try not to burden others with these constructs and our integration recommended approach (to be published to the Wiki) dictates that common business message definitions be based on the business or industry standards (current example is ISO20022 for trade reporting and matching). This should be independent of Ikasan as Ikasan operates on this data via discreet configurable components.

Does Ikasan support standards like JBI, support for web services etc?

We haven’t really looked too much into JBI, but we would be keen for any of the contributors to explore this. Support for Restful services is in initial development as part of the next planned release – we have looked at Jersey, JBoss’s RestEasy, and Springs restful offering as part of Spring 3.0.

Could you throw some light on long terms vision/direction for the product?

In a nutshell – for Ikasan to be so easy to use and integrate business with that anyone regardless of background can put together a robust solution in a cost-effective manner. Users should not have to worry about transactions, application specific syntax or semantics – our nirvana would be plug and play integration for the business. Focusing on the finance sector allows us to take a slice of a well defined market and concentrate on building commoditised solutions for that. Please keep an eye on our Jira as we are trying to build this out currently for the short term, but also adding medium to long term goals.