embedlets-developer — Outpost Embedlet container developer list

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
>

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

[Gregg G. W. <gr...@sk...>]

>With the advanced transaction, dynamic distributed caching and 
>customization features of the JMX based JBoss.org General Purpose 
>Architecture there is no end ...
>
>With "standard" hardware: 200Mbyte/s fibre channel array (the 
>bottleneck in or calculation cpu oriented versus the I/O oriented 
>mainframe world), 2 dedicated 1GBit direct links,  two 2,8 MHz/2GByte 
>standard PC (P4P800) Oracle 8.7.1 and dynamic on-demand precreated CMP 
>EntityBeans i got around 1000 continous inserts per second. The query 
>time on the optimized _beans_ (m:n ID query) was clearly below 1ms.

I have numbers that indicate this kind of performance is possible.  I just 
asked to see if there was real experience with huge transaction rates that 
didn't work as I think it should.

We're preparing to do some evaluations at this kind of performance level.  It 
will be exciting to see what's possible.
-----
gr...@cy...  (Cyte Technologies Inc)

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

[Gregg G. W. <gr...@sk...>]

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

We've had no problem with this issue as long as we've kept the configuration 
nightmare out of the way.  As I've stated here before, we designed our 
container architecture before J2EE existed, and we avoided configuration for 
everything, by designing systems that adapt, or discover.  We've added 100's 
of devices into systems day and night with zero impact to the existing 
devices.  The systems don't have per device configuration, or automatically 
recognize and configure the system for the new devices if device specific 
configuration is needed.  We haven't used the Jini Surrogate stuff yet, but 
some of the things that we do are similar to the that solution space.  
Eliminatination of IP address configuration is one thing that must be dealt 
with in large scale network deployments. Many small network devices don't 
implement DHCP because of code footprint, or because of the thought that fixed 
IP addresses provide some kind of security :-( The configuration of such 
devices network parameters can be made simple, but it is still an 
administrative step...

Out status monitoring software automatically creates new standard views for 
new devices. As soon as a new device is sending traffic in the system, you can 
search for a device by id and get a list of views to look at.  We typically 
have a status related view that shows communications and general health data, 
and a current 'values' view that shows the data that is important to the 
enterprise.

In our largest system, we have 6000+ views, most of which are generated 
automatically.  Everyone doesn't need to see all of these views.  Views are 
placed into view groups which are assigned access by user groups. Users of the 
system are placed into user groups administratively based on responsibilities.

At these kinds of scales, automation of configuration, or the elimination of it
is a must!

-----
gr...@cy...  (Cyte Technologies Inc)

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

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

[Holger B. - b. <ho...@bi...>]

Am 29.02.2004 um 00:09 schrieb Gregg G. Wonderly:

> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
>
>> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
>> _______________________________________________
>>
>>
>>> 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, what kind of transaction rates are working and what rates are 
> just not
> possible?

With the advanced transaction, dynamic distributed caching and 
customization features of the JMX based JBoss.org General Purpose 
Architecture there is no end ...

With "standard" hardware: 200Mbyte/s fibre channel array (the 
bottleneck in or calculation cpu oriented versus the I/O oriented 
mainframe world), 2 dedicated 1GBit direct links,  two 2,8 MHz/2GByte 
standard PC (P4P800) Oracle 8.7.1 and dynamic on-demand precreated CMP 
EntityBeans i got around 1000 continous inserts per second. The query 
time on the optimized _beans_ (m:n ID query) was clearly below 1ms.

Bottleneck here was the Client request time.

Other approaches for not-allowed mass checking are JMS approaches with 
MQSeries and a dead letter queue for unexpected ID's.

But IMHO checking a 10k bunch of RFID's on one point in the logistical 
chain smells.

just 2ct

bax

>
> -----
> gr...@cy...  (Cyte Technologies Inc)
>
>
>
>
> -------------------------------------------------------
> 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
>

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

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

I do not work directly on this application but my colleagues do. I
have asked them to join in on the discussion ... that said, they are
*really* busy these days.

Please realize that Sun sells a broad spectrum of h/w products so
to pigeon hole reference architectures, products and the like as
motivated primarily to sell high end h/w alone is missing the boat,
pretty much entirely. That and the bulk of the s/w offerings run
on a myriad of h/w and o/s platforms, the deployment choices are
quite broad.

Lastly, some apps are mission and/or life critical and as such the
respective architect should do due diligence is scoping out solutions
and the like and the thusly I assert the drive to "beige box"
everything is, again, likely missing the "bigger picture" boat.

hth,

- james

Gregg G. Wonderly wrote:
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
> 
> 
> 
>>Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
>>_______________________________________________
>>
>>
>>
>>>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, what kind of transaction rates are working and what rates are just not 
> possible?
> 
> -----
> gr...@cy...  (Cyte Technologies Inc)
> 
> 
> 
> 
> -------------------------------------------------------
> 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 

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

[Gregg G. W. <gr...@sk...>]

>Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
>_______________________________________________
>
>
>> 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, what kind of transaction rates are working and what rates are just not 
possible?

-----
gr...@cy...  (Cyte Technologies Inc)

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 

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

[Embedlets-dev] Sun has finally created an Industrial and Embedded Java community

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

Good news.  Sun has finally started an Industrial and Embedded Java community:

http://community.java.net/jddac

I think that this is the kind of support from Sun for Embedded Java that we
have been waiting for.  I am on my way now to sign up for the community.


Ted

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

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

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

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.    

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.



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


 
>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



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.


Ted

  

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

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

[John S. <jsp...@ne...>]

In the world of SECS GEM, where I worked we use a thing called event reports
to recieve data when the equipment wants to send it.  And have of course
programs to interface to the MES.



----- Original Message -----
From: "Gregg G. Wonderly" <gr...@sk...>
To: <emb...@li...>
Sent: Saturday, February 14, 2004 7:22 AM
Subject: Re: [Embedlets-dev] Interested in sharing a J2EE perspective


> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
>
> As I've discussed here before Cyte Technologies has been building device
to
> boardroom systems since 1997.  The issues that Ted brings up are very
real.
> It is important to understand these points and implement solutions,
> communications and strategy messages that work from the bottom of these
> organizations to the top.
>
> Some key issues related to the scalability Ted discussed revolve around
making
> the correct decisions about responsibilities at all levels to minimize
> 'network' traffic and administrative load.
>
> o If a device is able to detect a particular status, it should be
> able to throttle the reporting of that status based on configuration
> and importantance.
>
> o Polling is not a generally scaleable strategy.  At the upper levels of
> the system, you must use report by exception for status data.  A timely
> healthcheck must be included to allow you to determine that the device
> is still operating, and to refresh the world with the 'current' status
> periodically.  Think of the MPEG-4 I-Frame mechanism which allows video
> displays to randomly be inserted into the video stream without having to
> see the very first frame in order to understand what the current display
> should be.
>
> o Data that must be delivered should use an appropriate transactional
> mechanism that allows the data brokers to fail, and for the field devices
> to know what data is still undelivered.  This helps to eliminate large
> scale data recovery which can be impossible to administrate as the number
> of devices reporting data grows large.
>
> o In line with the previous issue, administration of the field devices
> must be automated as much as possible.  Any variant data/configuration
> must have an enterprise wide storage location that can be reached from
> all locations in the system.  Replacement devices can then be
> reconfigured for their installed location in an automated way that
> guarantees they are operating with the correct software and configuration.
>
> Our system was started before J2EE existed and we've continued to use it
> because it is well tuned and instrumented for this type of application.
One
> of our current applications is doing approximately 120,000 transactions
per
> hour against 3 different databases, as well as delivering 40,000+ data and
> status valued events into our system monitoring and control application.
> There are over 1500 end devices being polled by approximately 150 relay
> devices that do the status monitoring and reporting by exception and
required,
> timely data reporting.  The devices are delivering data at a rate of
> approximately 70 packets per second.  There are 2 machines receiving this
> data, each a hot standby for the other.  These machines are running linux,
and
> have load averages < 2.
>
> Our data routing software architecture is a multi-tiered system with
decoupled
> inbound and outbound data delivery using extensive multi-threading.  The
> primary latency that we deal with is database transactions.  We typically
run
> between 5 and 10 threads for each type of data delivery into the
databases.
> This is necessary to help make sure that we keep up with the inbound data
> rates.
>
> Having a well tuned, well maintained enterprise database system is a real
> necessity.  One of our customers is an aluminum melting enterprise.  We
are
> building furnace control systems that include data gathering and remote
> furnace control capabilities.  They have little experienced IT
infrastructure.
>  So, we have to do more hand holding and provide less technical and more
do-it
> documentation to make it possible for them to successfully utilize the
power
> of the systems that we are deploying.
>
> So, everthing that Ted is discussing is not a single persons experience.
> These are many of the primary issues that everyone needs to be aware of.
I'm
> really interested in hearing about other experiences that the J2EE folks
have
> had, and in particular are there common themes present in other types of
> integration applications.
>
> -----
> gr...@cy...  (Cyte Technologies Inc)
>
>
>
>
> -------------------------------------------------------
> 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
>

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

[Gregg G. W. <gr...@sk...>]

As I've discussed here before Cyte Technologies has been building device to 
boardroom systems since 1997.  The issues that Ted brings up are very real.  
It is important to understand these points and implement solutions, 
communications and strategy messages that work from the bottom of these 
organizations to the top.

Some key issues related to the scalability Ted discussed revolve around making 
the correct decisions about responsibilities at all levels to minimize 
'network' traffic and administrative load.

o	If a device is able to detect a particular status, it should be
	able to throttle the reporting of that status based on configuration
	and importantance.

o	Polling is not a generally scaleable strategy.  At the upper levels of
	the system, you must use report by exception for status data.  A timely
	healthcheck must be included to allow you to determine that the device
	is still operating, and to refresh the world with the 'current' status
	periodically.  Think of the MPEG-4 I-Frame mechanism which allows video
	displays to randomly be inserted into the video stream without having to
	see the very first frame in order to understand what the current display
	should be.

o	Data that must be delivered should use an appropriate transactional
	mechanism that allows the data brokers to fail, and for the field devices
	to know what data is still undelivered.  This helps to eliminate large
	scale data recovery which can be impossible to administrate as the number
	of devices reporting data grows large.

o	In line with the previous issue, administration of the field devices
	must be automated as much as possible.  Any variant data/configuration
	must have an enterprise wide storage location that can be reached from
	all locations in the system.  Replacement devices can then be
	reconfigured for their installed location in an automated way that
	guarantees they are operating with the correct software and configuration.

Our system was started before J2EE existed and we've continued to use it 
because it is well tuned and instrumented for this type of application.  One 
of our current applications is doing approximately 120,000 transactions per 
hour against 3 different databases, as well as delivering 40,000+ data and 
status valued events into our system monitoring and control application.  
There are over 1500 end devices being polled by approximately 150 relay 
devices that do the status monitoring and reporting by exception and required, 
timely data reporting.  The devices are delivering data at a rate of 
approximately 70 packets per second.  There are 2 machines receiving this 
data, each a hot standby for the other.  These machines are running linux, and 
have load averages < 2.

Our data routing software architecture is a multi-tiered system with decoupled 
inbound and outbound data delivery using extensive multi-threading.  The 
primary latency that we deal with is database transactions.  We typically run 
between 5 and 10 threads for each type of data delivery into the databases.  
This is necessary to help make sure that we keep up with the inbound data 
rates.

Having a well tuned, well maintained enterprise database system is a real 
necessity.  One of our customers is an aluminum melting enterprise.  We are 
building furnace control systems that include data gathering and remote 
furnace control capabilities.  They have little experienced IT infrastructure. 
 So, we have to do more hand holding and provide less technical and more do-it 
documentation to make it possible for them to successfully utilize the power 
of the systems that we are deploying.

So, everthing that Ted is discussing is not a single persons experience.  
These are many of the primary issues that everyone needs to be aware of.  I'm 
really interested in hearing about other experiences that the J2EE folks have 
had, and in particular are there common themes present in other types of 
integration applications.

-----
gr...@cy...  (Cyte Technologies Inc)

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

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hi,<br>
<br>
Have taken a very first cut responses to teh questions. Just to
stimulate further queries. WIll try and send out a more detailed
Architecture Possibility for integrating Devices into a J2EE Biz App
platform shortly.<br>
<br>
Please see inline comments below. <br>
<br>
Ted Kosan wrote:<br>
<blockquote type="cite"
 cite="mid...@we...">
  <blockquote type="cite">
    <pre wrap="">Ted Kosan asked if I could participate in the deliberations and present a J2EE angle to the technology.

<!----></pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <pre wrap=""><!---->First off, thank you for taking the time to add a J2EE perspective to this
discussion, it is much appreciated :-)

