RE: [Embedlets-dev] Re: JAPL Events

[Christopher S. <cs...@oo...>]

________________________________________
>
> >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
>
>
That is correct, but only as a JAPLListener. This maintains the decoupling
as Andrzej has pointed out.


> 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
>
>
>
>
> -------------------------------------------------------
> 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
>