001 Type of the interface (Socket, shared library or managed code)

  • Status: accepted
  • Deciders: partners

Context and Problem Statement

What is the type of communication between the data client (DC) and the transformation engine (TE)? Should we force a network protocol or is it better to use in-process communication?

Decision Drivers

  • supportability: data clients can be easily implemented by a sensor/tool manufacturer
  • reusability: data clients can be integrated into different TE implementations
  • availability: Language for TE implementations are not unnecessarily restricted
  • portability: minimum supported OS are Windows, Linux (POSIX combatible)

Considered Options

  • Socket/interprocess communication
  • stdcall C interface
  • dotnet/java interface

Decision Outcome

stdcall C interface

Positive Consequences

  • no restrictions for TE implementations
  • managed runtimes as well as native code can access stdcall binaries

Negative Consequences

  • The implementation language of the DC is restricted to a language which is compilable to native machine code.
  • The data client implementation may influence the stability of the TE
  • The platforms a data client can be used at depends on the manufacturer of the controller/sensor.

Pros and Cons of the Options

Socket/interprocess communication

The data client is running as a separate process on the same or a different machine and is accessible via a custom network protocol.

  • Good, because dataclient is completely independent runtime environment from TE
  • Good, because a faulty data client cannot crash the TE
  • Bad, because it requires a complex binary protocol
  • Bad, because additional delays for inter process communication must be considered
  • Bad, because of overall system complexity due to multiple running processes

stdcall C interface

The data client is realized as a shared library (.DLL on Windows, .so on *ix) which is loaded into the TEK process.

  • Good, because all imaginable TE implementation languages can load C libraries
  • Good, because it is supported on every sensible operating system and processor architecture
  • Good, because it has nearly no communication overhead
  • Good, because a socket interface can be added easily if ever needed
  • Bad, because manufacturer must provided different implementations for all supported platforms
  • Bad, because the implementation might be more complex than a Java/CLR implementation
  • Bad, because the DC code runs in the process of the TEK and may influence its stability

dotnet/java interface

Use a common managed runtime like dotnet CLR, Java Virtual Machine or a Python interpreter to be able to limit the required effort to provide data client binaries for all supported platforms.

  • Good, because implementation might be easier for a given manufacturer
  • Good, because one data client runs on every platform
  • Bad, because only platforms with existing Java/CLR runtime are supported
  • Bad, because it limits the implementation languge to the languages available on the CLR/JVM