I think that a good way to begin is with some background information.  [...]</pre>
</blockquote>
<blockquote type="cite"
 cite="mid...@we...">
  <pre wrap="">Now for the fun part ;-)  Here are some of the issues related to this problem
that we currently view as unknowns:

1) How many Internet-connected embedded devices is a typical J2EE system able
to handle and at what load levels?  Are the bottlenecks going to be the
embedded devices themselves, the network, the presentation layer, the business
logic layer or the database layer?  (For example, I studied Sun's new RFID
reference implementation white paper recently and they needed to develop a
special architecture in order to accommodate the massive amounts of data that
large groups RFID tags are capable of generating into the network as these
groups are moved past a given reader).</pre>
</blockquote>
Given that each tag doesnt represent too much data, the traffic may not
be too much. Say if each tag holds 1k data, then even 1000 tags will
generate only abt 1MB. But the fact remians that this (amount of tag
movements and teh data generated) has to be factored into the overall
solution sizing.<br>
<br>
<blockquote type="cite"
 cite="mid...@we...">
  <pre wrap="">2) What are going to be the best-practice protocols that will be used to
communicate between these Internet-connected embedded devices and the J2EE
system?</pre>
</blockquote>
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. In any rfid based system,&nbsp; the key event to
process is the tag movements (moved in, moved out). Once thismovement
is captured, then a layer on top can procide the current status- what
is there in which location. The movement in itself is an 'event'. Which
will need to be processed.<br>
<br>
Now, the specific processing involved depends on the biz application
udner consideration. As teh device is an independant resource, there
could be other apps also that are processing the events. So one
architecture option could be to have a J2EE bridge as an infrastructrue
pice, that will detect any movements and accordingly provide a 'j2ee
event' for teh biz layer to process. Teh j2ee event could copnceivably
be a JMS message. Once a j2ee event is generated, then teh biz
processing would be entirely within the J2EE domain (programming wise),
with all complexities of the devices itself well abstracted.<br>
<blockquote type="cite"
 cite="mid...@we...">
  <pre wrap="">

