Peter Firmstone wrote:
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.
It will be fed to the interpreter.
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.
I can imagine. I found it particularly a stress-reducer that the main control loop was done by a PLC. I cannot imagine that a customer would accept a solution without. The marriage of a PLC and a non-cyclic controller is a scenario i like. But a Java system for monitoring, datamining, recipe loading etc, would be perfect. The PLC-CPU combo could provide for reading the datapoints in the PLC memory via an Java API and the datapoints be exposed in the registry.
Still realtime java would be a benefit. Altough all data should be timestamped, the datarates can be such that starvation could be a real problem.
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.
It all revolves about the moment of compilation. Either at deployment (GCJ), start, verifier (classloader) or runtime. I think sensors will go for early instead of late compilation (maybe even interpreted). You could state, if the sensor has idle time in which it can do background compilation, the sensor has been too expensive.
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
But, that would mean a departure from 'let the client decide' isn't it? The registry provides all redundant sensors in one query (if i had the benefit of redundant sensors, i would read them both all the time, and provide a conflict resolution strategy, but still record both of the separate).
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.
Thats a particular nice thought, but if a service cannot comply with its realtime constraints, how can we make sure it has the capacity to remove itself?
Gr. Sim -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397
