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

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

> 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=20
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