Message Flow Integration

Iteration 1

Goal:

The goal of the first iteration is to gain a more solid understanding of the project at hand. This should help us take futher iterations in the right direction, and catch basic challenges at an early stage. We seek to get this understanding by experimenting with the most basic elements of the project: queues, MD-EJB's, simple integration design patterns and an XML representation of this small architecture.

The first pattern that we seek to generate is the Publish-Subscribe Channel. This is simply a way to recieve a message, and then send it to a number of other queues. As there are queues on the reiceving side, this is very similar to Durable Topic Subscribers in JMS. As we have stated earlier, although the pattern already exists in JMS, so far we seek to put all logic inside MD-EJB's, and since this is such a simple and basic pattern, it is not a bad place to start.

The XSD-schema for this XML-format will probably be very simple, and subject to much further development.

From an XML-file conforming to this schema, we should be able to automatically generate and deploy the needed MD-EJB's and declare the needed queues on the J2EE-server. Finally, simple endpoint client programs should be written to test system by sending and receiving messages at the endpoints.

So far we will work with the text-type of messages, where the text is in XML format.

Having implemented this small version of the system, we hope to have a better idea of what further steps will be best to take.

Deliveries:

• A simple XML representation of the queues and Publish-Subscribe patterns of the system.
• Software that takes this XML file as input, and generates:
  • Deployment Descriptors (standard ejb-jar.xml and WebLogic specific weblogic-ejb-jar.xml)
  • Message-Driven EJB's with the logic to forward the recieved message to the appointed queues
• Simple client to send messages to the input queue.
• Simple client to recieve messages from the output queue.

Conclusion:

JDOM proved to be a simple way of handling XML within Java, but tends to bring about many lines of code. Further, representing parts of the XML tree as String is not, we feel, the optimal way to handle XML. We will look into technologies that may provide a more object-oriented approach to this in future iterations.

We mistakenly called the pattern that we have implemented in iteration 1 "Splitter". The functionality of our MD-EJB actually resembles the Publish-Subscribe pattern, and should have been called by this name. Thus, in further iterations, the name Splitter resembles something different than what was implemented now.

We have touched on JMX, but are so far heavily relying on code copied from an example found on BEA's website. This is sufficient to create JMS Servers, JMS Connection Factories and JMS Queues, which is all we need for the time being. Thus, we choose to skip gaining a deep understanding of JMX at this point. All JMX code is WebLogic specific, and does not nessecarily look at all like similar code for other J2EE servers.
Later we may need additional JMX-code, e.g. to monitor the status of queues. We will deal with this issue as it comes along in future iterations.

Iteration 2

Goal:

Decide on a final structure of the XML format, that is extensible with more logic pattern, but otherwise can be considered final.

Implement XML format and generation code for the Filter pattern, Queue and Topic (the first being an EJB, the latter being the two JMS concepts).

Implemention is with XMLBeans and Velocity, and will hopefully also be more or less final.

Deliveries:

Application with more logic implemented in a more robust way than Iteration 1. I.e. using more suitable technologies, based on a final XML format, etc.

Conclusion:

Iteration 3

Goal:

Have GEF up and running.

Deliveries:

The logic implemented in Iteration 2, with a GUI to control the flow structure, manipulating the XML file.

Conclusion:

Iteration 4

Goal:

Implement the Transformation pattern. This will take an XSL/T string to manipulate the XML contents of messages.

Being able to implement a pattern at this time will prove how extensible our system is (or isn't).

Challenges:

What will the GEF graphical representation of the transformation look like?

Deliveries:

As Iteration 3, but with the Transformation pattern available.

Conclusion:

Future Iterations

To do's:

Solving the issue of circular structures.

...?