Jonathan,
>The
>resulting design can be simpler, because it does not require all the
>possible combinations and sequences of incoming events to be
specified, as
>would be required in a conventional programming approach."
I don't get it. I don't see a difference here between event driven
and conventional programming. If the events are discrete then
combination and sequence is irrelevent -- ergo requirements are the
same. For more complex logical events where combination or
sequencing is important then all possible paths would still have to
specified - ergo requirements are the same.
>During IPROF's VPLUS SIG, we were debating the Event based vs.
Procedural
>based paradigm.
My recollection, as one of the participants in that exchange, is the
'debate' consisted of one statement and a quick rebuttal.
Cortlandt Wilson
Cortlandt Software
www.cortsoft.com (MANMAN 3rd party Resources site)
(650) 966-8555
Jonathan van den Berg wrote in message ...
>Hello Tony, and list members,
>
>I listen, everyday, about the use of middleware to connect clients to
>servers, interface to databases, connect shared resources. Recently I
was
>reviewing some research from a friend of mine, Richard Pawson, who
leads the
>CSC Foundations Research Group, and came across this paragraph.
>
>Richard writes: "Instead of having programs that run periodically,
and
>execute a pre-determined process (branching and looping when
appropriate),
>the system is divided into independent chunks of code that fire or
trigger
>immediately in response to specific events - which may be
externally
>sensed, or internally generated. One obvious advantage for these
type of
>systems is speed of response; another is parallelism - responding
to
>multiple events (of the same, or different kinds) in parallel. The
>resulting design can be simpler, because it does not require all the
>possible combinations and sequences of incoming events to be
specified, as
>would be required in a conventional programming approach."
>
>During IPROF's VPLUS SIG, we were debating the Event based vs.
Procedural
>based paradigm. After reading the above paragraph, I just couldn't
resist
>sharing it. The biggest issue driving the demand for looser coupling
is
>business agility: the recognition that a system that is optimized to
>today's requirements may be very difficult to adapt to future needs.
Rather
>than trying to eliminate the joints between systems, we should be
>consciously trying to build in more joints, so that the pieces can be
more
>easily separated and re-formed in future.
>
>Cheers,
>
>Jonathan van den Berg
>Premier Software Technologies
>fon: 408-257-8757
>fax: 408-253-1184
>www: www.premiersoft.com
>
|