embedlets-developer

[Andrzej J. T. <an...@ch...>]

One of the challenges I see, regarding Graphical Wiring, is the fact that the 
Embedlet container uses a dynamic, event-driven paradigm which borrows 
from pub/sub messaging techniques (albeit in a lightweight manner).

What this means is that there really are no fixed "connections" or "wires" 
between embedlets, per se.  Everything is mediated by the Event Manager, 
which manages the queues and forwards produced events to registered 
consumers dynamically at runtime.

When an developer creates an embedlet (or service or adapter)  they will 
specify what event types the embedlet consumes and/or produces in the 
embedlet.xml config file (see latest Arch Disc Doc v1.4 for a more detailed 
discussion on this, in the appendix on Lifecycle dependency management).  

What this means is the container (or the Wiring tool) will know what the event 
inputs and outputs are when you drop an Embedlet on the wiring board.  Now 
if you drop another Embedlet on the board, it will know what it 
produces/consumes too.

That is sufficient information (in many cases) for the Graphical Wiring tool (or 
the Event Manager in a container) to automatically "wire" the two together.  If 
one embedlet produces Events of type A and another consumes Events of 
type A, then the tool can automagically draw the line between the two 
embedlets.  There would be no need for the user to manually draw such a 
connection.

A complication arises if an Embedlet only wants to receive (or send) events of 
a particular type to a specific Embedlet (or collection of Embedlets) rather than 
all consumers of that particular event type.  Then the user employing the 
Wiring Tool would have to place restrictions on which embedlets would receive 
the events.  For instance, they could delete "wires" that they didn't want.  

This implies, however, that our Event Manager has some more complicated 
"matching" capability that can be employed by Embedlets so that you don't just 
register as a consumer of a particular type of event, but that type PLUS some 
specific properties (sender/receiver name, value, etc.) in the event itself.  This 
is not a big deal from an EM Service implementation perspective (though we 
need to walk a fine line with how "fancy" we get on the conditions, at least for 
the intial incarnations).

But it does raise some questions on how you visually specify these additional 
conditions in a Graphical tool (or maybe you do it with a pulldown tab/window 
rather than using visual wiring metaphors)?  For instance...do you draw all the 
"connections" based only on event type (and no other conditions) and then 
allow the user to modify/delete those they don't want?  Or do you start with no 
connections and only add the ones you want?  

One of the beauties of pub/sub is the publisher usually doesn't care who is 
getting the events (decoupled messages), which defines "filtering" from the 
perspective of the consumer only (all the producer does is "tag" the message 
with properties that consumers might want to use for filtering purposes).  This 
provides for a very dynamic, self-configurable, and easily extensible 
environment (eg. to add logging of a particular event type, you just drop in a 
logging Embedlet that registers interest in receiving that particular event, and 
the producer neither cares nor knows that a new consumer was added). But 
there are situations (maybe for security reasons) that the producer might want 
to specify what consumers are eligible to receive a particular event.  Or maybe 
we'll need filtering at both consumer and producer ends.

I'm sure there are some other ways of doing this besides just the approaches 
I've listed above, but regardless, the visual metaphors to support the 
underlying event/messaging concepts (whichever ones we choose to 
implement) are not always as intuitively obvious as those for a fixed 
connection situation.

Get that GW thinking cap on, Ted!  It'll keep ya warm till the power comes 
back on! ;-)



Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com