Andrzej,
Most of the issues in this post that deal with the graphical wiring together of
software components I responded to in earlier posts so I guess there is no need
to repeat them here.
>
> > 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?
From the research I have done on JavaBeans it appears to me that the two things
that killed its potential for creating a large component market was 1) the lack
of a robust method for long term persistence of object graphs and 2) an event
mechanism that was not general enough to allow an extremely wide range of
software components to be easily wired together. Number 1 has already been
solved and I think we have an excellent shot at solving number 2.
As for EJBs, it seems to me that doing enterprise Java development right is so
complex that highly skilled Java programmers are absolutely needed in order to
'knit' everything together. If even the Java developers can not agree on
fundamental things like whether Container Managed Persistence or Bean Managed
Persistence is the best persistence mechanism to use then, to me, this is an
indicator that EJBs are not yet mature enough to support non-programmer
application assemblers.
The Embedlet space is looking like it is significantly simpler than the EJB
space and the more I work on a solution to the elevator problem the more I am
convinced that Embedlets have a real shot of being the first Java software
component technology to create a large and successful component market.
> > 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).
Over the past few weeks JAPL has been developed to solve the device drivers
problem.
Here is the simple Embedlet application again:
http://embedlets.sourceforge.net/devdocs/diagrams/embedlets_v.05.jpg
Could you draw up a model of the same application that uses an alternative to
JAPL to solve the device driver problem?
Ted
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
|
