[Embedlets-dev] Re: JAPL part of specification

[Andrzej J. T. <an...@ch...>]

Brill asks:

I thought that JAPL was going to be a separate specification, since it 
would/might have applicability outside of an Embedlet container?

> So... what I need to understand is how Outpost would be setting and getting
> attributes of a peripheral?

An Embedlet would have a reference to the JAPL device and would use whatever 
API the JAPL device exposed to set/get any attributes the device had exposed.

> > Can you give a bit more information about the idea behind these Type IDs?

Embedlet Event Types are just a string, which is tokens separated by periods. 
Something like my.event.id.  or device.id.eventtype.  The first token should 
not be emb or outpost, and don't use *'s in the type (those are used for 
pattern matching), other than that, no real restrictions.

> I started Piccadilly (what I'm calling the Outpost/JAPL combo) by extending
> Embedlet... the methods are fairly easy to understand.

You should not need to (and I feel shouldn't anyway) extend Embedlet to 
support JAPL devices.  See below.

> What I don't understand is how the embeled talks to the JAPL device.
> What is looked like, extending Embedlet is that the embedlet receives events
> from the system... now I assumed that I would do something different depending
> on the event code.

Assuming that the JAPL stuff is intended to be independent of the Embedlet 
container (something we talked about a long time ago), here is the way I 
think you should consider linking the two:

1) Create your JAPL drivers with an exposed API.  The JAPL device should NOT 
have a reference to any Embedlets, nor be dependent on ANYTHING in the 
embedlet spec (eg. no imports of org.embedlet or org.outpost packages).

2) Create an Embedlet (application logic that wishes to use a JAPL device) 
that receives Embedlet Events that will originate from a JAPL device somehow. 
The Embedlet can have a reference to the JAPL device if it needs it (or it 
can be passed in as part of the Embedlet Event it receives) so that it can 
make calls against the exposed API of the JAPL device.

3) Create a "proxy" wrapper for the JAPL driver that extends 
org.embedlet.EventProducer and which takes JAPL events (interrupts) and then 
creates/sends an appropriate Embedlet Event.  Note that this wrapper does NOT 
extend Embedlet (it doesn't have to), just EventProducer and that the JAPL 
driver can have a reference to the wrapper (if needed) for interrupt driver 
events (in which case the wrapper should implement a callback interface 
defined as part of the JAPL device API for such callbacks). The JAPL wrapper 
should NOT have a reference to any Embedlets.  All this wrapper does is 
convert internal JAPL information into an Embedlet Event, acting as a 
"bridge" between the two worlds.

A polling scenario doesn't need the wrapper (an Embedlet would use the Timer 
Service to poll the JAPL device), so let's look at an interrupt driven JAPL 
device.  Here is what the flow would look like:

1) JAPL device gets an interrupt.
2) JAPL device does a callback into the JAPL "Proxy" Wrapper.
3) The wrapper takes the interrupt data, puts in in an Embedlet Event and 
sends it (note: it does not know who the consumers are going to be).
4) An Embedlet (registered as a consumer for that particular event type) 
receives the event and then does something with it (possibly issuing JAPL API 
calls against the originating device, setting/getting attributes).

This approach follows best practices (per my earlier email), and is preferred 
for the following reasons:

1) Coupling between the Embedlet and JAPL layers is reduced (and kept uni-
directional, from Embedlet to JAPL only).

2) The use of a wrapper class means JAPL code can be used without change 
outside of the Embedlet Container environment (a good thing).

Make sense?  Do I need to write an example to show you how this is intended 
to be implemented?

Anyone else out there?  Gregg?  Chris?  You guys got any opinions?

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com