MainConcepts

The building elements of VSCB are parts, devices and wires. Parts denote software components, while wires are the component connectors. We use different terminology here because the terms components, interfaces and connectors have widely varying interpretations. In our approach, components and connectors are standardized and thus we call them parts and wires as shortened terms for ‘VSCB components’ and ‘VSCB connectors’. Parts consume, produce and/or transform data. Parts are anonymous collaborators. That is, there is no coupling between different parts. Part interfaces are also standardized. The interfaces provide ports to input and output data. Each port is denoted as either an inpin (consumes data) or outpin (produces data). A part is not a single object (class instance) – it can contain many objects. Parts are coarser grained than objects and usually provide services rather than methods. Parts, in contrast to objects, don’t share memory space and threads and can be distributed.

Parts can be atomic or composed into devices (composed, or assembled, from atomic parts and/or simpler devices). Atomic parts are implemented in an underlying programming language, such as Java. In device diagrams they have terminal elements, which correspond to inpins and outpins of the device.

Wires connect parts and forward data from one part to another. A wire connects part outpins with part inpins. Adding and removing wires do not affect parts. If a part outpin is connected to more than one inpin then the VSCB framework takes care of multicasting the output data. Wires can be combined with basic transformers to make outpin data types compatible with inpin data types.

Wires are not similar to class associations; rather, they are first class elements. Unified Modeling Language tools make associations a part of a class so that the class is ‘aware’ of associated classes. Wires are external to parts. Re-wiring the schema doesn’t change anything in parts. Wires are similar to pipes. The VSCB framework is responsible for forwarding the part produced output along wire(s) to destination part(s). The framework accepts the declarative configuration, parses the configuration and executes it. Specifically, the framework instantiates parts, fires inpins, accepts outpin data events and forwards them according to the schema of wires.

The configuration can be run in interpreting mode or executable code can be generated. As soon as the configuration is final the code can be generated with hard coded connectors. In this fashion, data transports are faster. With respect to web applications, a servlet can be generated.