Manage Learn to apply best practices and optimize your operations.

Open source middleware and SOA help FAA distribute weather data

The Federal Aviation Administration exploits Web-oriented open source middleware to modernize its systems while still safeguarding passenger safety.

Though its work is somewhat behind the scenes, most travelers know they depend on the Federal Aviation Administration (FAA) to ensure safe air travel. In the past, the organization has often scrabbled with technology and change. In fact, many of its systems have a lot of mileage on them and are difficult to modernize.

But in recent years, development groups within the FAA have set out to show that the organization can exploit Web-oriented open source middleware to modernize systems. The question was whether they could improve integration and cut costs, while still safeguarding passenger safety. Early results from a Web services and Service-Oriented Architecture (SOA) project suggest they are well on their way to this goal.

Under the aegis of the System Wide Information Management (SWIM) initiative, the U.S. Department of Transportation's FAA funded a program to transform methods, encourage data sharing and employ modern standards such as XML and Web services, said David Reiser, chief project engineer for this SWIM integration project. 

Figure 1

Reiser and his colleagues built an application that provides real-time weather updates in standard data formats to users of the National Airspace System, which is the umbrella description for the diverse systems and people that daily control U.S. commercial aviation operations.

This application Reiser and his team built brings considerable use of SOA and open source middleware to a system that was historically hardwired and custom built.

The team uses the Apache Camel integration environment, the Active MQ message broker, along with other open source middleware tools, to take weather feeds from the SWIM Integrated Terminal Weather System (ITWS).

These feeds are than processed and distributed, providing information on real-time weather events (see Figure 1) to external users in less than 1 second on average -- the application's compressed data stream runs at about 1 Mbps, streaming about 9 GB per day.

While pilots and air traffic controllers will still rely on traditional, direct sensor data, the SOA-based complementary system is seen as valuable to airlines planners and airport personnel, among others.

Reuse of code was a major goal, because using established code can save money and increase reliability.

"If you reuse something that has already been done, you reduce the source code that has to be maintained -- maintained sometimes for decades," said Reiser, who spoke at the recent CamelOne Conference in Boston, Mass. 

He was joined in the presentation by colleagues Ram Raju, senior IT architect, and Shane Kent, software engineer, both working for Computer Sciences Corp. and assigned to the Volpe Center within the U.S. Dept. of Transportation.

Reiser estimated his team saved 19% in cost and lines of code because of re-use. He said the team found readymade open source components to help them on their way. They found, for example, a readymade security component already existed in the Apache Camel community.

"This is a tribute to Gregor Hohpe," said Reiser, alluding to the noted author and systems architect who compiled a canon of reusable software patterns for enterprise application integration. Camel uses those same patterns.

Reiser and others see potential to use messaging middleware to integrate standard format air traffic and weather data with a variety of readily available Application Programming Interfaces (APIs). At the CamelOne event, the FAA team demonstrated the integration of flight data plotted against a Google Earth application using KML, a file format that can be displayed as geographic data in a Web browser.

The FAA work shows that open source enterprise software continues to grow, handling more and more of the toughest jobs that the modern world has to offer. Also shown is the fact that messaging middleware is coming to underlie complex software integrations that bring needed data to decision makers on a near-real-time basis.

Dig Deeper on Topics Archive

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

I agree the general thrust of this article, that middleware is increasing in importance. However I disagree that "using established code can save money and increase reliability", it may save money, but it probably won't improve reliability. At best reliability will be sustained, but that's unlikely too.

But the issue here is that middleware is being thought of as a messaging mechanism, which is part of its role - but like the operating systems on a computer, middleware can do a lot more for a distributed systems of systems than just facilitate communication. If thats all it does, and many do, then its just a set of software stovepipes that will get progressively more twisted and convoluted as more legacy code is integrated.

Good middleware will encourage quality code development through architectural system of system clarity. Legacy code can be considered as a set of data sources and sinks, which can represent state change.

When you do that, your middleware has the opportunity to increase reliability in your systems of systems. There is an open standard middleware that embodies these architectural principles, DDS (Data Distribution Service) from the OMG. Take a look.