Interfacing / Link Software

When various applications need to share information, a protocol determines how the communication takes place. The protocol could be a 9600 baud serial specification, or can involve advanced remoting middleware, such as ICE. We have experience designing solutions for just about anything in between these extremes.
As part of a customized solution, we have interfaced with many types of external systems. In some cases, the interface itself is complex enough to be worthy of a system of its own, for example, store-and-forward of data, many-to-many distribution, special protocol translations, etc.

External Link System Extension

For Singapore’s Changi Airport, we developed the External Link System Extension in 2006 to facilitate the translation of the 1980’s B-Line serial protocol into XML, which is then communicated through a Websphere MQ server to external clients (including Singapore Airlines Terminal Services). ELSE literally ‘stores-and-forwards’ flight information through MQ to interested systems. The XML protocol was designed by UFIS and Solution Space. The updates flow in two directions and the system caters for meta-requests (such as integration of a flight, block-transfers of entire data tables and so on).

Five Thailand External Link Systems

In 2009, we designed and implemented a FIDS-link system (FLINK) for five of Thailand’s international airports. The system collects real-time flight information and makes it available through HTTP to a central database, from where it will be formatted for Internet usage.

B-Line Serial Protocol Driver

For the ELSE project, we implemented a serial B-line driver to communicate with a Changi Airport legacy system. The same driver was provided to another customer as a stand-alone store-and-forward interface with a C and C++ language binding.

Middleware

‘Middleware’ refers to the concept of facilitating communication between various components of a software system. It provides communication and remoting facilities to all modules and applications within a system.

Internet Communications Engine (ICE)

Our preferred middleware is ICE, ZeroC’s Internet Communication Engine. ICE is similar in functionality to SOAP or CORBA, but is built for performance and supports bindings to many modern languages. It has many features not found in other middlewares, such as multiple host process management and grid-computing. Most of the high-performance, high-reliability systems that we design use ICE as the foundation for communication.

WebSphere Message Queue

For our ELSE project, we implemented a driver for IBM’s WebSphere MQ middleware.
In the early days of Solution Space, we wrote an MQ driver for Shen Zhen airport, such that a FIDS could communicate with an airport operational database.

SOAP and Web Services

SOAP and Web Services are increasingly becoming the preferred way of interfacing between industrial systems. We find that performance suffers under the XML transformations of the data, and the standard is quite cloudy when advanced features are required. That said, we use Web Services in a variety of external and internal interactions, such as TIMS.

.NET Remoting

If a system is entirely built on the Microsoft Windows platform and all applications use the .NET framework, and all the .NET frameworks are of compatible versions, then .NET remoting is one of the options for handling inter-process communication. In our systems, such an architecture is very rare, and so far we have used the technology once (in PACAMS).