RE: [Embedlets-dev] Re: JAPL Events

[James C. <ca...@vi...>]

>Let me repeat that:  though the Embedlet can have a reference to the
JAPL 
>device, the JAPL device should NOT have a reference to an Embedlet!

An embedlet should be able to register itself as a listener to a JAPL
event generator


James Caska
www.muvium.com
uVM - 'Java Bred for Embedded'



-----Original Message-----
From: emb...@li...
[mailto:emb...@li...] On Behalf Of
Andrzej Jan Taramina
Sent: Saturday, 29 March 2003 4:56 AM
To: emb...@li...
Cc: tk...@ya...
Subject: [Embedlets-dev] Re: JAPL Events


Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
_______________________________________________

Ted:

Sorry 'bout the delay in replying.  This new contract is keeping me 
pretty busy and I've been too fried in the evenings to do much else.  
Settling in now, so hopefully I can do some embedlet work in my spare 
time.

> In the case of RoboCode, the model is definitely interrupt driven.  In

> addition to this, the RoboCode event objects contain rich semantics 
> that need to be dealt with.  For example, the 
> robocode.ScannedRobotEvent contains these methods:
> 
>     double getBearing()
>     double getBearingRadians()
>     double getDistance()
>     double getEnergy()
>     double getHeading()
>     double getHeadingRadians()
>     double getLife()
>     String getName()

Each interrupt event should be mapped onto an Embedlet event.  Note that

using the User Data area of the Embedlet Event you can just append the 
robocode event, and not have to copy any data around.

> Before I posted my initial question I thought about this one a great 
> deal and what I came up with is that this would require another type 
> of software entity to be added to the Embedlet framework besides a 
> Adapters, Transports and Embedlet.  Before going this route I thought 
> that we should discuss it and probably at least try to solve the
problem another way.

Actually....it doesn't!  If you think about the robocode application,
the 
interrupts should be handled by a JAPL device driver, which in this case

is a robocode "virtual" device.

> Apart from this, it appears that the JAPL peripherals are well suited 
> to use method calls for commands being sent to them and simple 
> callbacks for any interrupts/events that they might generate.

Exactly.  And that robocode JAPL driver should convert the interrupts 
into Embedlet Events before posting them so that upstream Embedlets can 
do their battle planning.

> I am all for going with whatever makes sense here and my thinking so 
> far on this topic is as follows.  The Architecture document already 
> shows Embedlets having direct references to JAPL objects and so far my

> RoboCode experiments confirm that this is a good idea.  If an Embedlet

> has a reference to a JAPL peripheral then it is already closely 
> coupled with it and in my opinion this is not a problem because the 
> JAPL's abstract nature already provides the required level of
decoupling.

That is incorrect Ted!  Just because an Embedlet has a reference to a 
JAPL device does NOT imply that the reverse is OK.  Higher order 
components can have references to lower order (or more detailed, closer 
to the iron) ones.  However, the point of using an Event-driven model is

to avoid the reverse, where more detailed components should not have to 
know about the consumers of the events.

This is very analagous to good programming practice where a subroutine
or 
method should typically have NO knowledge of the caller.  Breaking this 
rule is what leads to tight coupling and inflexible application code.

Let me repeat that:  though the Embedlet can have a reference to the
JAPL 
device, the JAPL device should NOT have a reference to an Embedlet!

Let me put this another way:  if I can figure out a way to prevent JAPL 
devices from getting Embedlet references I will do so in the Outpost 
implementation. ;-)

The JAPL driver should be the interface to the device....in the robocode

example, the code that handles the interrupts.  If higher level 
components need to know about this, then you should post an Embedlet 
Event.

The beauty of doing this using only events (not callbacks) is that later

you can add other event consumers that add new functionality and your 
JAPL code remains blissfully unaware (as it should be) that other 
Embedlets are now consuming the events and performing even more complex 
battle plans.

