David Mattioli and Mike Pone, both senior staff software engineers at Lockheed Martin, presented an informative session at CamelOne 2013. They explained how they used Camel routes to simplify the integration of new Java applications with a tried and true C++ flight scheduling application. The flight scheduling application works extremely well, with no incidents and little -- if any -- downtime, so there's no need to replace that software system. However, it was a bit hard to reach.

Download this free guide

Download now: Java EE moves to the Eclipse Foundation

What are application developers and market analysts saying about Oracles decision to move Java EE to the Eclipse Foundation? What will this change? Find out here.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

The old system used to require air traffic controllers in the tower at the airport to phone in changes to Central Air Traffic Control for updates, Mattioli said. This would happen if, for example, local weather delayed a flight and that flight would need to be rescheduled. Then the airport tower would call a central desk that would enter the information into the system and return the new time to the airport, still by phone. The team at Lockheed Martin built a Java-based software system that would allow the airport to access the central application themselves, saving time and hassle for the whole traffic control system.

The major technical challenge the team faced was converting XML messages and POJOs with which their modern applications work into byte messaging that can be fed into the legacy C++ app. Mattioli and company's flight scheduling application is very particular about the types of bytecode messages it will receive and how those messages must be formatted.

Take advantage of enterprise integration patterns

Mattioli fessed up that one technical mistake they made along the way was to create a plethora of small independent routes between endpoints. The team created many bite-sized routes with one endpoint processor per route. They expected these routes to be highly reusable, and that many routes would provide optimal throughput.

In effect, Mattioli found that his team was reinventing the wheel and trying to outperform the enterprise integration patterns that the Camel system is already designed to optimize. Mattioli now advises other teams taking on similar projects to "take the focus off of what you can write. Let the components and patterns do what they're supposed to." At the same time, he encourages developers to build their own custom components when the existing components don't fit immediate needs. Just check if you really need to first.

There are four questions messaging systems designers should ask themselves, according to Mattioli:

What's the route?

What are the endpoints?

Does Camel have existing endpoints to use?

Does Camel have existing processors that will work?

Turning Java into C++

Mike Pone led the effort to ensure proper messaging between the C++ legacy application and the current Java systems. Pone said a lot of the work was done with tools from the open source project Javolution. He said Javolution emulates each and every C++ primitive in Java. From there, Java developers can build nested C++ structures as needed.

Pone stressed the importance of ensuring every C++ byte message produced by the Java application is formatted just so. If the byte buffer, which returns the C++ byte image, is misconfigured, then the legacy C++ application will not accept the input and things could break.

Pone explained that his team created a C++ test application to ensure each byte code message had exactly the right size and offset. That C++ testing was then automated as part of a JUnit test that ensures the compiler configurations are identical and the sizes and offsets of each message match. For longer or more complicated messages, Pone said, he sometimes had to compare tests field by field to find where a mismatch was introduced.

Communication challenges

In addition to the technical challenges, the team also had to find ways to work together over long distances and to explain to their bosses what they were doing and why. Mattioli described their project management system as "Scrum via telecommunications." There were major players on the team that others knew only by voice and avatar.

Mattioli gave a good deal of detail about what it was like to explain their design model -- which was largely Spring-injected Camel routes -- over the phone to the company's chief technology officer and vice president of engineering. "These are smart folks," Mattioli stressed. "Lockheed promotes from within, so these guys came up through the ranks themselves as engineers and systems designers."

Despite their technical expertise, it was still difficult for Mattioli and team to explain how the system worked with sequence diagrams. "We could hear the silence of not understanding coming from the phone." Mattioli said the problem stemmed in large part from the complexity of the project and the amount of detail that needed to go into the flow charts and sequence diagrams. Mattioli found Gregor-grams were more effective in relaying the basics of the messaging system without getting bogged down in excess detail.

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy