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

[<ra...@pr...>]

Hi Ted,

About the pitch for for pushing hardware, was referring to Sun's paper
citing performance issues (referred to in an earlier mail). Surely
Savant is a neat concept. Enables easier adoption of rfid based
solutions by clearly separating out the devices from the enterprise
applications.

Three more points below...

> 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.

Agree. These intermediaries will be the interface for the Enterprise
apps. Need to evolve the models here. As I said earlier, A J2EE aware
layer must be built. That can further declaratively enable wiring
various events with the required biz processing.


>
> 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
> ;-)

As Greg pointed out in his post, believe handling of individual
outposts is probably not a serious challenge. Also, with the Savant
servers in place, it is quite likely that each savant server will have
multiple devices connected. Will act as concentrators as well.


>
>
>> 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.

We could explore this. I can also bring this up with TSS (know Floyd).
But for this to be effective, the kit must include good simulators- so
one can explore without actually needing any tags or readers.

Cheers,
Ramesh


>
>
> Ted
>