3) J2EE developers currently have 100% control over any web applications that
they develop but it is unlikely that J2EE developers will be personally
configuring, deploying and managing these new Internet-connected embedded
devices on a company's intranet.  As indicated above, IT support personnel will
most likely be doing this job.  This new scenario entails splitting the
responsibility/control for this class of application between the J2EE
developers and the IT support personnel which has not been encountered before. 
What are the best-practice strategies for handling this new scenario?</pre>
</blockquote>
The bridge-approach above will provide the necessary separation from
teh devices domain to the applications domain.<br>
<blockquote type="cite"
 cite="mid...@we...">
  <pre wrap="">

4)  As things stand right now, almost no one in the traditional embedded
systems community has any idea what a J2EE application server is nor even what
the function of an enterprise system is in general.  Conversely, almost no J2EE
developers have ever had their hands on any type of embedded systems and, at
best, most only have a vague idea of what their capabilities are.  Before the
"sensor to boardroom" vision can be realized these two communities will somehow
need to be brought closer together.

With respect to the J2EE developer community, what might be some promising ways
to raise its level of awareness with regards to this issue?  Once the awareness
level is raised, what are some workable strategies for enabling J2EE developers
that are interested in moving into this new and promising area of monitoring
and controlling the physical world to start gaining some experience with these
technologies?

  </pre>
