|
ITHACA - Interoperability Through Handler and Codec APIs
|
ITHACA is an architectural approach for integrating heterogeneous distributed computing systems. The acronym stands for Interoperability Through Handler And Codec APIs. The ability of heterogeneous computing systems to interact in a coherent and consistent manner is the first objective that the interoperability attempts to address and resolve. The second objective would be to minimize the impact of changes throughout the components and the system as a whole. Interoperability does not focus on the interacting components themselves but rather on the interface between them. Interoperability might be horizontal or spatial, for existing components, as well as vertical or temporal, for legacy and future add-ons. One of the most obvious methods of achieving interoperability is to elect or define a unique set of descriptors and rules that describe the state and behavior of the component interfaces. Each component has a native set of descriptors and rules that fit in the best possible way that component but not others. This implies that certain conversions must be performed which usually induce a certain overhead on the system resources (memory, CPU, network bandwidth, etc.). The aim is, of course, to try to minimize the number of such conversions. In smaller distributed systems one can inspect which is the dominant set of native descriptors and rules and elect them as the interoperable ones, leading to many interfaces that do not need conversions as well as the largest number of single conversion interfaces. But in larger systems and particularly if one needs to achieve a temporal interoperability the election of a dominant set is not an effective way forward. In this case an external or foreign set that guarantees a maximum stability of its definition and structure and providing a sufficient provision for a spatial and temporal interoperability is necessary. Such sets are usually defined and described by true or de-facto standards. In many cases, a wide coverage and adoption is achieved with sets that are not native to any system, like HTML or XML for example. If the interoperability is required for every individual component in the system, then double conversion interfaces are necessary everywhere. By keeping the descriptor and rule conversions within each component one can achieve only the first interoperability objective. The essence of ITHACA is to isolate the descriptor conversions in codecs and that of the rules in handlers and pulling them out in standalone APIs thus minimizing the impact of changes to those codec and handler APIs only, relieving the components themselves of such concerns. The following picture represents schematically the transition of a native system to an ITHACA compliant one: By choosing an ITHACA approach not only one can achieve the second objective of the interoperability, but it also gives the choice of applying such conversions only where they are really necessary and not everywhere in an indiscriminate fashion. The benefit in performance, without loosing that of interoperability gained by using an ITHACA approach, may become obvious in systems where certain interfaces are intensively used and where double conversions from and into the same native representations (A-S-A) are not necessary.
|
|
|