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

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

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 that 
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 Java
> 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 prove 
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 that
> 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 is
> 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 “how do
> 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?”  And the ruthless answer is “Not very much”.  TINIs 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 commercial
> success.

Agreed.
 
> The primary reason for this is that Enterprise Java developers have no
> where near the background needed to successfully deal with the Embedded
> 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 primarily
> enterprise developers (including enterprise Java developers) is a flawed
> 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 and 
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 framework.

What capabilities do Embedlets offer an
> Enterprise Java developer that normal Embedded Java does not offer them?

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 popular.
 
> Answer: “Not much”.  Again, TINIs have been around for over 3 years 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.  And 
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/transport 
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 see 
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 instrumentation 
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 normal
> 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 the 
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 components 
(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 “most likely *initial* target market
> for graphically wired Embedlets” 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 for
> 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ïve users will be able to wire?

> To say that Embedlets are only *for* solving problems in the enterprise
> space is just as suspect as Sun stating that Java was only *for* solving
> 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 what 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 what
> 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 is
> growing at a snails pace and so it is going to be small for a very long
> time.

See above comments.  I think I've addressed this.

> So, after working extremely hard for years to increase the size of the
> 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 wildly
> 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 very
> 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 them
> 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 Embedlets
> 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 wiring
> capabilities, and then marketing these capabilities to any and all markets
> that could potentially use them, is *equally* as important for Embedlets
> 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 they 
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 to 
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