Message Flow Integration
https://sourceforge.net/projects/integrationflow/
..........................................................
calendar
iterations
Detailed project outline
Problem formulation
Integration of legacy systems usually involves asynchronous queues. A number of integration patterns apply to these queues. However, usually in the process of declaring these queues and programming the logic that combines the legacy endpoints and the queues in between, the high level architectural focus can be hard to keep, as too much attention is needed at the lower abstraction levels.
We seek to ease the integrational process by providing a tool that automatically generates queues and logic from a higher abstracted model.
Method
Software development in short, well-defined iterations. Clear goals for each iteration are defined in advance, but may be altered as we progress through the process.
Deliverables
The piece of software we have developed.
A report describing the process, the problems we have encountered and the considerations we have made during the process.
Basics
The nature of the most basic elements of the project are as such:
-
The integration patterns are of a theoretic, business-logical nature. The book "Enterprise Integration Patterns" describes 65 of these, many of which could be implemented in our application.
-
Message-driven EJB's should be generated to reflect the specific pattern it represents the pattern it represents. Also, it must reflect the context in which it is to be deployed (e.g. what queues it connects). After generation, MD-EJB's must be packed as an EAR-file and deployed on a J2EE-server. This, of course, should also be done automatically.
Although some basic patterns can be solved by many queue-systems alone, at least to begin with, we want to make a clear logical distinction of using queues only to provide asynchronicity, and wrap all pattern-logic in message-driven EJB's. Later, for performance optimization, we might decide to take further use of the functionality of the message queues.
-
Queues are server-controlled entities. As such, the way we should control them in our application is significally different from how we generate MD-EJB's. We need to tell the J2EE-server to create, drop, etc. the queues. This will be done by our application through the JMX API. The connection between queues and MD-EJB's is controlled with the JMS API.
-
We seek to develop an XML language to represent the integration system designed by the user. This will be the middle
Iterative development
For the time being, we are developing our software in an iterative process, more or less conforming to existing agile development development methods described in the litterature. However, please note that we are not trying to make this an assignment on software development methods. We are meerly taking an approach that we feel is logical and best suited for what we try to accomplish.
We have described the various stages of development on the iterations page.
What's next
Further areas, that we likely may need to investigate after this includes:
-
Integrating more patterns as MD-EJB types. It is by no means our goal to implement e.g. all patterns described in EIP, but a few more will be needed, even to just provide proof of concept.
-
To make our application interesting to the world, we hope to make a dran-and-drop-like GUI plug-in for the Eclipse framework.
Here, the Eclipse Modeling Framework (EMF) may help us a long way in we represent the model of the architecture. Further, the Graphical Editing Framework (GEF) may provide us with much of what is needed to build the GUI.
Both these frameworks must be evaluated and possibly tested as to how applicable they are to the project.
Preliminary literature
Enterprise Integration Patterns - Designing, Building, and Deploying Messaging Solutions, Gregor Hohpe & Bobby Woolf