> The only thing we are missing now is a way for a JAPL peripheral to 
> send asynchronous information back to the Embedlet that has a 
> reference to it and using a simple callback for this purpose seems to 
> solve this problem adequately.

NO!  NO!  NO!]

Have the JAPL peripheral post an Embedlet Event.  You can attach the 
robocode interrupt data to the Embedlet Event...and the Producer ID
let's 
you tie this back to a particular JAPL peripheral (or include a
reference 
to the producing JAPL driver in the event).

That is how components should communicate using the Embedlet standard.  
Using callbacks from lower components to higher ones is against the 
spirit of the Embedlet spec and is also considered a very bad
programming 
practice for the reasons given.

> If there is then a need to propagate this information to the reset of 
> the components in the Embedlet container then the Embedlet that 
> contains the JAPL peripheral can then translate the JAPL event it 
> received into an Embedlet event and send it to the container.

Do this in the JAPL driver.  This gives you more downstream flexibility 
and is the way that Embedlets were supposed to work.

> It is starting to look like there are going to eventually be thousands

> of JAPL peripherals and it is going to be normal for developers to 
> create them 'on-the-fly' just like I am doing with the RoboCode I/O 
> systems. Since most of a developer's effort will probably be focused 
> on the Embedlets anyway it also seems like it might be a good idea to 
> have the JAPL related development be confined to the Embedlets too.

I'm not sure what you mean by that.

> If this line of thinking is followed to its logical conclusion then 
> JAPL peripherals are completely encapsulated inside of Embedlets and 
> showing them attached to the periphery of the Embedlet container is 
> not an accurate depiction.

I disagree.....the whole point of the event model is to allow this 
decoupling.  This way you can write a single embedlet that can manage 
multiple (similar) JAPL devices very easily.  Longer term application 
maintenance and expansion is also facilitated without needing to rewrite

any JAPL driver code if you take my approach from day one.

> I suppose that the 'Embedlets having direct references to JAPL 
> peripherals' model that is shown in the Architecture document is 
> either a good idea or it is not a good idea.

-1:  JAPL drivers having references to Embedlets
+1: Embedlets having references to JAPL devices
-1: Using callbacks from lower order components to higher order ones
+1: Using events to pass stuff from lower order components to higher 
+ones

> If it is a good idea then I do not
> see a problem with completing the connection by allowing the JAPL 
> peripheral to send callbacks to the Embedlet that contains it.

Like I said, if I can figure out a way for the Outpost implementation to

prevent this, I will! ;-)

> If it is
> not a good idea then this implies that Embedlets should not contain 
> direct references to JAPL peripherals at all and then we will need to 
> come up with another way to solve this problem.

Therein lies the fallacy of your approach, Ted.  This is not a symmetric

situation.  A one way reference from Embedlet to JAPL is fine, and in 
fact, was intended to be used all along.  It's the reverse reference
that 
is a bad idea since it breaks encapsulation and couples things too 
tightly.

A calling program can depend on a subroutine/method.  But a 
subroutine/method should not depend on the caller.  Async relationship!

Same with Embedlets versus JAPL drivers.

> At this point I would vote for exploring the callback model and see 
> how it plays.

Don't do it Ted!  Stay away from the dark side.  Do it the "right way".

Use event generation in your JAPL driver.

> Well, am I correct in assuming that the container only instantiates 
> one conventional instance of each Embedlet and that the 
> ComponentContext objects are then used to hold the state of multiple 
> Embedlets?

Nope.  Something I discussed with Chris.  To allow caching of 
ComponentContext data Outpost instantiates an Embedlet object for each 
Embedlet that is needed (unlike servlets).  But that may just be a 
container implementation decision, so may not be consistent across other

Embedlet Container implementations in the future.  

Use Events Ted....stay away from callbacks!

...Andrzej

Chaeron Corporation
http://www.chaeron.com




-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
Embedlets-developer mailing list
Emb...@li...
https://lists.sourceforge.net/lists/listinfo/embedlets-developer