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

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

Very nicely stated Ted.

This does, however, require a dynamic configuration interface on the
container/embedlet side!

A static configuration system would involve:

1. Set up your wiring diagram
2. Compile/process - embedlet code generation???
3. Deploy code with vendors' tools
4. Test with a JMX compliant tool
5. Repeat if not correct

Very cumbersome and time consuming.

I do see great value in a JAR like packaging system. Very clean, consistent
and self contained.


> Topic tags:[AR][GW][DO][HW][PM]
> _______________________________________________
>
> 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
>
>
> -------------------------------------------------------
> 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
>