a main component, inspired by autonomic
system, that handles the rules and the
objectives to satisfy (Hybrid application
engine);
a component of web service orchestration for
the implementation of identified actions and
for collecting feedback;
a set of application services for the
management of the new features.
In this architecture we will identify at least four
conceptual levels at which the logic of the process
operates: 1) the agents that monitor events, 2) the
rules and objectives of the autonomic engine
(dynamically changed by the collected feedback), 3)
the workflow system of service orchestrator engine,
4) the specific processing services.
Supporting the development cycle with specific
authoring tools, we can "describe" a good part of the
process at a logical level higher than classical
programming techniques. This results in a
significant reduction in time and cost for
development, testing, and for the future evolutive
maintenance of the system.
4.1 The Filter Component
The filter component in the diagram of figure 2 has
been included only to highlight the need to intercept
the transaction's input received by the system and
translate it into events for the new application
engine. In reality this can be done differently
depending on how the information system has been
created.
The filter can operate in a "transparent" mode
with respect of transactions in the existing system or
it can intercept new transactions that can be
deployed exclusively in the new system.
With respect to existing transactions, if the
system includes a "Front Controller" component, the
solution coincides with that shown in the diagram.
Alternatively events can be taken from a log file
of transactions, captured by a transparent proxy or
even through a simple function to invoke before
each component of the existing information system.
The latter solution is certainly the most invasive
but anyway has a low criticality since it is an
intervention that can also be made automatically.
The main objective of this component, however,
remains that of "listening" the requests sent to the
system and eventually turning them into "events" of
interest for the new application engine.
4.2 The Hybrid Application Engine
This is an event-driven "application engine" based
on autonomic principles (which follows essentially
the structure). In particular, the "Monitor"
component collects and controls events sent from the
filter or from the sensors network and, if necessary,
forwards them to the analysis component.
The sensors network, useful to extend the
perceptual capabilities of the system in the "out of
home" environments (if is present) is implemented
through a system of cooperating agents that process
the events themselves and send them to application
engine.
The Analysis component will check which
business rules apply to the treatment of the event.
The choice of rules can be taken in many ways,
especially taking into account a number of state
information related to the environment (environment
variables) and the feedback received from the
execution manager.
In particular, the rules used to decide which
processes to run, are of two types: 1) rule "still
valid" that are evaluated in a predefined order and,
when met, are performed (and therefore more of a
rule can be enforced), 2 ) rules "alternatives" that
are evaluated and weighed, with a fuzzy logic
approach, calculating a truth value for each of them
and choosing the one with the greatest weight (of
course only if it exceeds a certain truth value).
The rules can also use environment variables to
take into account the state of the system and to
contextualize the choices. These rules can be
conditioned (in the calculation of the value of truth)
by the feedback returned by any processing
components.
The "Plan" component is used to schedule the
execution of actions, in the predefined sequence
defined by the selected rule and controls the
outcomes of any action.
The actions are performed using the "Execute"
component that interfaces various "effector" to
manage the internal services execution, the new
applicative features, the feedback and any replies to
be sent to user.
5 INDUSTRIAL APPLICATIONS
In addition to the use cases developed as part of the
research projects mentioned above, the intervention
strategy described in this work was being applied (at
different levels) in various industrial projects and in
particular for two projects addressed respectively to
ICEIS 2011 - 13th International Conference on Enterprise Information Systems
360