Re: [Embedlets-dev] Interested in sharing a J2EE perspective

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

Ramesh wrote:

>Ted Kosan asked if I could participate in the deliberations and present a J2EE

>angle to the technology.

First off, thank you for taking the time to add a J2EE perspective to this
discussion, it is much appreciated :-)

I think that a good way to begin is with some background information.  This
group consists mostly of Embedded Java developers and it was started in
November of 2002 for the purpose of discovering what the best-practice
strategies are for allowing J2EE to automatically monitor and control all
aspects of an enterprise using Internet-connected embedded systems.  One of the
ideas that sparked this discussion was the "sensor to boardroom" vision that
Sun has been talking about for the past few years and what technologies,
architectures and patterns would be needed in order to actually make the vision
a reality.

The initial pattern that we came up with is what we call the 'Wide Fanout'
pattern and it consists of hundreds (or even thousands) of Internet-connected
embedded devices situated anywhere on a company's intranet and feeding measured
data into the company's backend systems.  These devices can consist of anything
from RFID and SmartCard readers to almost any kind of sensor or actuator that
one can think of ( as an aside, just last week I started consulting for a
railroad mfg. company that is interesting in starting to leverage the new RFID
devices and readers that have recently become available and one of the issues
that immediately came up was how to manage the flow of data that the devices
will be generating).


Here are some of the issues related to this problem that we think have a solid
handle on:

1) The Internet-connected embedded devices needed to do the actual monitoring
and control are now available and some of the members on this list are vendors
of some of these devices ( for example, http://systronix.com  and 
http://muvium.com ).   

2) The primary business mechanisms that most companies will be using to
determine which aspects of an organization need to be automatically monitored
and controlled at any given time are process improvement methodologies like
6-Sigma, TQM, Lean Manufacturing, TOC, etc.  

(One example of this is about a year and a half ago I spent 4 months consulting
at a GE aircraft engine test facility in Ohio and one of the primary process
improvement projects they were working on was automatically monitoring the
location and state of each engine as is made its way through the facility.  6
Sigma workgroups were where all of these process measurement decisions took
place.  Another example is a Liebert plant that I visited recently where they
want to automatically monitor each part as is routed through their powder
coating department.)

3) The class of employee who is typically responsible for configuring,
deploying and maintaining any Internet-connected process monitoring devices are
the IT support personnel who are usually not programmers and who may or may not
have an intimate understanding of the facility's intranet design.

4) One of the primary barriers that is going to be an impediment to
implementing the "sensor to boardroom" vision going forward is the vast
cultural differences that exist between the embedded systems developer
community and the enterprise/computer science developer community ( see
http://www.javadevices.org/javadevices/resources/images/venn_diagram_large.png
).

We are just now approaching the point where a widespread interest is starting
to build for allowing a company's backend enterprise systems to automatically
monitor and control its internal process using the company's intranet.  It
appears that most people are not aware of this potential cultural
communications problem yet but, if it is real, they soon will be.




Now for the fun part ;-)  Here are some of the issues related to this problem
that we currently view as unknowns:

1) How many Internet-connected embedded devices is a typical J2EE system able
to handle and at what load levels?  Are the bottlenecks going to be the
embedded devices themselves, the network, the presentation layer, the business
logic layer or the database layer?  (For example, I studied Sun's new RFID
reference implementation white paper recently and they needed to develop a
special architecture in order to accommodate the massive amounts of data that
large groups RFID tags are capable of generating into the network as these
groups are moved past a given reader).

2) What are going to be the best-practice protocols that will be used to
communicate between these Internet-connected embedded devices and the J2EE
system?

3) J2EE developers currently have 100% control over any web applications that
they develop but it is unlikely that J2EE developers will be personally
configuring, deploying and managing these new Internet-connected embedded
devices on a company's intranet.  As indicated above, IT support personnel will
most likely be doing this job.  This new scenario entails splitting the
responsibility/control for this class of application between the J2EE
developers and the IT support personnel which has not been encountered before. 
What are the best-practice strategies for handling this new scenario?

4)  As things stand right now, almost no one in the traditional embedded
systems community has any idea what a J2EE application server is nor even what
the function of an enterprise system is in general.  Conversely, almost no J2EE
developers have ever had their hands on any type of embedded systems and, at
best, most only have a vague idea of what their capabilities are.  Before the
"sensor to boardroom" vision can be realized these two communities will somehow
need to be brought closer together.

With respect to the J2EE developer community, what might be some promising ways
to raise its level of awareness with regards to this issue?  Once the awareness
level is raised, what are some workable strategies for enabling J2EE developers
that are interested in moving into this new and promising area of monitoring
and controlling the physical world to start gaining some experience with these
technologies?




I know that this has been somewhat of a large amount of information to relay
all at one time but these are some of the main issues that this group has been
working on for over a year now.

Don't feel like you need to comment on everything that has been listed above
but we would appreciate hearing your perspective on any parts of it that you
find especially interesting.


Thanks,

Ted Kosan

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html