</blockquote>
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/embedded
world <br>
<br>
<blockquote type="cite"
 cite="mid...@we...">
  <pre wrap="">

I know that this has been somewhat of a large amount of information to relay
all at one time but these are some of the main issues that this group has been
working on for over a year now.

Don't feel like you need to comment on everything that has been listed above
but we would appreciate hearing your perspective on any parts of it that you
find especially interesting.

  </pre>
</blockquote>
Will be glad to keep the dialog going. Ultimately organisations look
for solutions to solve their problems. The solutions themsleves will
always be integral (all aspects addressed). To that end any enabling
pieces that can integrate the devices &amp; the application tiers, will
help deliver better solutions.<br>
<br>
Cheers,<br>
Ramesh<br>
<blockquote type="cite"
 cite="mid...@we...">
  <pre wrap="">
Thanks,

Ted Kosan

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
<a class="moz-txt-link-freetext" href="http://taxes.yahoo.com/filing.html">http://taxes.yahoo.com/filing.html</a>


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps &amp; Web services for Linux with
a free DVD software kit from IBM. Click Now!
<a class="moz-txt-link-freetext" href="http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click">http://ads.osdn.com/?ad_id=1356&amp;alloc_id=3438&amp;op=click</a>
_______________________________________________
Embedlets-developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Emb...@li...">Emb...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/embedlets-developer">https://lists.sourceforge.net/lists/listinfo/embedlets-developer</a>
  </pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<table style="width: 95%;" font="arial" size="1" border="0" padding="0">
  <tbody>
    <tr>
      <td style="vertical-align: top; font-family: arial;"><font
 ="arial" size="1">Ramesh <a href="http://www.jroller.com/page/rameshl">
Loganathan</a></font></td>
      <td style="vertical-align: top;"><br>
      </td>
    </tr>
    <tr>
      <td style="font-family: arial; width: 70%;"> <font ="arial"
 size="1">VP,
Engineering&nbsp; <br>
      </font></td>
      <td style="font-family: arial;"> <font ="arial" size="1">Ph:&nbsp;
(+91) 40 341
1672 </font></td>
    </tr>
    <tr>
      <td style="font-family: arial;"> <font ="arial" size="1"><a
 href="http://www.pramati.com">Pramati</a>
Technologies, Hyderabad, India </font></td>
      <td style="font-family: arial;"> <font ="arial" size="1">Cell:(+91)
98 490 42997 </font></td>
    </tr>
    <tr>
      <td style="font-family: arial;"><font ="arial" size="1"><a
 href="http://devportal.pramati.com"><span
 style="text-decoration: underline;">devportal.pramati.com</span></a></font></td>
      <td style="font-family: arial;"><font ="arial" size="1"><a
 href="http://www.jroller.com/page/rameshl">&lt;views&gt;</a></font> </td>
    </tr>
  </tbody>
