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

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

Ramesh wrote:

> My take on this is that this is more a pitch to push high end
> hardware. 

It is my understanding that the concept for the RFID Savant server was
developed at the original MIT RFID center and this center probably did not have
a need to push high-end hardware?  My impression from Sun's RFID white paper is
that they simply took this core Savant concept and innovated on it.

From my perspective, I view Sun's RFID whitepaper as a huge inflection point
indicator because, up until I read this paper, it was my opinion that the class
of embedded system that would be the first to be widely interfaced to J2EE
backends would be 8-bit Internet-connected systems.  (The Embedlets group has
developed the term "Enterprise Outpost" to describe the class of
Internet-connected embedded system that is specifically designed to interface
with J2EE backend systems.)

Since RFID appears to be the driver that is finally going to force a
J2EE/Embedded Systems marriage, whatever class of embedded system is needed to
run a Savant server is going to be the main class of Internet-connected
embedded system that is going to experience wide adoption on the shop floor.

Since Savant servers require J2SE-level technology to run, it follows that the
class of hardware system needed to host them is standard PC class hardware.

For those of us in the JINI and JXTA communities, this information is like gold
because it means that we will be able to start bringing the full capabilities
of both of these technologies to bear against the formidable problems that
exist on the shop floor.



> Even if a truck full of tags were to move past a reader, the
> challenge today is to accurately scan these tags (I know atleast 2
> large software players in rfid space that have said this is still a
> problem. Even just a small crate moving past a scanner on a conveyor
> belt is a challenge). Given this, the least of the worries (yet) is
> the lareg number fo hits.

I personally do not view the ability to process a large number of tags in a
short time span the primary problem.  I think that competent Java programmers
will be able to solve this problem with the appropriate amount of linear hard
work.

To me the main problem is that the entities which decide where, when and how
many Enterprise Outposts will be deployed in a company (regardless of whether
they are RFID readers or other process monitoring and control computers) are
process improvement committees, not J2EE developers.  For example, Sun uses the
6-Sigma process improvement system and it would be Sun's legion 6-Sigma
committees that would determine this.

My point here is that I can see how linear hard work can design a J2EE/Embedded
System solution that will handle almost any information input rate.  What I can
not see is how a linear solution can solve the problem of thousands of shop
floor data sources and sinks being dynamically added and removed from a
company's Intranet by IT personnel completely apart from the involvement of
J2EE developers.

What kinds of designs can automatically handle these dynamic load changes?  How
can thousands of dynamically-connected Enterprise Outposts be managed by
existing IT personnel?  How can Enterprise Outposts be configured and deployed
by existing IT personnel without the help of the Java developers who designed
them?

These are the bigger-picture problems that keep some of us nights ;-)



> This is a good idea. But not sure how TSS will fit in. TSS is ore a
> discussion forum- so a good place to sound ideas out. But it is not a
> forum where people could try out stuff.
> 
> If anyone has an actual problem they are working on, and can share the
> details without going thru the specifics, we can collectively evolve
> some paradigms. Any takers?

This is what I had in mind.  Most TSS members would not be able to spec-out a
RFID reader, the Internet-connected embedded system to control it and the
software needed to read the tags and send them to a J2EE system.  Members of
the Embedlets group could do this, however, and this could be made available as
an open kit that interested TSS members could just purchase.

This could be done as a TSS experimental project where some of us Embedded Java
developers could provide support for these RFID experimenter's kits so that
interested TSS J2EE developers can start playing with them.  The idea would be
to do this before most people actually had a need for it so that when the need
does arise, people can capitalize on it.


Ted


__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools