[Embedlets-developer] Re: Design Criteria

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

Ted mentioned (in a private email that he said I could respond to on the list):

> Here are a few design criteria that I was working under as
> I was exploring the Embedlet event mechanism:
> 
> - Must allow pre-compiled and pre-serialized software
> components (Embedlets) to be graphically wired together
> using a wiring tool.

I'm not against this approach, but am very skeptical of the value of Graphical 
Programming/Construction tools.  Java IDE's attempted to do just that, but real 
world problems tend to get complex quite quickly, and graphical tools with 
code generation never managed to step up to the challenges.

I have a vision of an Embedlet system where the embedlets themselves can 
include some reasonably complex logic (kind of like servlets in concept).  I 
don't see these Embedlets being developed using graphical tools, since the 
logic that can be specified with such soon gets to be more complex and more 
trouble than just coding it in Java.  Developers would create embedlets using 
normal Java programming tools.  This approach would also apply to the 
creation of device drivers that embedlets could use to control/interface with 
real hardware devices (such as PLC's for instance).

The Outpost container would provide a number of facilities and component 
services that the embedlets could use.  Logging, Management, External 
Communications, Events and such.

The "glue" where you configure the container, all the device drivers and 
embedlets (components) and standard services, including how they all 
interact, dependencies and such, would be done using an XML config file, 
again similar to how servlets and EJB's work these days, and how their 
respective containers are config'ed (Tomcat, JBoss, WebLogic, etc.)

This XML config is likely to not be as simple as James might want, simply 
because configuration is rather complex as are the applications that users 
might want to create built on the Outpost framework.  Though it should be 
simpler than something like Tomcat or JBoss's XML config.

For more capable processors (eg. PC's with a JVM) the container could 
dynamically read the config at startup and use dynamic proxies and other 
techniques to instantiate the "application.  On less capable processors, there 
would have to be a "code generator" that would read the XML config and then 
generate the "glue" code statically, which would then be compiled into a self-
contained Outpost application (container and components) that could actually 
run on the embedded device.  Basically, there would not be a single Outpost 
Container implementation.  Outpost would be a collection of specs, interfaces 
and utility classes that would have differing implementations for platforms of 
differing capability.  Though the embedlet/device driver code should be 
common, the deployment of the final application would be different.  It's the 
only way I see to be able to address the wide spectrum of target processor 
capabilities (uVM to TINI to JStamp to PC, etc.). 

At some point, if someone wants to build a graphical UI that will generate the 
XML config files, that's fine and dandy.  But I don't think it should drive the 
architecture of the container, since that will place artificial limits on the 
container that will likely translate into roadblocks to usage of Outpost in the 
real world.  

I thought our goal was to make the integration of outlying devices (some quite 
intelligent with some serious capability, eg. JStamps) with the back office 
Enterprise systems (J2EE/.NET/etc) much easier, and especially to get the 
server-side/corporate Java developers more comfortable with embedded 
development.  Inventing a Graphical programming paradigm will probably not 
do that (though it might be nice to have of course).....having a good container 
architecture, some core services, that will allow Java programmers to write 
embedded code quickly (eg. by using familiar container concepts as already in 
existance with Servlets et al) will achieve these goals.

> - Must run on systems as small as a TINI (and perhaps even
> a uvm).

Agreed.  But PLC's?  I think those are too limited in their functionality to 
include at this stage. (Note: I'm using the classic definition of a PLC here...not 
that of a generic u-processor.  I don't think anything smaller than a high end 
PIC running uVM should be targetted).

> - Can not use dynamic event proxies.

Sure!  Why not?  The Outpost specs should be independent of whether the 
implementation of an Outpost-compliant container can support dynamic 
proxies or not (see comments above on how that might work).  Some Outpost 
implementations may well be able to support such advanced features (I see 
threading, dynamic classloading and the like as similar features, that if 
available, should be useable, but not mandatory).

James's comments on the "standards" that are evolving in the embedded 
device arena are well taken.  But the bulk of these so-called "standards" are in 
reality just proposals.  A true standard is in wide deployment (eg. TCP/IP is a 
standard, WS-Security is not), and none of these are.  I thought our intention 
was to make Outpost and Embedlets the defacto, open-source standard for 
such things.  The fact that there are similar efforts out there (some of a 
proprietary nature, something I wish to strongly avoid) just validates our 
direction and market opportunity.




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