Check out our general getting started in 10 steps. Programming with TECS will nearly look the same in all programming languages. Since the getting-started is not available in all languages yet you might take a look into the /examples/language/ directories. We provide at least a publish-subscribe example for all programming languages. Also, compiling, running, modifying the examples is a good starting point.
The best documentation is available in Java since we first implement features in Java and then reproduce them in other languages. Therefore, you should always take a look at the src folder in libtecs/java/ if you need to understand a function, method or argument.
TECS combines different communication methods together. The moment you have included our libtecs, you have access to all these methods. Therefore, it is important to understand them in order to decide which one suits your application best.
In publish-subscribe a central server is running on a central computer. All clients will connect to this central server. During connection, they inform the server about information they are interested in (subscribing). These are specified by a simple string which identifies the type of events the client wants to subscribe. The server will automatically forward events matching this type to all clients which subscribe it in form of events. A client can, on the other hand, publish information over the central server at any time by transmitting events, which must specify a type.
We suggest using Thrift to serialize the payload transmitted via the central server, but you can also publish and subscribe for binary data from any other serializer. The server itself will not take a look into the published data and therefore will not need to understand the payload.
In TECS, we use the term message passing to refer to a simple server-client (1:N) architecture that can communicate by exchanging messages.
Messages can be any binary data with a string as type identifier.
However, we recommend to use Thrift to specify the messages (see Thrift's structs) to avoid implementing the (de-) serialization and the message classes themselves in every required programming language.
Compared to RPC, a message passing server does not need a request to send data to a client.
Remote Procedure Call
Since TECS is built on Thrift, which allows you to specify RPC services and automatically generates appropriate clients, RPC can be easily used in TECS. Remote Procedure Calls should be used if you expect an answer from the server which must be associated with the request. Every time you think about making a request and expecting an answer, RPC is your choice. TECS supports you with creating RPC servers and clients and also allows you to automatically discover them. Take a look at our examples - especially in Java - to see the advantages of TECS in RPC.
Discovery is needed to find the services you want to talk to. Every module in TECS is able to be discovered. We provide a very simple technique for discovery via multicasting which includes automatic merging of different services. Most discovery techniques use interval based broadcasts to discover a service. This either spams the network with unnecessary traffic or takes time depending on the interval the service uses to announce itself. In TECS we use slow intervals to announce but increase the speed by letting the client request for available services via UDP Multicasting. The services will reply by UDP Unicasts. A special merging strategy will filter the services you need perfectly.
TECS uses URIs to announce and discover services so you can easily use it in combination with other software modules.
In this comparison, we try to explain the difference to other systems in an informal language. We are currently working on an elaborated scientific answer to this question and will share it as soon as possible. These are just our first impressions on a very subjective level.
ZeroMQ is a Transport Layer unification while TECS works on the application layer. Shortly said, ZeroMQ gives you sockets while TECS gives you data type definition and transmission strategies.
We actually checked if we could build TECS upon ZeroMQ but its abstraction from the network is so big that some things where not be able to be implemented using ZeroMQ, what forced us to implement our own transport layer. This is actually hard, because each programming language does things differently on the transport layer.
EBS was developed at DFKI. However, it is mainly developed for Java. It uses Java's serialisation of classes which cannot be transferred to different programming languages. EBS is a special tool for designing cyber-physical environments, mainly with software components in Java. However, it has some features, like filters and security, which are not part of TECS yet.
Similar to ZeroMQ only strings or binaries are transfered. There is no support in defining datatypes via an IDL. ActiveMQ uses JMS which uses only the publish-subscribe approach while TECS gives you publish-subscribe, message-passing, RPC and discovery and of course datatype definition using Thrift as IDL.
The name TECS, which stands for "Thrift Eventbased Communication Service", already gives away that TECS is based on Thrift. While Thrift only specifies RPC, TECS extends this basis with message based communication, among other approaches.
First and foremost, ICE is hard to google. You find it at https://zeroc.com/ and is the technology that is most similiar to TECS. Actually, it is very good, but harder to use than TECS. If you are working on production code, you should currently prefer ICE.
Protocol Buffers is an alternative to Thrift, but supports less programming languages and some statistics tell that it is also slower than Thrift. That is the reason TECS is built upon Thrift and not on Protocol Buffers, although the IDL beneath Protocol Buffers is very similar. Anyway, since TECS allows you to send binary blobs, you could easily use Protocol Bufferes to define your application layer communication. However, we do not give any support for this.