Re: [Embedlets-dev] Re: Bridging JAPL and Embedlets

[Ted K. <tk...@ya...>]

Andrzej,

>Also Embedlets are controlled by the Container (ref: Inversion of 
>Control architectural design principle).  If you let the JAPL 
>layer do callback directly into the Embedlet you have bypassed 
>the Container control mechanisms which could be a "very bad thing".  
>The container implementation may be enforcing prioritization 
>through the event queues, and by bypassing this with a direct 
>callback you may compromise realtime deterministic response 
>guarantees.  Also a container implementation may choose to 
>use a dedicated thread per Embedlet....and calling into the 
>Embedlet using the JAPL thread could easily cause problems.

Ok, this explanation is finally hitting home with me!  I think that I can gain
some mental traction with this issue if we discuss it in the context of
threads.



>There are a number of good reasons for using the "mediatory/proxy" 
>class to bridge the two worlds of JAPL and Embedlets....

I like the I/O Mediator idea but now I have the following question about it:

I assume it is ok to allow Embedlets to have direct references to these
mediators?  If so then how does the following scenario work?  The IOMediator
has just received a callback event from a JAPL peripheral that it has a
reference to and concurrently one of the Embedlets that has a reference to the
IOMediator invokes one of its methods.  Have we not just moved the two-threads
problem referenced above out of the Embedlet and into the IOMediator?

As I look back on the experimenting that I had been doing with Robocode I had
actually placed an Embedlet into the IOMediator role and had it do all of the
I/O semantic level - application semantic level impedance matching within
itself.  It was my intent that callback events received from the JAPL device
would be converted into the appropriate Embedlet Event and then submitted to
the Embedlet Event system.  The only thing that the JAPL's callback thread
would be responsible for was doing this conversion and submission.

Any data that needed to be sent to the JAPL peripheral from other Embedlets
would need to be sent as Embedlet events that the Mediator Embedlet would
receive and then translate into method calls on the JAPL peripheral.  I was not
planning on placing any application logic inside of this Mediator Embedlet at
all.

If I can clearly understand how the IOMediator solves the two-threads problem I
think I can embrace it with no reservations.



>I hope this long description and examples help. 

Oh yes, very much so!  And when people start asking us tough questions during
our JavaOne and Embedded Systems conference presentations, these explanations
will definitely come in handy too!  ;-)

Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://platinum.yahoo.com