1. Introduction
We start our blogging 'career' with one simple idea. That, in presenting or writing an article
We start our blogging 'career' with one simple idea. That, in presenting or writing an article
about any kind of Java-based distributed system, an information often lacking in the tutorials
which I come across is a 'beautiful' architecture diagram clearly pointing out the set of
participants; at least runtime participants.
2. Software Participants
Distributed systems are usually modeled by graph-theoretic means into nodes and edges. It
is these nodes that are the participants exchanging 'messages'. In a typical presentation of a
Java-based software system, it is rarely the case that the most important participants be listed
or presented in a unified diagram right from the beginning. We advocate a diagram-first
approach that presents a top-view of the system and its main protagonists (i.e. participants).
If this is the first thing that a developer encounters, il will serve as a mental hook upon which
to register the details of the presentation. By contrast, classical or dominant presentation adopt
(rather unconsciously perhaps), a 'Syntax-First' approach; there often seems to be a rush to
show the first fragments of relevant configuration or the 'hottest' annotations to use. This is a
'parachuting' presentation. The developer is parachuted into the technology without telling him
how he found himself at that point of the coding space.
3. Hidden Software Participants
In today's complex distributed systems, these are just too many threads, too many listeners, too
many interceptors, and quite a few 'implicit' steps which participate in the successful operation
of a runnig distributed Java-based architecture. It's simply impossible to list every potential
participant both visible and 'implicit'. We shall call these 'implicit' participants, hidden participants.
The idea is to bear in mind, when drawing an introductory architecture diagram, the existence
of these hidden participants, and to make intelligent choices as to which should be revealed to
the developer. Personally, I often found it useful when Message-Driven-Beans (MDBs) are
explained, that the application server's JMS broker be explicitly mentioned and given due 'respect'.
Any software professional with little experience in message-oriented systems, can leave with a very partial understanding of MDBs if no mention is ever given to the application server's part in the functioning of the whole JMS setup.
2. Software Participants
Distributed systems are usually modeled by graph-theoretic means into nodes and edges. It
is these nodes that are the participants exchanging 'messages'. In a typical presentation of a
Java-based software system, it is rarely the case that the most important participants be listed
or presented in a unified diagram right from the beginning. We advocate a diagram-first
approach that presents a top-view of the system and its main protagonists (i.e. participants).
If this is the first thing that a developer encounters, il will serve as a mental hook upon which
to register the details of the presentation. By contrast, classical or dominant presentation adopt
(rather unconsciously perhaps), a 'Syntax-First' approach; there often seems to be a rush to
show the first fragments of relevant configuration or the 'hottest' annotations to use. This is a
'parachuting' presentation. The developer is parachuted into the technology without telling him
how he found himself at that point of the coding space.
3. Hidden Software Participants
In today's complex distributed systems, these are just too many threads, too many listeners, too
many interceptors, and quite a few 'implicit' steps which participate in the successful operation
of a runnig distributed Java-based architecture. It's simply impossible to list every potential
participant both visible and 'implicit'. We shall call these 'implicit' participants, hidden participants.
The idea is to bear in mind, when drawing an introductory architecture diagram, the existence
of these hidden participants, and to make intelligent choices as to which should be revealed to
the developer. Personally, I often found it useful when Message-Driven-Beans (MDBs) are
explained, that the application server's JMS broker be explicitly mentioned and given due 'respect'.
Any software professional with little experience in message-oriented systems, can leave with a very partial understanding of MDBs if no mention is ever given to the application server's part in the functioning of the whole JMS setup.
No comments:
Post a Comment