</table>
:-)
<br>
<font ="arial" size="1">
"Logic is a systematic method of coming to the wrong
conclusion with confidence.." -- Murphy
</font></div>
</body>
</html>

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

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

Ramesh wrote:

>Ted Kosan asked if I could participate in the deliberations and present a J2EE

>angle to the technology.

First off, thank you for taking the time to add a J2EE perspective to this
discussion, it is much appreciated :-)

I think that a good way to begin is with some background information.  This
group consists mostly of Embedded Java developers and it was started in
November of 2002 for the purpose of discovering what the best-practice
strategies are for allowing J2EE to automatically monitor and control all
aspects of an enterprise using Internet-connected embedded systems.  One of the
ideas that sparked this discussion was the "sensor to boardroom" vision that
Sun has been talking about for the past few years and what technologies,
architectures and patterns would be needed in order to actually make the vision
a reality.

The initial pattern that we came up with is what we call the 'Wide Fanout'
pattern and it consists of hundreds (or even thousands) of Internet-connected
embedded devices situated anywhere on a company's intranet and feeding measured
data into the company's backend systems.  These devices can consist of anything
from RFID and SmartCard readers to almost any kind of sensor or actuator that
one can think of ( as an aside, just last week I started consulting for a
railroad mfg. company that is interesting in starting to leverage the new RFID
devices and readers that have recently become available and one of the issues
that immediately came up was how to manage the flow of data that the devices
will be generating).


Here are some of the issues related to this problem that we think have a solid
handle on:

1) The Internet-connected embedded devices needed to do the actual monitoring
and control are now available and some of the members on this list are vendors
of some of these devices ( for example, http://systronix.com  and 
http://muvium.com ).   

2) The primary business mechanisms that most companies will be using to
determine which aspects of an organization need to be automatically monitored
and controlled at any given time are process improvement methodologies like
6-Sigma, TQM, Lean Manufacturing, TOC, etc.  

(One example of this is about a year and a half ago I spent 4 months consulting
at a GE aircraft engine test facility in Ohio and one of the primary process
improvement projects they were working on was automatically monitoring the
location and state of each engine as is made its way through the facility.  6
Sigma workgroups were where all of these process measurement decisions took
place.  Another example is a Liebert plant that I visited recently where they
want to automatically monitor each part as is routed through their powder
coating department.)

3) The class of employee who is typically responsible for configuring,
deploying and maintaining any Internet-connected process monitoring devices are
the IT support personnel who are usually not programmers and who may or may not
have an intimate understanding of the facility's intranet design.

4) One of the primary barriers that is going to be an impediment to
implementing the "sensor to boardroom" vision going forward is the vast
cultural differences that exist between the embedded systems developer
community and the enterprise/computer science developer community ( see
http://www.javadevices.org/javadevices/resources/images/venn_diagram_large.png
).

We are just now approaching the point where a widespread interest is starting
to build for allowing a company's backend enterprise systems to automatically
monitor and control its internal process using the company's intranet.  It
appears that most people are not aware of this potential cultural
communications problem yet but, if it is real, they soon will be.




Now for the fun part ;-)  Here are some of the issues related to this problem
that we currently view as unknowns:

1) How many Internet-connected embedded devices is a typical J2EE system able
to handle and at what load levels?  Are the bottlenecks going to be the
embedded devices themselves, the network, the presentation layer, the business
logic layer or the database layer?  (For example, I studied Sun's new RFID
reference implementation white paper recently and they needed to develop a
special architecture in order to accommodate the massive amounts of data that
large groups RFID tags are capable of generating into the network as these
groups are moved past a given reader).

2) What are going to be the best-practice protocols that will be used to
communicate between these Internet-connected embedded devices and the J2EE
system?

3) J2EE developers currently have 100% control over any web applications that
they develop but it is unlikely that J2EE developers will be personally
configuring, deploying and managing these new Internet-connected embedded
devices on a company's intranet.  As indicated above, IT support personnel will
most likely be doing this job.  This new scenario entails splitting the
responsibility/control for this class of application between the J2EE
developers and the IT support personnel which has not been encountered before. 
What are the best-practice strategies for handling this new scenario?

4)  As things stand right now, almost no one in the traditional embedded
systems community has any idea what a J2EE application server is nor even what
the function of an enterprise system is in general.  Conversely, almost no J2EE
developers have ever had their hands on any type of embedded systems and, at
best, most only have a vague idea of what their capabilities are.  Before the
"sensor to boardroom" vision can be realized these two communities will somehow
need to be brought closer together.

