RE: [Embedlets-developer] Re: Wiring tool versus Container Infrastructure: WE NEED BOTH!

[James C. <ca...@vi...>]

>Chicken and egg syndrome Ted.

I have called it 'build it and they will come' syndrome in the past. We
ignore the fact that one of the key reasons java took off in the first pl=
ace
is that SUN! provided a vast quantity of packages that solved hard proble=
ms
for java developers.

I would argue that it is the packages that made java not the language. Su=
n
built the packages.

Here we are in the situation where there are literally thousands of devic=
es
drivers for cork to write and thousands of embedlets to use that drivers =
via
JAPL or whatever and all this needs to happen before a wiring app can 'wi=
re
them together' without requiring someone to write and embedlet or even
harder a JAPL device driver.

I would argue that at the moment C has a bigger library than Java in
embedded which is why it dominants. Almost nothing to do with the languag=
e.

Java however has the advantage that its library can go further.. ie it is
inherintly more re-useable than C. The issue is that the C libraries are
80/20 libraries so are hard to slay.

James Caska
http://www.muvium.com
'Java Bred for Embedded'





> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of
> Andrzej Jan Taramina
> Sent: Sunday, February 02, 2003 10:49 AM
> To: emb...@li...
> Cc: tk...@ya...
> Subject: [Embedlets-developer] Re: Wiring tool versus Container
> Infrastructure: WE NEED BOTH!
>
>
> Ted rants about his pet Graphic Wiring tool:
>
> > Assertion 1: Without graphic assembly capabilities, Embedlets
> *don't* have
> > a market.
>
> I don't agree...but DO agree that a Graphic Wiring tool would expand th=
at
> market and would be a very valuable thing to have.
>
> > Reason 1)  The only market that Embedlets *without* graphic wiring
> > capabilities can be targeted toward is *Embedded* Java programmers.  =
So
> > how many of us are there?  Lets check the numbers on the Embedded Jav=
a
> > lists:
> >
> > JStamp list - 333 members.
> > JStik list - 64 members.
> > TStamp_TStik list - 100 members.
> > TINI list - estimated < 2000 members.
>
> How about all the MIDP/CLDC/CDC etc Java programmers, who could easily
> use Embedlets to write embedded code?  There are more of those than in
> your total of all of the above.
>
> How about Java programmers in general?  There are hundreds of thousands
> of them (more than C/C++ programmers according to surveys over a
> year old).
> They could also easily write embedded code given the right
> infrastructure and
> tools.
>
> Lies, Damn Lies and Statistics, Ted.  You can shape the numbers to prov=
e
> anything you want.  And I can do the same to refute your stats
> with my own.
>
> > Extrapolating from these numbers one can (very generously) estimate t=
hat
> > there are probably <10,000 Embedded Java programmers in the
> whole world at
> > this point in time.
>
> And a solid Container-based architecture, similar to
> Servlets/EJB's/etc, would
> raise that number into the hundreds of thousands that could
> quickly and easily
> learn to write embedded code using Outpost/Embedlets.
>
> > In addition to the existing number of Embedded Java programmers
> being very
> > small ,the rate of new programmers entering the Embedded Java group i=
s
> > equally small (see #3).
>
> Which is why creating an infrastructure that can be easily
> learned, with many
> off the shelf components would increase the number of developers
> capable of
> writing such applications by a few orders of magnitude.
>
> > After looking at these extremely small numbers, one must ask =93how d=
o
> > Embedlets enable this very small and slowly growing group to attain
> > success with Embedded Java that they could not do with just regular
> > Embedded Java?=94  And the ruthless answer is =93Not very much=94.  T=
INIs have
> > been around since 1999.  If Embedded Java was going to succeed in the
> > marketplace using conventional marketing techniques, then TINI
> would have
> > been a commercial success by now.  To date it has not been a commerci=
al
> > success.
>
> Agreed.
>
> > The primary reason for this is that Enterprise Java developers have n=
o
> > where near the background needed to successfully deal with the Embedd=
ed
> > Space and they never will.
>
> I disagree. I believe that a properly designed Outpost Container
> and Embedlet
> solution will be VERY familiar to the Enterprise Java folks, and
> make it easy
> for them to write embedded applications.
>
> > 2) Trying to market Embedlets as a programming technology to primaril=
y
> > enterprise developers (including enterprise Java developers) is a fla=
wed
> > strategy that will fail.
>
> I'm not convinced that it is flawed....but obviously having a
> facility that allows
> non-programmer types to create simple (emphasis on the simple) embedded
> applications would be very beneficial to increasing the size of
> this market.  And
> hence a Graphic Wiring tool is very valuable to have.
>
> But it has to be built on a well architected, slim, fast base
> that provides the
> power and flexibility for developers to write complex embedlets,
> for if they can't
> create packaged, reuseable embedlets your whole argument breaks down.
>
> Chicken and egg syndrome Ted. Your argument holds only if there
> is a large
> selection of pre-built embedlets to choose from.  But developers
> will not write
> such, unless the tools, infrastructure and capability to do such
> exists and is
> familiar enough and easy enough to co-opt the general Java developer
> community into being able to create components (embedlets) with minimal
> training.  And then there will always be applications that
> require custom logic,
> where the problems cannot be solved with off-the-shelf
> components.....so the
> Outpost platform has to be able to handle these situations as well.
>
> We cannot have just a simple solution that makes more complex
> applications
> impossible (eg. a Graphical Tool without the underlying development
> infrastructure).  Obviously, the reverse of having
> powerful/flexible dev tools will
> not help as much if you can't handle the simple cases quickly, easily a=
nd
> cheaply.
>
> However, I do believe that with an appropriate underlying
> architecture, we can
> have our cake and eat it too, by supplying a graphical wiring
> tool that sits on
> top of a modular, lightweight, powerful and flexible container framewor=
k.
>
> What capabilities do Embedlets offer an
> > Enterprise Java developer that normal Embedded Java does not offer th=
em?
>
> One could pose the same question regarding servlet containers
> versus using
> straight Java code.  The key is to simplify the application
> development to focus
> primarily on the business rules/needs rather than on plumbing and
> housekeeping.  That is why container architectures have become so popul=
ar.
>
> > Answer: =93Not much=94.  Again, TINIs have been around for over 3 yea=
rs now
> > and they are very easy to attach to enterprise systems.
>
> Not they're not....you have to home-roll almost all the code to
> do so.  That is
> playing with plumbing rather than focusing on business requirements.  A=
nd
> you have to become an expert in the platform at hand, Tini's in
> your example.
> That is not productive.  The whole Outpost effort, from
> standardizing device
> drivers using JAPL, to reusable embedlets to pluggable protocol/transpo=
rt
> gateways is to reduce the learning curve and promote both code and
> knowledge reuse.
>
> > If Enterprise
> > Java developers were going to take an interest in Embedded Java
> they would
> > have already done so already with TINIs.
>
> I disagree...primarily because I don't think that most
> corporations have had a
> requirement for this level of top to bottom integration with
> monitoring/metrics/control that goes from the lowest
> manufacturing/distribution
> level up to the enterprise planning systems.  I have only started to se=
e
> literature discussing the "Real Time Enterprise" (which will
> drive the need for
> such top to bottom integration) very recently, and I predict that
> this evolution in
> corporate thinking will drive increasing interest in such instrumentati=
on
> capability.  That coupled with the first standardized integration
> technology
> (Web Services, using XML/SOAP) puts us at a very unique point in time,
> where an Embedlet solution might be able to leverage increased
> market share
> and attention.
>
> > Embedlets without Graphic Wiring
> > capabilities do not bring anything significant to the table that norm=
al
> > Embedded Java does not already offer.
>
> I disagree, Ted, for all the reasons I have tried to outline
> above.  Sure...graphic
> wiring will be very useful, and I think we should build it (and build t=
he
> underlying container architecture to support it), but I believe
> the confluence of
> business needs ( the emerging concept of the "Real Time Enterprise),
> common integration standards (web services), the availability of
> Java-based
> embedded systems, and the widespread adoption of container-based and
> java-based solutions will provide a lot of significant benefit
> just from the
> Embedlet/Outpost container itself, with Graphical Wiring adding a
> lot of icing
> on top of that benefit.
>
> > Every piece of my input into the brainstorming process has
> centered around
> > the goal of finding markets for embedded Java through allowing
> > *non-programmers* (this is where 90% of the market is) to
> construct useful
> > embedded system solutions using graphic embedded component assembly
> > techniques.
>
> This has never worked very well.  Programming is the "logical"
> expression of
> business rules and requirements.  Most non-programmers (except
> for trivially
> simple applications) have trouble thinking that logically.  Which
> means that for
> "real world" applications, not only do we need a tool to handle
> the simple stuff
> (graphical wiring)...but also the underlying infrastructure to
> allow professional
> developers to create much more complex applications that will be
> beyond the
> "logical cognitive" abilities of many non-programmers.
>
> We also need a solid platform for the development of Embedlet component=
s
> (and JAPL device drivers, protocol/transport adapters, etc.)
> themselves, since
> the utility of a Graphical Wiring tool will be directly
> proportional to the
> availability of pre-built embedlets, as I had noted above.
>
> We need BOTH Ted!  No-one is arguing against a Graphical Tool...I
> think it's a
> wonderful idea, that will drive much value.  But it will be
> useless without the
> right infrastructure and architecture under the covers.
>
> > I have consistently stated that my =93most likely *initial* target ma=
rket
> > for graphically wired Embedlets=94 were the legion of non-programmer =
IT
> > support personnel who are present in all medium and large size
> companies.
>
> Great....give them a graphical tool with hardly any components to
> wire!  This
> group will never be able to create enough components to make that
> "initial
> target market" viable.  We also have to create a large community of
> component (embedlet) developers that can feed the pre-built components =
to
> this market.  And there is a huge experience base of such
> developers already
> that it makes sense to try and co-opt to the task.....Enterprise
> Java developers
> that know how to develop components for container-based systems.
> It would
> be suicidal to not address this.
>
> > The enterprise Java programmers were primarily a back door strategy f=
or
> > marketing graphically wired embedded systems to these IT personnel.
>
> See above. Chicken and egg syndrome Ted!  Who's going to produce
> all these
> great embedlet components that the na=EFve users will be able to wire?
>
> > To say that Embedlets are only *for* solving problems in the enterpri=
se
> > space is just as suspect as Sun stating that Java was only *for* solv=
ing
> > problems in the Embedded Space in the early 1990s.  Thinking about a
> > technology in terms of what it is *for* is an extremely dangerous and
> > limiting mindset to have.  A much better way to think about any given
> > technology is in terms of what it can *do*.  Show any given group wha=
t a
> > technology can *do* and they will figure out all by themselves
> what to use
> > it *for* in their respective domains.  The best chance that
> Embedlets have
> > of succeeding is for us to show as many diverse groups as possible wh=
at
> > Embedlets can *do* and let them take it from there. (shirky.com).
>
> You still need to pick a business problem and then provide a
> solution.  That is
> the surest way to success.  What it's "for" and what it "does" is
> irrelevant in it's
> impact and attention-getting capability when compared to "what
> problem does
> it solve".  That being said, I do agree with your comment above...
>
> > 3) The size of the Embedded Java programmer group is very small, it i=
s
> > growing at a snails pace and so it is going to be small for a very lo=
ng
> > time.
>
> See above comments.  I think I've addressed this.
>
> > So, after working extremely hard for years to increase the size of th=
e
> > Embedded Java developer pool I can confidently state that it is going=
 to
