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

A Framework for Inter-Module Communication

IP.com Disclosure Number: IPCOM000013369D
Original Publication Date: 2003-Jun-18
Included in the Prior Art Database: 2003-Jun-18
Document File: 4 page(s) / 67K

Publishing Venue

IBM

Abstract

A simple method/process to build an extendable sequential flow mutli-threaded Java application without recompiling any base modules, as new ones are added. The key to this invention is the use of an XML control file. The control file defines how the base Java application will function. For instance, it determines how communication between the different modules will take place, how data will be passed among them (e.g., via primary memory or secondary memory), and will layout parallel execution (multi-threading) paths where appropriate.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 4

A Framework for Inter-Module Communication

The basic architecture consists of a Java* Application, a control XML file, and various methodHandlers. The base Java application will read/interpret the XML control file. This file has a sequence of "methodHandlers". Each methodHandler is a wrapper class to the actual module that is executed. The main program contains a "resultVector". This vector stores the result of each program module called by their corresponding methodHandler. Every methodHandler has a reference to the main program (object) and hence will be able to store the results of its program module into the main program's resultVector. Every MethodHandler class is itself a subclass of a generic abstract MethodHandler with a single method called getResults. The getResults method creates an instance of the new module, executes the module and stores the results from the module into the resultVector of the main program. Even though the execution of the program is sequential, the flow is broken down into a n-nary tree where the nodes of the tree are modules who are either not dependent on other modules for execution or already have the results from other modules for execution. All the modules in the same level are executed in parallel while the modules in n & n-1 levels are executed sequentially thereby substantially increasing the speed of execution. The tree is formed by looking intothe input and output indexes in the XML file for each module. See Flow Diagram:

1

Page 2 of 4

Flow Diagram

MethodHandler1

XML control file

MethodHandler1 MethodHandler2 MethodHandler3 MethodHandler4

Main () {

Results vector

Read XML file

While(more_MethodHandlers) { Call getResults () }

R1

R2

R3

R4

getResults () {

......

main.results.add(...)

}

MethodHandler2

getResults () {

......

main.results.add(...)

}

MethodHandler3

getResults () {

......

   use Results main.results.add(...)

}

Main Program Steps :
1) Read the control XML file and and create dependency graph as shown in fig2.
2) Call the methodHandlers using the dependency graph. If methodHandlers can be executed in parallel (as per the dependency graph)then use multi-threading.

Method Handler Steps :
1) Get the required inputs from the Results Vector of main program.
2) Call the module to be executed and get the results.
3) If results need to be processed then process the results.
4) Save the results in the Results Vector of main program.

    The main advantage of this over similar applications is that this defines a unique framework of Inter-Module Communication (IMC) from the control XML document. It uniformly depicts how communication between the modules within the main application is to communicate with each other (see layout of control XML document below). The methodHandlers operating in the framework will work with local memory (i.e., main

.

.

.

.

2

[This page co...