RE: [Embedlets-dev] [Arch] Management of embedlets

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

>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
>
> > IMO our embedlet architecture as it is now, is a little too much like a
> > servlet architecture, and I don't think it fits the environment
> as well as
> > it should.
> > I think it would be far better to do things the other way
> around, so that
> > the outpost device was sent its configuration, and then sent
> its data back
> > out to it's "listeners", similar to a subscriber pattern. This
> would mean
> > that the embedded devices could do their work in their own time
> frame, as
> > fast as they can reasonably do it, while not getting tied up servicing a
> > single request.
>
> In the current architecture the 'real-time' components are JAPL
> components.
> In my imagining, JAPL components which are very much like, if not exactly
> like, cork components will likely have Event driven orientation. I think
> embedlets are subscribers to JAPL components which have event
> generators for
> which Embedlets are listeners for sure. In this way all real-time
> is handled
> by the container and the real-time features of the platform.
>
> Again though, the embedlet implementation may use no JAPL
> components at all!
> It may simply be a logic configuration and not be a real-time system.
>

This is true. A possible application for embedlets is in multi-processor
distributed computing where an array of JVM's each run a small set of
identical embedlets to perform matrix operations. This would create a low
power, low cost, high density super-computer with inherent near-neighbor
communication.

Pretty exciting when you think about it!

> James Caska
> http://www.muvium.com
> 'Java Bred for Embedded'
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> > -----Original Message-----
> > From: emb...@li...
> > [mailto:emb...@li...]On Behalf Of
> > Brill Pappin
> > Sent: Tuesday, February 11, 2003 5:46 AM
> > To: emb...@li...
> > Subject: Re: [Embedlets-dev] [Arch] Management of embedlets
> >
> >
> > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> > _______________________________________________
> >
> > > > I'd narrow that down a little I think... for the most part
> an Embedlet
> > > > would be talking to/gathering data from a single device, so
> maybe the
> > > > embedlet should be a singleton... also helps reduce load on
> > the embedded
> > > > environment by not trying to do to much at once.
> > >
> > > I don't see any reason why we should limit an Embedlet to talk to one
> > device,
> > > arbitrarily.  As for singletons...in a threaded system, you
> > wouldn't even
> > have
> >
> > I disagree with that, singeltons have their place in any
> > development... most
> > useful when you wnat to make sure an environment has only one
> > instance copy
> > regardless of how the implementation runs. I see it as good programming
> > pratice to protect the areas of code that need it, against
> poorly written
> > implementations.
> > IMO never depend on 3rd parties to do your work for you ;)
> >
> > > > For instance, on the physical level in Cork, only one device can be
> > > > talking over I2C at any one time, so the underlying code
> > allows the bus
> > to
> > > > be "locked" for any other requests, it also takes the
> addresses of the
> > > > available devices into account because you can't have more
> > than one with
> > > > the same address (in certain circumstances you can, but in
> > that case it
> > > > would be the same device as far as the software was concerned).
> > >
> > > Assuming it's a polled device, the Timer Service would create
> a periodic
> > event,
> > > which an Embedlet would be listening for.  The Container
> would then call
> > the
> > > embedlet's event processing method with the timer event.  The embedlet

> > > would lock the bus, poll the device, unlock the bus, possibly do some
> > other
> > > processing (send a device-specific event based on the value
> it got) and
> > would
> > > exit.
> >
> > I think you have to be careful here, as not all external devices return
> > immediatly... for instance a 1-Wire net with a heavy wieght and
> > radius could
> > take several seconds to properly search, which is an eternatiy in
> > electronics. I2C is much faster, but till may take several hunbred
> > milliseconds depending on the device (the Devantech SRF08 will
> > take from 70
> > to 100ms to return a single ping).
> >
> > > > Anyway, I don't think its really required that the embedlets
> > behave that
> > > > way, as the container can do the work of requesting data as
> needed...
> > > > however the embedlet should take into account that the container can
> > only
> > > > do things one at a time (for the most part). Anyway, quick,
> > low traffic
> > > > requests are important here.
> > >
> > > Not sure what you mean by this.  The Container only manages
> > Embedlets....it
> > > would not be it's responsibility to talk to a JAPL/Cork interface.
> > (Separation of
> > > Concerns).  The only time a physical device and Container would
> > interact,
> > > would be in the case of an interrupt drive device.  When the interrupt
> > came in
> > > the JAPL code would use a static Container method to get a
> handle to the
> > > Event Service, so it could post an Embedlet Event into the queue.
> >
> > What I was thinking is that the container could to all the
> talking in the
> > background to lower level stuff, and make the data availible to
> > the embedlet
> > when it needed it... or the embedlet could request some
> specific data from
> > the underlaying code (or the container) and receive a callback
> > whent he data
> > was actually delivered.
> >
> > > > The other option of course is to dump the data elsewhere (into a DB
> > maybe)
> > > > and allow the embedlet to redirect requests, or be used only for
> > outgoing
> > > > transmission (and not service requests on its own).
> > >
> > > Not necessary (and DB's won't typically be available on an embedded
> > device).
> > > The event queues effectively provide the capability you need (for
> > transient
> > > storage and linkage between a device, Embedlet and Container, but in a
> > > decoupled manner).
> >
> > I agree, although I think it important that the device not have
> to respond
> > to the embedlet in the embedlets timeframe. so everything must
> be loosely
> > coupled so that the underlying system is not tied up  trying to
> service a
> > single embedlet request, at the expense of all else it must do
> for normal
> > operation.
> >
> > IMO our embedlet architecture as it is now, is a little too much like a
> > servlet architecture, and I don't think it fits the environment
> as well as
> > it should.
> > I think it would be far better to do things the other way
> around, so that
> > the outpost device was sent its configuration, and then sent
> its data back
> > out to it's "listeners", similar to a subscriber pattern. This
> would mean
> > that the embedded devices could do their work in their own time
> frame, as
> > fast as they can reasonably do it, while not getting tied up servicing a
> > single request. This is somewhat how I thought it was to work, but I'm
> > getting the idea recently that every request is polled from the outpost
> > device... which will work up to a limited weight, but is a fairly
> > significant point of failure as the outpost network grows (which is the
> > problem we're attempting to solve here).
> >
> > - Brill Pappin
> >
> >
> >
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> > http://www.vasoftware.com
> > _______________________________________________
> > Embedlets-developer mailing list
> > Emb...@li...
> > https://lists.sourceforge.net/lists/listinfo/embedlets-developer
> >
> >
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer