You are here

Distributed architectures

Distributed architectures


TANGO is an object-oriented distributed control system. It is a software bus for connecting hardware and software objects via CORBA technology. Devices can either be located on the same computer or distributed across computers linked by a network. Programming support is available for C++, Java, and Python. TANGO provides libraries which mask network access details and enable the use of objects. Tango SystemTANGO is based on the principle of a software bus—a set of links (cables, printed circuits, etc.) which may be shared by several devices for communications.
All the devices connected to the bus can intercommunicate. Thus applications such as system configuration tools, supervision tools (for monitoring the status of certain devices), and test interfaces communicate not only with one another but also with all the system's hardware. Hardware devices are connected to the bus via a server application called the “device server” which offers TANGO interfaces. Programmers can either use generic methods and attributes for each device server, or write custom ones.
Some of the code can be generated automatically using the tools provided: developers simply add the code required to manage the hardware. This code can access the vendor-supplied control system (DLLs, libraries, RS-232 commands, GPIB, etc.).
Heterogeneous equipment can be connected to the TANGO bus and communicate. Users are unaware of the diversity: they benefit from well-referenced and accessible methods and attributes.



Component Object Model (COM) technology enables communications between software components. Developers use COM in order to create reusable software components for building distributed applications, and to benefit from Windows services. The family of COM technologies includes COM ,+, Distributed COM (DCOM), and ActiveX controls. Microsoft provides the Component Object Model (COM), an OLE communications standard between various applications. It defines the method for accessing the functions of OLE objects, and the main services required to integrate objects. Programmers wishing to develop an OLE application had to comply with the standard calling protocol and provide various services defined in OLE. The standard was designed to be open, i.e. developers did not have to provide all the services defined in OLE to be operational. However, the more services an OLE object offers, the better it is integrated. Similarly, the more an application can use services, the better it works with the objects providing those services. Furthermore the system is extensible: you can define services other than those defined in OLE.  Most services are defined in OLE, however; and COM itself uses some of those services. Thus the line between what is defined by COM and what is defined OLE is unclear. In principle, all system services are COM services.

Microsoft created Distributed COM (DCOM) to extend COM technology in order to make it possible to distribute components over a network.