[Embedlets-developer] Re: Embedlet comments

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

 From Ted:

> It is my opinion that if we are able to bring a
>  simple,  platform-independent, snap together component
>  market to the embedded space that it will be a huge
>  success.

I agree with you, but to be successful you need lots of pre-built components 
first.  That requires standard interfaces/contracts and a Container specification 
(and some implementations for common platforms, PC/JStamp/uVM/etc) first.

If you do the design of the Container and component contracts well, with a 
solid XML configuration vocabulary, then layering a sexy graphical UI on top of 
that is pretty easy.  However, many components and even more funcational 
embedlets (with application logic in them) will need to be built using classic 
Java development techniques first. Bit of a chicken and egg scenario there.

Designing a container and the contracts it needs (eg. interfaces, lifecycles, 
etc.) that will eventually support this vision is a non-trivial task, especially since 
it needs a lot of flexibility to handle the wide range of platform capabilities and 
constraints that we are targeting.

>  I do not personally have any problems with the XMLDOM route
>  but my primary goal is a huge market of Embedded Components
>  that can be graphically wired together by a 'Component
>  Assembler' class of application developer.  

I believe that the design of the Outpost container/component architecture will 
be the critical piece of the technology puzzle here, with a graphical UI being 
some nice sex/sizzle for later.

Many people have tried to float graphical assembly tools....but for the most 
part they have not succeeded (JavaBeans are a good example of this).  Most 
real-world problems require custom logic....which is where the graphical 
assemblers break down.  And trying to create a graphical programming 
language is probably not going to succeed in the short term.  Look at how all 
the current containers work....all XML-based config files....nary a graphical 
assembly tool anywhere to be seen, though these might start to appear as the 
configs stabilize, container best practices solidify and the configs get complex 
enough to warrant such tools

As for DOM....it won't ever fly on an embedded platform.  Too much memory 
overhead in instantiating the XML parse tree.  On embedded platforms, event 
based (SAX) XML parsing makes much more sense.  For the construction 
tool, that builds the glue that binds the container/components from the XML 
config, almost any XML parser can be used, since that process would likely be 
done on a more capable box (like a PC).

> Yes, flowchart based programming has been around for years,
>  but the killer idea here is that the Embedlet standard can
>  allow a *huge* market for platform-independent, reusable,
>  pre-serialized embedded components to be created.  The new
>  XML based long term persistence format makes this feasible
>  now.

I'm not convinced that a JavaBeans approach with serialized instances is 
really that valuable.  It hasn't succeeded in the more classic Java space.  What 
seems to have garnered favour and market share is writing code to a 
container spec (eg. servlets, embedlets, EJBs) and specifying the "instances" 
that need to be created in an XML config file instead.

The argument for a huge market for serialized components never materialized 
in the Java world....so I am quite skeptical that it will do so (at least in the 
shorter term) in the embedded world.  More likely that an Embedlet Container 
approach that is reminiscent of Servlet (and other) containers would gain 
traction and usage a lot faster.

>  The Component market is the 'holy grail'.  The wiring tool
>  is just a support technology for this market.

That's what they said about J2EE (and EJBs), and about JavaBeans before 
that...but it hasn't really materialized.  How would the embedded space be 
different?

> So, I propose VPL (Virtual Peripheral Library) as the
>  official name.  What does everyone think?

For what pieces of the Outpost/Embedlet puzzle?

I see device drivers (or virtual peripheral drivers) as just special cases of an 
"embedlet".  One that may need regular polling (or a separate thread of 
execution where supported), and that would primarily produce Embedlet 
Events that are lower level/hardware oriented (eg. bit values, streams, etc), 
but might respond to control events as well.

It may make sense to distinguish "embedlets" which contain application logic, 
from "device drivers" that sit next to the hardware.  But there is some overlap, 
if you use the Event model to glue the two together (with the Event 
Management provided by the container itself).

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