With respect to the J2EE developer community, what might be some promising ways
to raise its level of awareness with regards to this issue?  Once the awareness
level is raised, what are some workable strategies for enabling J2EE developers
that are interested in moving into this new and promising area of monitoring
and controlling the physical world to start gaining some experience with these
technologies?




I know that this has been somewhat of a large amount of information to relay
all at one time but these are some of the main issues that this group has been
working on for over a year now.

Don't feel like you need to comment on everything that has been listed above
but we would appreciate hearing your perspective on any parts of it that you
find especially interesting.


Thanks,

Ted Kosan

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

[Embedlets-dev] Interested in sharing a J2EE perspective

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hi,<br>
<br>
Ted Kosan asked if I could participate in the deliberations and present
a J2EE angle to the&nbsp; technology. Agreed and joined the group. Looking
forward to participating in the deliberations.<br>
<br>
Cheers,<br>
Ramesh<br>
<br>
<div class="moz-signature">-- <br>
<table style="width: 95%;" font="arial" size="1" border="0" padding="0">
  <tbody>
    <tr>
      <td style="vertical-align: top; font-family: arial;"><font
 ="arial" size="1">Ramesh <a href="http://www.jroller.com/page/rameshl">
Loganathan</a></font></td>
      <td style="vertical-align: top;"><br>
      </td>
    </tr>
    <tr>
      <td style="font-family: arial; width: 70%;"> <font ="arial"
 size="1">VP,
Engineering&nbsp; <br>
      </font></td>
      <td style="font-family: arial;"> <font ="arial" size="1">Ph:&nbsp;
(+91) 40 341
1672 </font></td>
    </tr>
    <tr>
      <td style="font-family: arial;"> <font ="arial" size="1">Pramati
Technologies, Hyderabad, India </font></td>
      <td style="font-family: arial;"> <font ="arial" size="1">Cell:(+91)
98 490 42997 </font></td>
    </tr>
    <tr>
      <td style="font-family: arial;"><font ="arial" size="1"><a
 href="http://www.pramati.com"> www.pramati.com</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a
 href="http://devportal.pramati.com"><span
 style="text-decoration: underline;">devportal.pramati.com</span></a></font></td>
      <td style="font-family: arial;"><font ="arial" size="1"><a
 href="http://www.jroller.com/page/rameshl">&lt;blog&gt;</a></font> </td>
    </tr>
  </tbody>
</table>
:-)
<br>
<font ="arial" size="1">
"Logic is a systematic method of coming to the wrong
conclusion with confidence.." -- Murphy
</font></div>
</body>
</html>

[Embedlets-dev] J2EE <-> Embedded Devices discussion.

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

Hello all,

I have been busy lately bringing the javadevices.org site online but now that
it is up and running I would like pick up our long standing "J2EE talking to
Embedded Devices" discussion and move it forward a bit more.

To help with this I have invited a professional J2EE developer to join the list
so that he can provide a backend developer's prospective.  His name is Ramesh
Loganathan and I kind of found him by accident when I noticed his RFID and J2EE
related post on jroller:

http://www.jroller.com/page/rameshl/20040212#nifty_rfid_based_solutions_and1

