Getting computers, systems, and software to talk with each other can be extremely complex and time consuming. Interoperability issues have challenged system architects, designers, system engineers, software engineers and test teams since the advent of computers. We should have best-of-breed approaches that everyone can subscribe to, right?

Unfortunately, interoperability is a moving target. The number of computer interface languages and protocols continues to grow and change over time. Some have been around for decades whereas others fall out of favor for various reasons (e.g., complexity, cost, etc.) only to be replaced by newer interface languages and protocols.

The result? As the number of protocols increases, system complexity increases. This increases the amount of software devoted to communications—which increases development, testing and maintenance costs.

New and/or evolving standards and protocols further challenge us to develop and test cost-effective, high-quality solutions in a timely manner. New technologies such as the Internet of Things (IoT) will simply add more fuel to the ‘complexity fire.’ It isn’t unreasonable to expect that some of the thousands of new devices currently in development will use their own proprietary interface language—at least until vendors embrace new industry standards. Getting legacy systems to communicate with other systems and devices using old and new protocols is a significant interoperability challenge.

A variety of tools and methodologies have been used to try to solve interoperability problems, including custom software to perform protocol translations, gateways, and middleware products such as Enterprise Service Buses (ESB). Each approach has challenges. For example:

• Manually modifying existing applications to use new protocols oftentimes increases development risk, schedule, and cost since multiple applications/components have to be updated whenever new protocols are introduced.
• Development of gateways to translate protocols centralizes the functions associated with protocol translation, reducing or eliminating the impact to existing software applications. Unfortunately, this approach may impact system performance since all the translations are performed by the gateway. As a result, architectures often incorporate multiple gateways, which, in turn, increase overall system complexity.
• Service Oriented Architectures (SOA), such as ESBs, provide a middleware infrastructure to connect and route messages and data among software applications. However, the complexity and cost associated with selecting, integrating, configuring, and maintaining the appropriate ESB often presents a challenge to an organization’s technical and management teams. Moreover, the ESB, in many cases, provides significantly more functionality and capability than is required to simply address protocol translations.

So what can be done? Fortunately, a new approach, called the Automated Protocol Translator (APT), addresses interoperability issues. The APT translates different protocols without modifying existing systems or software, at a lower cost, in less time than current approaches. The APT is a tool (incorporated as an Eclipse plugin) that generates all the software needed to translate protocols while eliminating the need for manual software development. If available, a project’s existing Interface Design Languages (IDLs) definitions such as CORBA IDLs or Google Protocol Buffer IDLs can be used to further expedite the protocol translation software generation process.

Tools, like the APT, are new and unique approaches to removing expensive, manual activities from the development process. Manually generating software to translate multiple messages/fields normally takes weeks or months to complete. But with a little up-front work, the APT can reduce this effort to hours.

In a forthcoming post, we will explore more deeply APT features and how this approach can generate better quality interoperability solutions faster, and cheaper than existing solutions.