embedlets-developer

[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

[Embedlets-developer] Re: Design Criteria

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

Andrzej,

> > 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 had an interest in Graphical Software Component wiring since attending
Mark Davidson's JavaBeans session at JavaOne 2000.  Mark Davidson is the
JavaBeans technical lead at Sun and over the years I have had the opportunity
to ask him what went wrong with the original JavaBeans vision and how this
could be fixed.

He said that one of the primary problems was that when JavaBeans first came out
there was not a good long term persistence mechanism available for it and
without this capability a market for JavaBeans components could not be made. 
JavaStudio and the original BeanBuilder graphically wired together JavaBeans
very well but without being able to persist the object graphs that were created
the approach was doomed.

The early IDE vendors worked around this problem by dynamic code generation but
this is a relatively poor and unreliable way to solve the JavaBeans
configuration and wiring problem. 

The new Long Term Persistence API has solved the persistence problem but after
the initial failure most people seem to have forgotten that JavaBeans were
originally designed as a general purpose software component technology capable
of supporting a large software component market for people that wanted to
graphically wire applications together.  Beyond this, with EJBs and the
enterprise market taking off like it did there were little resources or desire
to pursue the original JavaBeans vision.

Mark and some other people as Sun have been working hard over the years to come
through on JavaBeans's early promise and now they have the new BeanBuilder tool
that demonstrates that the JavaBeans idea as originally envisioned works.  I
think that the opportunity to bring this technology to existing IDEs would be a
tough sell but the Embedded Java space is just now taking off and I think that
this technology could be very successful here.

Here is Mark's Software Component Assembly manifesto:

http://tkosan.javadevices.org/misc/embeddedjava/manifesto.html

The new BeanBuilder tool is open source and I would like to use it as the
foundation for the initial proof-of-concept Embedlet Wiring tool.



> 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.  

We are in complete agreement here.  The Embedlets themselves will often be very
complex and so they will probably be developed in Java by skilled Java
programmers.  The graphical wiring capabilities are just for allowing
non-programmer application assemblers to assemble applications using standard
software components (Embedlets).



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

I agree that the container could offer standard services but I think that the
services should be pluggable so that if one wanted to put a minimal service
Embedlet Container in a uVM it could be easily done.



> 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.)

I think that we will need to discuss this point further.  I think that if a
non-programmer application assembler is developing an Embedlet based
application then they should be able to do so by directly wiring the
application together using a graphic wiring tool (which is a technique that has
been proven to work well by JavaStudio and the various versions of the
BeanBuilder).

But I agree with you in that I do not want to *force* people to only use a
graphic wiring tool to develop Embedlet applications.  For experienced Java
programmers I think that your deployment via an XML configuration file is an
excellent idea that has also been proven to work well in a number of
situations.

I do not see why we can not provide both mechanisms especially since they seem
to be complementary.



> 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.

So far the experience I have had with developing a solution to the elevator
problem indicates that quite complex applications can be assembled by
graphically configuring components and wiring them together.  I hope to have my
solution available for critiquing within 2 weeks so that we can see if I am
missing something critical.



> 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.  

The route that the wiring tool is taking is to allow the application to be
graphically wired together and then the application's complete object graph is
saved using the LTP API and then also deserialized into the embedded system.  I
have already successfully deserialized small applications into a TINI as a
proof of concept (it worked well) and I think that this technique will work
with the uVM too.



>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.). 

I think that we should definitively prove that one Embedlet specification is
incapable of spanning the full spectrum of target environments before falling
back on multiple specifications.  I currently think that one specification will
be sufficient.



> 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 think that, just like with security, if the graphical wiring capability is
not built in from day one that it can not be successfully be tacked on
afterwards.  In order to accommodate graphic wiring, Embedlets simply need to
permit their properties to be configured using setters and getters (achieved
mostly through naming conventions) and they need to allow for the registering,
unregistering and handling of events.  They should suffer no more than normal
JavaBeans have by being able to be using in a graphic wiring tool.



> 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.  

With JAPL, Embedlets can handle all possible 'peripherals' from simple devices
to the most complex backend system.  Again, this is shown in the following
simple Embedlet application (notice that it is hooked up to a backend
enterprise system):

http://embedlets.sourceforge.net/devdocs/diagrams/embedlets_v.05.jpg

My primary goal is not to get enterprise developers more comfortable with
embedded development.  My goal is to allow the semi-technical IT personnel
which are present in most companies to be able to graphically wire together
Embedded systems and attach them to backend enterprise systems with minimal
help from the the enterprise developers.

My thought was that the $25/hour IT personnel should not have to bother the
$100/hour enterprise personnel more often than was absolutely necessary in
order to attach the eventually large number of embedded systems that companies
will eventually need to be hooking to their enterprise systems.

In my scheme, the enterprise developers are primarily used as a 'back door'
method for marketing the Outpost idea to companies.  Even though some of them
might catch the embedded systems bug, I think that most of them will not have
the necessary background for interfacing embedded systems to their company's
processes.

Without graphic wiring capabilities Embedlets are not usable by my pet target
user base.



> > - 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).  

I spent a significant amount of time digging into the dynamic proxy API and it
will only run on JDK 1.3 and up APIs.  Numerous classes in the API were
enhanced to accommodate dynamic proxies (like the serialization API) and almost
no embedded Java system are going to have these capabilities in the near
future.

The good news is that the main reason that dynamic proxies are needed is
because of all the listener types that Java's event mechanism uses like
ActionListeners, WindowListeners, etc, etc,.  So far my research has indicated
that Embedlets will work fine with just *one* event listener:

public interface EventReceiver //All Embedlets implement this interface.
{
   receiveEmbedletEvent(EmbedletEvent ee);
}

Since all Embedlets that need to receive events implement one interface there
is no need for dynamic event proxies.  Simply have an Embedlet register itself
as an event listener for a specific type of EmbedletEvent on any given target
Embedlet and thats it.  It is so simple that it will easily fit even on uVM.



Ted

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