Ramesh is the VP of engineering at Pramati ( http://www.pramati.com ).  I am
sure that he is a fairly busy person but hopefully he will be able to spend
enough time with us get a better handle on the J2EE/Embedded Devices problem.


Ted

 

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

Re: [Embedlets-dev] Embedlets - ir

[Jac K. <j.k...@th...>]

On Fri, 6 Feb 2004, Christopher Smith wrote:

> I tried the jir compile and get:
> 
> Finding class net.geeba.ant.Tini
> build.xml [8] taskdef class net.geeba.ant.Tini cannot be found
> 
> I am pretty sure my tini is up to date (1.12). Any suggestions?

This is a build message from ant signaling it can't find TiniAnt in it's
classpath. If you don't have it, go and get it at tiniant.sourceforge.net

Regards,

Jac

-- 
 Jac Kersing            Technical Consultant   The-Box Development
 j.k...@th...                         http://www.the-box.com 

RE: [Embedlets-dev] Embedlets - ir

[Christopher S. <cs...@oo...>]

Fixed - I had to add the classpath (TiniAnt.jar) to the TiniAnt classdef

Christopher Smith
OopScope, LLC.
www.oopscope.com
cs...@oo...
805-276-0598

> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of
> Christopher Smith
> Sent: Friday, February 06, 2004 1:39 PM
> To: emb...@li...
> Subject: [Embedlets-dev] Embedlets - ir
>
>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> Jac,
>
> I tried the jir compile and get:
>
> Finding class net.geeba.ant.Tini
> build.xml [8] taskdef class net.geeba.ant.Tini cannot be found
>
> I am pretty sure my tini is up to date (1.12). Any suggestions?
>
>
> Christopher Smith
> OopScope, LLC.
> www.oopscope.com
> cs...@oo...
> 805-276-0598
>
> > -----Original Message-----
> > From: emb...@li...
> > [mailto:emb...@li...]On Behalf Of Jac
> > Kersing
> > Sent: Tuesday, November 11, 2003 2:54 PM
> > To: emb...@li...
> > Subject: RE: [Embedlets-dev] X10 and 802.11
> >
> >
> > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> > _______________________________________________
> >
> > On Tue, 11 Nov 2003, Kelly Smith wrote:
> >
> > > Mostly exceptions for "Out of memory" and "Unable to connect to
> > remote host"
> > > from a browser.  Sporadic at best, and even though I sprinkled
> > som GCs in
> > > critical sections when the Java code (running on TINI) was idle (i.e.,
> > > waiting for somtehing to do in a thread). Communication data
> > rates to/from
> > > the CM11A from TINI's serial port were never a problem.
> >
> > Hmm, as I stated before, I've got it up and running for over
> 400 days. No
> > out of memory errors yet...
> >
> > > P.S. You will need a cross-over cable from a TINI/TStik to the CM11A.
> >
> > Or just use a handmade cable with GND, TX and RX (cross-over for those
> > indeed) as all other signals are not important anyway (if they are
> > connected at all)
> >
> > Regards,
> >
> > Jac
> >
> > --
> >  Jac Kersing            Technical Consultant   The-Box Development
> >  j.k...@th...                         http://www.the-box.com
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by: ApacheCon 2003,
> > 16-19 November in Las Vegas. Learn firsthand the latest
> > developments in Apache, PHP, Perl, XML, Java, MySQL,
> > WebDAV, and more! http://www.apachecon.com/
> > _______________________________________________
> > Embedlets-developer mailing list
> > Emb...@li...
> > https://lists.sourceforge.net/lists/listinfo/embedlets-developer
> >
>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>

[Embedlets-dev] Embedlets - ir

[Christopher S. <cs...@oo...>]

Jac,

I tried the jir compile and get:

Finding class net.geeba.ant.Tini
build.xml [8] taskdef class net.geeba.ant.Tini cannot be found

I am pretty sure my tini is up to date (1.12). Any suggestions?


Christopher Smith
OopScope, LLC.
www.oopscope.com
cs...@oo...
805-276-0598

> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of Jac
> Kersing
> Sent: Tuesday, November 11, 2003 2:54 PM
> To: emb...@li...
> Subject: RE: [Embedlets-dev] X10 and 802.11
>
>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> On Tue, 11 Nov 2003, Kelly Smith wrote:
>
> > Mostly exceptions for "Out of memory" and "Unable to connect to
> remote host"
> > from a browser.  Sporadic at best, and even though I sprinkled
> som GCs in
> > critical sections when the Java code (running on TINI) was idle (i.e.,
> > waiting for somtehing to do in a thread). Communication data
> rates to/from
> > the CM11A from TINI's serial port were never a problem.
>
> Hmm, as I stated before, I've got it up and running for over 400 days. No
> out of memory errors yet...
>
> > P.S. You will need a cross-over cable from a TINI/TStik to the CM11A.
>
> Or just use a handmade cable with GND, TX and RX (cross-over for those
> indeed) as all other signals are not important anyway (if they are
> connected at all)
>
> Regards,
>
> Jac
>
> --
>  Jac Kersing            Technical Consultant   The-Box Development
>  j.k...@th...                         http://www.the-box.com
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>

RE: [Embedlets-dev] Lego MindStorms being discontinued?

[Christopher S. <cs...@oo...>]

They just had a big re-org based on poor sales. They are pulling back to
their traditional building blocks market.

Christopher Smith
OopScope, LLC.
www.oopscope.com
cs...@oo...
805-276-0598

> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of Ted
> Kosan
> Sent: Tuesday, January 13, 2004 10:37 AM
> To: emb...@li...
> Subject: [Embedlets-dev] Lego MindStorms being discontinued?
>
>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> I wonder what the story is behind Lego MindStorms being killed off?
>
> http://weblogs.java.net/pub/wlg/895
>
>
> Ted
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
> http://hotjobs.sweepstakes.yahoo.com/signingbonus
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>

[Embedlets-dev] Lego MindStorms being discontinued?

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

I wonder what the story is behind Lego MindStorms being killed off?

http://weblogs.java.net/pub/wlg/895


Ted

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

[Embedlets-dev] RE: new JavaDevices All Embedded Java site (sneek peek)

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

Christopher wrote:


> What are the new CVS settings? Do we need new security info?

My thought is that the Embedlets project will remain hosted at sourceforge but
that the new projects (like JBASIC) will be hosted at javadevices.dev.java.net.

To gain write access to the new CVS one needs to become a member of the
javadevices.dev.java.net project and then request a role as a developer.

I am still trying to figure out how the new site works so things might be a
little rough until we can get them figured out.


Ted

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

RE: [Embedlets-dev] new JavaDevices All Embedded Java site (sneek peek)

[Christopher S. <cs...@oo...>]

Ted,

Looks Good!

What are the new CVS settings? Do we need new security info?

Chris

Christopher Smith
OopScope, LLC.
www.oopscope.com
cs...@oo...
805-276-0598

> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of Ted
> Kosan
> Sent: Monday, December 15, 2003 10:12 PM
> To: emb...@li...
> Subject: [Embedlets-dev] new JavaDevices All Embedded Java site (sneek
> peek)
>
>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> During the past couple of weeks I have been busy putting together
> a central
> Embedded Java community site and if you want to take a sneek peek
> at it, here
> it is:
>
> http://javadevices.org
>
>
> All of the development-oriented parts of the site are housed in a
> new java.net
> project including email lists, CVS, etc.
>
>
> For a while now I have felt that the Embedded Java community
> needed a central,
> vendor-neutral site where the community could deal with the 'big picture'
> issues involved with growing the Embedded Java space as a whole.
>
> After thinking to myself for a number of years "why doesn't someone put
> together a central site like this because Embedded Java needs one
> very badly?"
> one day I woke up and thought "why don't you just get off your
> b*tt and do it
> yourself?".
>
> The site is not completely fleshed-out yet but the foundational
> Java Beginner's
> course is live and I am currently working on re-working and
> uploading  1-Wire
> and TINI/TSTIK follow_on modules.  My hope is that Embedded Java
> vendors will
> use the foundation_module to help ease their customers into the
> world of Java
> and then to develop and upload follow_on modules of their own
> which deal with
> their specific products.
>
>
> JBASIC and JPLAB are also getting close and I hope to have them up too by
> sometime next week.  The goal with these two pieces of technology
> is to provide
> a standard, free, open-source BASIC and a simple IDE environment
> (to run it and
> other plugins in) to Embedded Java vendors so that they can do
> the following:
>
> 1) Provide the easiest way possible for developers to get up and running
> quickly on their respective products.
>
> 2) To finally have a way to go after the traditional Embedded
> Systems market
> which is still dominated by products like BasicStamp, BasicX,
> PICBasic, etc.
>
>
> I would have had JBASIC up sooner but I ran into a serialization
> bug with TINI
> 1.12 that Dallas Semiconductor is currently fixing and hopefully they will
> release a patch for it relatively soon.
>
>
> Anyway, have fun looking through the site and feel free to
> subscribe to the
> top-level 'discuss' list with any feedback you may have.
>
>
> Ted
>
> __________________________________
> Do you Yahoo!?
> New Yahoo! Photos - easier uploading and sharing.
> http://photos.yahoo.com/
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>

