We are actively pursing a real-time solution (module) for JavaSpaces.
Sent from my iPhone
Michael McGrady
Principal investigator AF081_028 SBIR
Senior Engineer
Topia Technology, Inc
Work 1.253.572.9712
Cel 1.253.720.3365
On Feb 23, 2010, at 8:48 PM, Peter Firmstone <[email protected]> wrote:
Sim IJskes - QCG wrote:
Peter Firmstone wrote:
Anyone have any thoughts about real time java threads? EtherCAT
is real time ethernet, a Jini service that runs on a real time
thread, over real time EtherCAT with JERI and clients running on
real time threads. That would be more realistic in an industrial
environment (ubiquitous computing) than a Jini Toaster yes? We
seriously need to remove all and any references to Toasters,
coffee machines etc in documentation.
EtherCAT, do you mean the fieldbus type?
Yep
Jini certainly looks like a good communications platform for SCADA
solutions. All one needs is a small ARM-7 based sensor/controller
and GCJ for creating a flashable image and your on the road.
Anybody here know of such a scenario in the wild?
Nope be interesting to see though, if it exists. GCJ 4.0 compiles
to native code. Not sure how to do dynamic class loading for
service proxy's.
I'm looking at Sun's RTSJ and Embedded Industrial x86 at the moment.
My guess is that Oracle wont open it, even though Sun originally
intended to. Java looks ideal for embedded. Although at this stage
I have no intent of utilising Jini on real time threads.
However the thought exercise is interesting:
Jini Services and clients wouldn't need to be run on real time
threads unless they were part of real time software
implementations. For classes on real time threads (RTSJ) , there is
an initialisation stage where all bytecodes for class files will be
pre compiled to avoid hotspot, so a service could potentially run on
a real time thread. Simple proxy's could be pre compiled in the
initialisation stage, limiting the client to the services
determined at initialisation.
A person might rightly suggest the 8 fallacy's of distributed
computing as being a problem. One would tackle this by providing a
time guarantee for service discovery. So in a redundant network
topology utilising EtherCAT, one could have realtime services and
simple proxy clients pre determined at initialisation time, the
service would actually form part of the redundancy system, upon
catching an exception, the lookup service would provide the location
of an alternate service, utilised in instances where redundant
sensors or functions were in place, made available through Jini
services. The real time service might remove its entry from lookup
once it has reached a load level that limits the real time
guarantees. There are a number of time guarantees that need to be
considered, such as network latency (according to the doc's EtherCAT
has low latency, distance and load are limiting factors) and Service
load.
Perhaps with a dynamic smart proxy, one might initially use a simple
service proxy, where a server performs work subject to time
guarantee's, until the smart proxy is compiled in the background on
a non real time thread and loaded onto a real time thread when ready.
Perhaps the real time service lookup would need to be a totally
different lookup service mechanism, specific to real time, that
could coexist in the same space as the existing Jini Service
Discovery / lookup spec. The River framework would have to check if
a service or client registering for Real Time services were running
on real time threads and whether the network supported Real Time
constraints. A distinction would need to be made between soft and
hard real time.
http://www.ciss.dk/download/Slides%20Martin%20Astradsson.pdf
I would love to work on a SCADA kernel completly written in Java.
Yes...
Cheers,
Peter.
Gr. Sim
