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

[James T. <Jam...@Su...>]

Agreed Ted! Very much so in fact.

Being of the "JXTA frame of mind," we have the opportunity to *securely*
(underscore securely) interconnect all things, big and small, to a much
larger degree then was possible a few short years ago.

Having been on the original "team of two" that helped bring Tomcat to the
free world I have a keen interest/sense in what a J2EE model would look
like in a vastly distributed world ... but it isn't here yet. So, let's
get our heads together and simply deal with the facts.

note: there are some *low* level JXTA api's in the next release that
should make this all the more understandable.

- james

Ted Kosan wrote:
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
> 
> 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
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer

-- 
Java == platform independence
XML  == application independence
JXTA == network independence

Secure End-to-End Computing