[Embedlets-dev] new JavaDevices All Embedded Java site (sneek peek)

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

During the past couple of weeks I have been busy putting together a central
Embedded Java community site and if you want to take a sneek peek at it, here
it is:

http://javadevices.org


All of the development-oriented parts of the site are housed in a new java.net
project including email lists, CVS, etc.


For a while now I have felt that the Embedded Java community needed a central,
vendor-neutral site where the community could deal with the 'big picture'
issues involved with growing the Embedded Java space as a whole.  

After thinking to myself for a number of years "why doesn't someone put
together a central site like this because Embedded Java needs one very badly?"
one day I woke up and thought "why don't you just get off your b*tt and do it
yourself?".

The site is not completely fleshed-out yet but the foundational Java Beginner's
course is live and I am currently working on re-working and uploading  1-Wire
and TINI/TSTIK follow_on modules.  My hope is that Embedded Java vendors will
use the foundation_module to help ease their customers into the world of Java
and then to develop and upload follow_on modules of their own which deal with
their specific products.


JBASIC and JPLAB are also getting close and I hope to have them up too by
sometime next week.  The goal with these two pieces of technology is to provide
a standard, free, open-source BASIC and a simple IDE environment (to run it and
other plugins in) to Embedded Java vendors so that they can do the following:

1) Provide the easiest way possible for developers to get up and running
quickly on their respective products.

2) To finally have a way to go after the traditional Embedded Systems market
which is still dominated by products like BasicStamp, BasicX, PICBasic, etc.


I would have had JBASIC up sooner but I ran into a serialization bug with TINI
1.12 that Dallas Semiconductor is currently fixing and hopefully they will
release a patch for it relatively soon.


Anyway, have fun looking through the site and feel free to subscribe to the
top-level 'discuss' list with any feedback you may have.


Ted

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/