EAI High level implementation

The EAI Overview introduced us to some key terms and concepts, but now it is time to look at something in a little more detail. To help illustrate, let's look at a simple scenario.
File Processing SystemOnce again, let's keep things really simple for now. We will start to add complexity as we go. Right now have a need to create a file processing system that will do the following:

• XML files are dropped into a folder called process_folder.
• Each file is sent to a third party tool that is running on separate Unix box.
• The output from the third party tool is a binary file
• These binary files can only be processed by an executable installed on a Windows machine.
• The Windows machine consumes the files and stores them in a repository

Possible SolutionAt this point the eai patterns seem like a good fit. We know there are several implementations available to us, but Apache Camel will provide us with what we need. And since its just a java library, it relieves us of some of the complexities surrounding ESBs.
With Eclipse, we can create a new Maven Project using one of the available Camel Archetypes. The archetype we pick depends on the container we want to run it in and the DSL we want to use.
Next we can create a route using our favourite DSL that contains the following:

1. A File Component's consumer would poll the process_folder directory for incoming xml files. The producer would create a message containing headers and the body would contain the content of the file. Please see the File Component for further details.
2. Since the third party tool runs on a separate machine, we could add a message to a queue that it is listening to. For this we need a JMS Component
3. The message could contain the location of the input file and possibly the location where it wishes for the output to be placed.
4. The route would also need to move the input file and the output to be available from one application server to the next. Please refer to the File Processing section for further details.
5. The route would then need another JMS Component to pass a message along to the Windows machine.
6. Now the message would contain the location of the output from the previous step along with the location of where the new results should go.
7. The route would then consider the job complete.

Sample code and further details to come in a future article.
File ProcessingAssuming that each of our application servers can access the same share or mount, we can do something like this:

• Move or copy each file from the process_folder to a directory called work_folder/<unique_identifier>/step1. This will allow the first application to have an isolated area in which to work with the file.
• Create a directory called work_folder/<unique_identifier>/step1/result. This will be where the application will put its results
• Move the file(s) from work_folder/unique_identifier/step1/result to work_folder/unique_identifier/step2
• ... and so on. With all this moving, we are going to want to create a custom component that can handle this for us. More on this in a future article. In the meantime, have a look at: Writing Custom Components

NOTE: Unique identifier can be the CamelID which is provided in the header of each message. An idempotent repository can be used to ensure uniqueness across processes.
Application AdaptersOne question still remaining is just how do we get these legacy systems to listen to a queue. One way is by creating an adapter that will listen to the queue and launch the application in a separate command line process. Since Apache Camel is just a library. We can do something like this:
With Eclipse, we can create a new Maven Project using one of the available Camel Archetypes. Once again, the archetype we pick depends on the container we want to run it in and the DSL we want to use.
Next we can create a route using our favourite DSL that contains the following:

1. A JMS Component listening on the same queue that our other route is sending messages to.
2. We would then use the input file location and the result location provided in the message header, and pass them along to a command line process.
3. This command line process can be run using Camel Exec
4. External processes make tracking progress challenging. Implementing this would vary from application to application. One option would be to monitor log files, queues or tables that the process may be updating. Our route could place messages on a separate queue that a "Progress Tracking Application" could consume. This issue will be covered in greater detail in a future article dedicated to Application Adapters.
5. We could then set the body with the location of the output and allow Camel to return the message.