Browse Prior Art Database

Integration Analysis to Support Product Migration

IP.com Disclosure Number: IPCOM000240792D
Publication Date: 2015-Mar-03
Document File: 2 page(s) / 62K

Publishing Venue

The IP.com Prior Art Database

Abstract

Utilising one or more of product trace, monitoring, command output and system dumps to analyse Integration Flows running within an Enterprise Integration Application to identify key indicators to risk associated with migration, performance and development to provide a ranked list and associated risk levels of Integration Flows to guide migration activities.

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

Page 01 of 2

Integration Analysis to Support Product Migration

Integration products provide their customers with a variety of features and tools to develop and deploy complex integration solutions. When a customer moves between products (from Integration ProductA to Integration ProductB for example) each product is likely to exhibit different characteristics for different technologies or supported logic - for instance, processing 1,000 200K payloads per second for a particular integration on ProductA may require 3 physical CPUs, but an implementation of the same integration on ProductB may require 4 physical CPUs, or may require a more complex integration design. Thus there is a need for prioritisation and risk management for such product migrations.

    Described herein are the methods and tools needed in order to assess the areas of similarity and areas of difference between the implementations of the two products and to thereby provide an indication of the level of risk or order of change between the likely implementation in the new product and the current implementation in the existing product. The output of these methods and tools would be recommendations that allow for the prioritisation of migration tasks and resources into the high risk areas first thereby reducing overall migration risk and so reduce the commercial risk to the software vendor.

The analysis will include an assessment of
Complexity of current implementation

      
Workload processing
Indication of the risk of potentially requiring additional resources
Indication of the risk of requiring additional development focus to address areas of unusual or particularly complex product usage

    The proposed method would collect information from a system processing simulated production workload - this could be done in several ways, for instance:

      Collect appropriate trace information - certain products may already provide the required information through trace

      Collect appropriate monitoring information - certain products may already provide the required information through monitoring metrics

      Collect information on shared / common resources - this could be gathered through appropriate trace / product commands / system dumps

    An alternative implementation would be a plugin module utilising Aspect Oriented Programming methods and byte code instrumentation to extract the relevant data from the source product. The plugin would need to be provided with the methods to instrument (namely those implementing an appropriate interface that models a logical processing block - a block executing a specific function within an integration flow - in the run-time) and variables / objects associated from which the Name and Message Size may be retrieved / calculated.

    The proposed method would analyse the collected information, which for each logical processing block would include:

Container Name

Type

Name

Message Size

         
Summary of processing
The proposed method would then be able t...