Overview

Roaming Components are designed to provide flexible TAP/NRTRDE processing at your fingertips and, as such, they adopt a highly modular approach. Each roaming component (also called “module”) is designed to perform a single TAP/NRTRDE processing task rapidly and efficiently. In many cases, a single roaming component can be enough to provide the solution you need. When this is not the case, two or more roaming components can be easily wired together to deliver more complex solutions.

Since you only need to purchase what you actually need, Semantix Roaming Components can be the most cost-effective, value-priced solution available. Components are independently developed, evolved and tested resulting in increased stability as compared to a more monolithic, tightly meshed approach. Components are also highly configurable. This is a byproduct of the design approach that has been followed. As each component has been designed to perform a single task in a variety of situations and settings, with no particular environment in mind, configurability was an absolute must. Semantix will also respond to further customization needs upon request for the rare cases where the configuration mechanisms do not cover your needs. In short, with the Semantix Roaming Components you can be rest assured that you have invested in a software infrastructure of superior robustness, modifiability and extensibility.

The technical model of the Roaming Components is one of independent application, each executing in its own address space. Each module is operating on one or more input files, produces as its output one or more output files and is configurable by means of (usually) an XML file. A number of usage scenarios may only need a single roaming component. When more are required, they can be wired together using simple shell scripting mechanisms, or, at most, small Python/Perl scripts.

The number of different control paths that need to be tested in a software system increases exponentially with its complexity. Therefore a system consisting of a number of decoupled components is much more amenable to testing strategies and will allow for a much larger control path coverage than the same system with all the constituent components integrated in a single application. Furthermore, as each component is implemented as a separated application, running in its own process space they can be tested in isolation and then put to work together secure in the knowledge that there are no interdependencies between the modules, no bugs that may arise due to their working together and no way for defects to propagate across modules.