Re: [Embedlets-dev] Re: Bridging JAPL and Embedlets
Status: Alpha
Brought to you by:
tkosan
|
From: Ted K. <tk...@ya...> - 2003-04-01 08:19:27
|
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 |