Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Automatic Migration of Integration Intention

IP.com Disclosure Number: IPCOM000237539D
Publication Date: 2014-Jun-20
Document File: 2 page(s) / 68K

Publishing Venue

The IP.com Prior Art Database

Abstract

This article describes a system that uses analytic techniques to migrate integration logic from one form to another, so it might be reused by a different integration provider. By observing existing black box behaviour and correlating data a model of intention is generated using plugins provided by integration experts. The model can then be converted to a particular integration providers format using plugins supplied by the integration provider.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 54% of the total text.

Page 01 of 2

Automatic Migration of Integration Intention

Migrating from one integration product to another is an extremely complex process. It takes deep understanding of both products to ensure the behaviour or intention is replicated exactly during the migration. This is currently only possible for experienced integration engineers.

    Often migration tools are provided, but they focus on matching the individual components of the integration logic to a matching component in the new system. This only provides a skeleton solution and does not ensure the intention of the existing system is replicated.

    A multi step system is proposed that monitors an existing running system as a black box. Data is collected and correlated so an abstract model of the integration intention can be created and used to generate integration applications in the format required. Thus providing a more comprehensive migration than current tools and ensuring the intention of the integration logic is not lost.

    1. Capture Phase. A pluggable interceptor framework is used to monitor the existing system and capture all requests, responses, inputs, outputs and log files.

    2. Correlation Phase. A pluggable correlator framework is used to correlate the unstructured data into sets of requests, responses, inputs, outputs and logs that all relate to the same transaction. Examples would be checking for correlation information in the message headers, checking for correlators in the content of the message body, or matching on threadId or tracking a synchronous invocation.

    3. Application Generation. A plug...