> > happen *very* slowly and it is going to be an uphill battle every
> > centimeter of the way.  I now know the reasons for this but we
> do not need
> > to go into them here.
>
> One of the goals of Embedlets was to break through this ennui,
> and provide a
> different (yet very familiar and proven) paradigm, to try and
> increase this pool
> substantially.  An embedded container!  This leverages prior art
> and known
> best practices, and has a great chance of succeeding.
>
> > To summarize, Servlets, EJBs, JavaBeans... these technologies are wil=
dly
> > successful because the pool of developers that use them is in the
> > *millions*.
>
> Um....Ted....the first two are wildly successful...but JavaBeans
> have never
> really taken off.  Sorry...but that is the reality of the market.
>  Sure, JavaBeans
> are useful (value objects, etc), but there are virtually no
> applications based
> solely on JavaBeans....almost all such apps are based on
> Container/Component architectures.
>
> > Embedlets without graphic wiring capabilities are going to
> > *fail without question* due to the simple fact that the Embedded Java
> > developer pool is estimated to be < 10,000 and it is growing
> very slowly.
> > Almost anything marketed to a target market that is this small will v=
ery
> > likely fail.
>
> For all the prior reasons, I vehemently disagree.  I think
> embedlets could
> succeed without a graphical wiring tool.  However, I think it
> would be EVEN
> BETTER if we had such a tool, along with a good container
> implementation/standards.
>
> Why the big rant trying to convince us that a Graphical Tool
> would be useful
> and beneficial.  I think we all agree with that...but it's not a
> sufficient condition,
> in and of itself, to guarantee the success of Outpost.  We need
> the underlying
> infrastructure.
>
> And like I said, I really believe we can do both!
>
> > So, Embedlets are
> >
> > - A Camelot 'round table' that allows diverse technologies and
> communities
> > to be brought together for a common purpose.
> >
> > - An airport terminal that allows data from multiple sources to
> be routed
> > to multiple destinations.
> >
> > - A United Nations which allows different languages using diverse
> > protocols to work together to solve mutual problems.
> >
> > - A benevolent Borg which accommodates and assimilates wildly diverse
> > technologies into a collective that can leverage the laws of synergy.
>
> Cute but so general as to be virtually useless. ;-)
>
> Can we talk about HOW we deliver all of the above....in a useable
> form for
> both simple AND complex applications....for embedded application
> development AND embedlet component creation?  We need to address all of
> these if we are to succeed.
>
> > The best chance that Embedlets have to fulfill this roll is by
> providing a
> > way for extremely diverse market segments to be able to easily use th=
em
> > for solving their domain specific problems.  Currently, the
> most promising
> > technology we have for enabling this is graphic assembly of software
> > components (Embedlets).
>
> That is just ONE component of what a successful solution needs.  A good
> one...a useful one...but not sufficient in and of itself.
>
> > Here are some low hanging fruit markets that graphic assembly Embedle=
ts
> > has access to:
> >
> > - PIC programmers (huge group of non-Java developers).
> > - 8051 programmers (huge group non-Java developers).
> > - AVR programmers (huge group of non-Java developers).
> > - PLC programmers (huge group of non-Java developers).
>
> Who could all learn Java extremely quickly, at least enough to
> write code for a
> well designed Outpost Container architecture. To go from C/C++ to
> Java is not
> that hard for most programmers, especially if you have the
> plumbing already
> handled.  And who is going to write the intial embedlets, device
> drivers and
> communications adapters for all these platforms?  You're not
> going to wire
> those at first....
>
> > - Non-Programmer IT personnel (millions of members).
>
> Most of whom can't think logically enough to create applications,
> regardless of
> tool used....at least not for apps that are beyond trivially simple.
>
> > - Lego Mindstorms programmers (huge group of non-Java programmers).
> > - etc.
>
> This would be a great group to co-opt...and get over to use Outpost and
> Embedlets.  I would bet that after doing some simple apps (using
> the Outpost
> Graphical Wiring tool), they would start to experiment with
> creating their own
> embedlet components, custom device drivers, etc.  But we have to
> be careful
> that we do not inadvertently label Outpost/Embedlets as "toy technology=
".
>
> > just simply are not enough of us to directly service this
> combined market
> > by directly programming these solutions ourselves (again, anyone who
> > thinks they can refute this claim will need to show their numbers).
>
> And there are not enough of us (on this list) that can create enough
> components to service this combined market.  WE NEED BOTH!
>
> > As for the assertion that graphic assembly of applications does
> not work,
> > the large Lego Mindstorms user base easily refutes this claim.  It
> > obviously *does* work and is quite *successful* even when
> allowing for the
> > fact that there is still much room for improvement in this area.
>
> And as someone pointed out, this works well for simple
> apps....but soon the
> user discovers that they hit a wall (sooner than you think, which
> is why we
> don't all program using graphical metaphors yet).  And what do
> they do?  They
> dig in and start writing code!  We need to provide a solid
> foundation so that
> when a user has requirements that cannot be met with a wiring tool and
> existing components, they can easily develop their own.
>
> > In conclusion.  I absolutely agree that a well architected Embedlet
> > specification is extremely important to the Embedlets effort.
>
> Whew.....one would never guess from your rant above.
>
> > I also
> > maintain, however, that giving Embedlets state-of-the-art graphic wir=
ing
> > capabilities, and then marketing these capabilities to any and
> all markets
> > that could potentially use them, is *equally* as important for Embedl=
ets
> > to succeed.
>
> I don't buy the "equally", but such a comparison is silly anyway.
>  Who cares.  A
> graphical tool WOULD be very useful and would expand the
> potential market,
> and then lead to a larger pool of embedlet component developers (as the=
y
> evolved past the easy stuff).
>
> So let's build such a graphical tool....on top of the best
> Embedlet Container
> architecture known to man!
>
> And along those lines....stay tuned for the imminent posting of an
> "Outpost/Embedlets Architecture Discussion Document" that is intended t=
o
> foster discussion of an architectural solution that will allow us
> to do both!
>
>
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
>