Several models allow representation of the interactions between logic components of a system and their dependencies. One of the first of these models was the model Input-Process-Output (IPO), followed by its evolution, the model Hierarchical Input-Process-Output (HIPO) . These models allow conceptualization of the logic components of a solution as well as their inputs and outputs. The evaluation of the inputs and outputs between logic components and virtual components allows us to describe the possible interactions between the components of the virtual layer.
The first high-level elements identified by the IPO model are the inputs and outputs. For a monolithic solution, three input/output possibilities between a logic component and a virtual component are available: one where the virtual component is a data source; one where it is a data target; and one where it can be the source and the target of the only logic component of the solution. In a distributed environment, another scenario presents itself: the case where the virtual component is the output of a logic component and the input of another logic component, via a second virtual component and a communication link. Then, the virtual component is used for communication between two logic components of the same solution. The availability of these two virtual components, as well as that of the communication link, impacts only the parent component, since the dependency is unidirectional.
The IPO model identifies another characteristic: when the information is transformed between the input and the output of the virtual component by a process. So finally, then, a last characteristic must be taken into consideration when evaluating a virtual component: the ability of a component to have persistence, so that the virtual component can maintain a state between two calls.
The direction of a dependency between a logic component and a virtual component does not represent the direction of the flow of information. A unidirectional dependency can have feedback, no matter the direction of dependency, as long as the initial request is in the direction of the dependency.
Although a logic component can have inputs and outputs from the same virtual component, some combinations are not possible. In some contexts, a logic component may have the same virtual component as input and output, without transforming the information or changing the state as shown in figure below. The logic component in this figure may then be cut into two distinct logic components, which each depend on a virtual component and are linked by a communication link. So, by having as premise that a two-way dependence is cut in this way, an assumption can be put forth: a virtual component does not transform information, does not conserve state, and cannot be the input and output of the same component.
If a virtual component transforms the information and does not maintain state, it is not possible that this component is unidirectional, based on the IPO model described earlier. In effect, a virtual component transforming information must receive information to transform and must return information from the transformation. Also, a virtual component that processes information, but has no feedback, is not a virtual component. It is a service exposed by a public interface and used by an external solution, or is it a separate logic component that cannot be virtualized. Since the processing components are communication links, it is useless to have a virtual processing component with no feedback. A virtual processing component is therefore necessarily bidirectional.
Finally, if a virtual component conserves a state, it can be used both as an input, to access information, as well as an output, to conserve information. It can also be used both as an input and output of a same logic component, just as it can be used for input and output of several logic components.
It is possible to denote the types of virtual components covering all the probable cases of interaction between a logic component and a virtual component:
- a transitional virtual dependency is a component serving as an output or input to a logic component, without transforming information or conserving state, which is connected to another virtual communication component having the inverse interaction with another logic component, such as a logic communication link;
- an immutable virtual component serves as both input and output to a component or several components, and maintains a state between calls, like storage on mass media (a database, a file, etc.);
- a virtual processing component serves as much as input and output to a component, and transforms the information. This virtual component must be a function strictly in the direction y ← f(x).
The following table shows the possible interactions between a component and the abstract characteristics of a virtual component. These abstract characteristics take into account the inputs and outputs from a same logic component towards a single virtual component. Although some interactions seem impossible, they will be noted as improbable, since the test does not cover all possible circumstances of these combinations.
|Input only||Output only||Input & Output|
|No transformation, no state||Possible||Possible||Improbable|
Possible combinations of the above table therefore deliver the three types of virtual components. In this study, the virtual components, combined with the logic components, form the only two kinds of components constituting a solution, the physical components being abstracted by the virtual components or taken into account in the availability of logic components.