[Embedlets-dev] Re: [GW] 'specification' and 'live wiring' modes.

[Ted K. <tk...@ya...>]

Andrzej,

>I envisioned the Wiring tool as just being responsible 
>for the specification of how an Outpost application was 
>wired together (which embedlets, device drivers/JAPLs, 
>adapters), and would simply generate the XML Config file 
>declaration that represents this wiring.  Then it would 
>only call the regular(non-graphical) build process upon 
>request (which might be an ANT build, but that is just 
>calling a java process like almost any other).

My vision for the Wiring Tool is for it to be able to do everything you have
laid out here because I agree that they are important to the project.  I will
call this the Wiring Tool's 'specification' mode.

But I also want it to go beyond these capabilities.  The Wiring Tool will have
a mode where it will host a live Embedlet Container and as Embedlets are
dragged from a pallet and dropped into the container they are instantiated and
completely functional.  I will call this the Wiring Tool's 'live wiring' mode.

In live wiring mode, the JAPL pallet will contain a selection of JAPL
peripherals on it that can be dropped into the wiring area and then attached to
the sides of the Embedlet Container just as you have shown in the Architecture
document.  These JAPL interfaces can then be implemented by simulated I/O
modules (which are wired to the implementation side of the JAPL peripheral) or
by physical PnP modules that are attached to the workstation.

As the Embedlet based application is wired together, its functionality can be
continuously tested by sending live events to the Embedlets using a dialog in
the Wiring Tool or by triggering the simulated JAPL I/O module or by triggering
the physical I/O module.  I also think that perhaps something like JUnit tests
could also be generated for both sides of the JAPL interfaces so that the
application can be continuously tested from outside the Embedlet container and
the I/O modules could be tested from the inside.  

The ID tags on the I/O modules can also be read or configured at this time so
that when the I/O circuit is detached from the workstation and moved over to
the target embedded system the application has already had its bindings made
with the I/O modules.

The application is manipulated until it is running as desired.  No compilation
occurs during this process and none is needed because all of the Embedlets used
in this mode have already been pre-compiled.

At this point one has a complete Embedlet object graph that is configured and
wired together as desired and all of the configuration file information that
can be specified in specification mode already exists in this live object
graph.  One now has the following choices that can be made:

1) Have all of the configuration files for all of the Embedlets and JAPL
peripherals automatically generated from this object graph.  This can be done
by either  a) analyzing the object graph in memory and converting it into the
XML configuration file formats or by  b) using the Long Term Persistence API to
serialize the object graph into an XML file format which can then be used to
generate the needed XML files.

2) The object graph represents the application exactly as we want to have it
running on the target system so we serialize this object graph, send it to the
target system using whatever method method is appropriate and then deserialize
it into the target system's Embedlet Container.  Of course, each Embedlet's
.class file will also need to be sent to the target system but I am hoping that
something like a BAR file could accommodate not only .class files and other
needed resources, but a serialized object graph if desired too.  TINI/TStik
already have deserialization capabilities and I have tested this idea on a TINI
and it works just fine.  As soon as Ajile releases their CDC implementation
JStamp/JStik will have deserialization capabilities too.  James has said that
muivum could also accomodate this technique if needed.


The reason that I like the idea of leveraging Ant is that operations that would
have been built into the Wiring Tool (and thus dependent on it) could be moved
into Ant.  For example, the generation of Embedlet configuration files from a
serialized object graph could be done in Ant so that this operation can be used
by the Wiring Tool and by any other entity that is capable of using Ant.


So again, I am committed to giving the Wiring Tool a specification mode that
will operate any way you and others think is appropriate for generating
Embedlet configuration files but I am going to attempt to give the Wiring Tool
a live wiring mode too.


Ted


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com