On Tuesday 27 April 2004 09:15, hammett wrote:
> > JBoss uses JGroups which was referenced earlier in this trail - it might
> > have been lost in all the <snips/>.
>
> Haven't heard of that... Sounds cool! Did you try it already?
I have quietly followed this thread, to see where it leads.
I would like to describe the System Fault Tolerance system that I am planning
to put into place with the help of Merlin.
Some 'types' of systems lends themself to easier SFT than others. Most people
here, I guess, works with Transaction Oriented systems (most common in
'business systems') and tends to talk about stateful and stateless entities.
I have not done enough work in this area to provide any useful insights.
However in DataFlow Oriented systems (which is what I normally work with) I
use a distinction between "Signal" and "Parameter", and I have concluded that
a completely transparent SFT layer can be introduced without the support of
the components in such systems.
A "Signal" is 'stateless' in that it is re-generatable, and continously
updated, whereas "Parameter" is a persisted (stateful) transaction-like
entity. "Parameters" controls the Signal flow in whatever way the system is
designed.
Example;
+------+ +-----+ +------+ +---+ +-----+ +------+
|Sensor| --> |Scale| --> |Filter| --> |PID| --> |Scale| --> |Output|
+------+ +-----+ +------+ +---+ +-----+ +------+
In words; a Sensor component sends events of measurements, connected to a
Scale component that translates the measured value to engineering units. The
output event from the Scale componentgoes to a Filter component, that
'cleans' the values and limits the number of further events (if the change
was very small it doesn't need to be propogated), the chain may then be
connected to a PID regulator that tries to keep the measured value to a
certain pressure, and its output goes to another Scale component, then onto
some form of Output component.
This is a Data Flow solution and above is the Signal Chain.
Each component then has a set of "Parameters" which can either be modified
manually, by transaction-oriented code or signals.
+----------------+
input x >----->| Linear Scale |-----> output f(x)
| f(x) = k*x + m |
+----------------+
^ ^
Parameters | |
========== | |
k-factor >--------+ |
|
m-factor >--------------+
Ok, that was the introduction of Data Flow Oriented systems.
To achieve System-Fault Tolerance in this we need to automatically create a
clone of each component, and wire it like;
+----------------+
+--------------->| Linear Scale |-----> out prime
| | f(x) = k*x + m |
| +----------------+
| ^ ^
| Parameters | |
| ========== | |
in>-+ k-factor ---------+ |
| | |
| m-factor ---------------+
| | |
| | |
| v v
| +----------------+
+--------------->| Linear Scale |-----> out secondary
| f(x) = k*x + m |
+----------------+
"out prime" is wired to the next component in the signal chain, whereas the
"out secondary" is the standby.
The trick is to detect when the 'prime' has died, in which case the system has
to "re-wire" the "out secondary" as "out prime" and connect it to all the
"in"s.
The system would also need to make a new instance of the component on another
node, and then make that the "secondary".
Let's look at the "wire".
+-------+ wire +--------+
| Scale |----------->| Filter |
+-------+ +--------+
The "wire" is most easily implemented in Java by JavaBean styled Events. But
as JINI quickly figured out, it is not suitable to have JavaBeans events in a
distributed environment, so _I_ concluded that the 'better way' was to
encapsulate the whole 'wire' concept into a small subsystem.
+-----------------+ +-----------+ +---------------+
| Wire StartPoint |--->| Transport |-->| Wire EndPoint |
+-----------------+ +-----------+ +---------------+
This would give us a caller chain (standard Java method calls), of;
+-----+ +----------+ +---------+ +--------+ +------+
|Scale|-->|StartPoint|-->|Transport|-->|EndPoint|-->|Filter|
+-----+ +----------+ +---------+ +--------+ +------+
If we then assume that the "StartPoint" and "EndPoint" is really only an
interface;
+---+
| S | +---+
| t | | E |
| a | | n |
+-------+ | r |-----------+ | d |--------+
| Scale |-->| t | Transport |-->| P | Filter |
+-------+ | P |-----------+ | o |--------+
| o | | i |
| i | | n |
| n | | t |
| t | +---+
+---+
We can quickly see that the StartPoint and EndPoint could be the same
interface, hence the transport could either be remote for distributed or
local direct wiring for efficiency.
JavaBeans is no longer the best way to handle this!
Instead, Merlin wires the component 'directly', and the "Wire" (of some type)
is just a standard Service.
What?
YES! Standard Merlin assembly can handle the "wiring".
Furthermore, the "Interceptor Chain" pattern discussed elsewhere, will be
leverage to create the inter-JVM transport connectivity, and the component
cloning will be created using Merlin's Facility concept, where components can
be instantiated on-the-fly.
Although these thoughts are somewhat far from what many developers here are
used to, I hope some inspiration can come out of it, particularly the
discovery that Merlin's Assembly can often (always?) replace the JavaBeans
Event pattern, and provide both an efficient and a lot more flexible solution
to decoupling.
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
