[Embedlets-dev] [Arch] re; Device polling

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

Chris responds to Brill:

> This is the classical 'who has control' discussion that goes on in any
> architecture. My recomendation would be to break the pieces down to a
> little lower level so that you have fine-grain, descrete functional blocks
> that can provide both functional requirements:

> This also gives you the flexibility to have local independent loops that
> run at different rates if that is a requirement. You (the Embedlet user)
> gets to determine who is in control! You (the Embedlet designer) do no
> have to accommodate multiple, mutually exclusive requirements.

I have to side with Chris on this.  Creating a JAPL interface layer that does 
device-level protocol neutralization and provides a solid generic interface to 
arbitrary devices is challenging enough.  Then there will be the task of 
providing JAPL interfaces for the large quantity of unique hardware devices 
out there.  KISS principle would seem to be a wise way to go for the JAPL 
layer, just due to the size of the core task.

If you try to subsume things like polling timer services (which will drag event 
management and a lot of the rest) into the device interface layer, it will 
complicate that layer immensely and result in too much coupling between the 
device and application (Embedlet) code.  Embedlets are the natural place for 
that kind of service, would provide a clean split of responsibility.

Let JAPL expose a common device interface.  But let the Embedlets determine 
how/when that interface should be invoked. Clean....simple...decoupled.  

This approach has some other key benefits.  JAPL interfaces stay simple and 
could be used by other embedded Java solutions (for example, hardcoded 
solutions that don't use an Embedlet container).  It also allows Embedlets to 
use non-JAPL enabled devices easily, yet still leverage common services like 
Timer/Events as needed.  Embedlets will also be configured using XML 
syntax, so that is a logical place to put things like timing requirements (how 
often to poll a device).  Keep in mind that Timers will also be used for other 
purposes (eg. sending a status update to a remote enterprise system on a 
periodic basis, Management services, etc), not just for device polling.

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