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

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

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

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