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

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

> My take on this is that this is more a pitch to push high end
> hardware. Even if a truck full of tags were to move past a reader, the

This is more real then pitch I can assure you.

- james

ra...@pr... wrote:
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
> 
> 
> 
> 
>>Ramesh wrote:
>>
>>
>>>Given that each tag doesnt represent too much data,
>>>the traffic may notbe toomuch. Say if each tag holds
>>>1k data, then even 1000 tags willgenerate only abt 1MB.
>>
>>Here is the link to SUN's new RFID website:
>>http://wwws.sun.com/software/solutions/auto_id
>>
>>The 'Architecture' document contained there indicates how much work
>>they had to do in order to accommodate reading large numbers of tags
>>in a short span of time.  One important aspect of this new
>>architecture is that the Savant servers are really high-powered
>>embedded systems that are deployed near the RFID readers.
> 
> 
> My take on this is that this is more a pitch to push high end
> hardware. 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 teh worries (yet) is
> teh lareg number fo hits.
> 
> Even if we were to assume that the scan problem is resolved, the
> software problem is still not too big. The key is to have the scanner
> (or the system to which it is connected- say a savant node) have
> abilities to store in real-time all "hits" it gets. And allow other
> systems to query the scanner to get teh "hits" it presently has. (Kind
> of what the savant servers are meant to do).
> 
> I dont believe this will require large hardware. (But this remains to
> be seen!).
> 
> 
>>One implication of this is that what use to be a J2EE application
>>that was located completely in the backend infrastructure is now an
>>application that is partially located in the backend infrastructure
>>and partially distributed throughout the facility in embedded
>>devices.
>>
>>The process of how the J2EE community is going to accommodate this
>>new class of application is one of the things that is most
>>interesting to me.
> 
> 
> This has to evolve. But one key piece of integration I see is to treat
> each "scan" as an "event" and have a pre-defined biz processing manage
> the event. Event would be a tag "scanned" at a given "scanner". Could
> be refined further to even a tag of a given "type" scanned at a given
> "scanner". Examples of "given scanner" could be the scanner at a
> check-out counter, or scanner at a loading-dock, or scanner on a
> shipping converyor belt, so on.
> 
> The key is that there may be some realtimne processing involved. Say,
> the system may need to notify security at shipping to allow the truck
> to pass. if the truck had a few thousand "hits", the server will need
> to process all of them. But then again, this problem could be as
> simple as firing a few DB queries for each "hit" to verify that the
> part was meantto move out. Now, if there were 5000 tags in teh truck,
> and 4 queries are needed for each tag- then a total of 20,000 DB
> queries may be needed. Even at 5ms per qry (I can get a PK based
> simple qry to exec at this speed on a decent desktop), this is a
> cumulative time of 100 seconds. Given that DB accesses from middletier
> are verymuch parallelizable, in an app-server, atleast 10 queries
> could be fired in parallel (on a low end server). So this brings the
> total processing timeto about 10 seconds.
> 
> In short, with asimple solution to process a truck leaving shipping,
> where all tags are verified against soem shipping reference to ensure
> that right product is leaving the warehouse, it will take under 10 sec
> to process this- using low end servers.
> 
> 
>>>One key aspect here would be to ensure that there is
>>>some intervening infrastructure piece that sits in
>>>the middle to provide a pure J2EE abstraction to the devices.
>>>[snip]
>>
>>I am looking forward to seeing what kind of architecture ideas you
>>are sketching out.
> 
> 
> Am having a pilot project underway within my company to try out some
> approaches. Am sure other companies are doing the same. But the key is
> to separate the realtime processing (to register a "scan") from the 
> actual biz-processing tier- thru the 'intervening infrastructure
> piece'. As discussed earlier  in this note, this could be specifiable-
> what scan shd trigger what processing.
> 
> 
>>>Guess one key aspect here is to identify biz cases where the
>>>devices intergate into core biz applications. (This would
>>>also be the key for getting budgetary approvals). Assuming
>>>there is a biz case, then the main challenge will be to
>>>integrate the two domains- devices/embeddedworld
>>
>>It has been my experience that one of the challenges encountered
>>(usually before the device integration challenge is encountered) is
>>in figuring out how to even begin discussing this new class of
>>application at the business case level.  This is completely new
>>territory for most people and, for the most part, they do not even
>>know how where to start because there is no past experience to guide
>>them.  One the reasons that this group has been working to figure
>>out what the best-practice patterns in this space are is to help out
>>with this problem
> 
> 
> As I mentioned earlier (above), the key is to enable "wiring" the biz
> logic. In very simple terms, the fact remains that each "scan" must be
> processed. The scan could be a scan when a "move" occurred, or a
> repeat-scan on a stationary object occured. Every move must be
> processed. Stationary repeat-scans are used to query where a given tag
> currently is. With these abstractions, a simple enabling software
> layer can be easly put together.
> 
> 
>>I am beginning to think that it would be an interesting idea to
>>partner with a J2EE community like 'The Server Side' to set up a
>>pilot program where developers can start experimenting with these
>>new technologies.  I think that us Embedded Java developers would be
>>able to put together some experimental hardware system specs and
>>embedded software if we could find some J2EE-based organizations who
>>would be willing to deploy them and start experimenting with the
>>J2EE code needed to accommodate them.
> 
> 
> 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?
> 
> Cheers,
> Ramesh
> 
> 
> 
>>
>>Ted
> 
> 
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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_id56&alloc_id438&opclick
> _______________________________________________
> 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