by Markus Eisele
BEA WebLogic Real Time server (WLRT) provides a Java-based infrastructure catering to real-time processing needs. This is something quite new in the Java world: Handling requests in real time requires more than just a performing and reliable J2EE server. The key to making the new features work is the JRockit Java Virtual Machine (JVM). This article describes a cool marriage between BEA WebLogic Server and BEA JRockit and provides some of the basics of real-time computing. It ends with a short introduction to relevant use cases of WebLogic Real Time.
Before we start talking about WebLogic Real Time we have to think about the two words introduced with this product name: "real" and "time." Numerous definitions of real time exist and many articles describe the various concepts— the first Java Specification Request ( JSR 1) was even dedicated to this topic. However, the definitions are varied. No one provides a definitive explanation of what real time is and where to find it, but everyone seem to believe they know it when they see it. To get a better understanding of this concept some common definitions should be introduced. According to a good discussion about real time by Douglas Jenson, two different types of real time exist: "soft" real time and "hard" real time:
In a hard real-time system the time deadlines must be met or the result of a calculation is invalid. For example, have a look at embedded systems that run in cars. If you accelerate and the electronic accelerator's impulse is delayed, you have very unintended behavior. If what you end up with is a delayed braking system, dire consequences will result. The timing constraints in a soft real-time system are not as stringent. The result of a calculation can still be useful even if it does not meet its time constraints.
Audio streaming is an example of a soft real-time system. If a packet of data is late or lost, the quality of the audio is degraded, but the stream may still be valid.
To guarantee that the timing requirements of a real-time system are met, the behavior and timing of the underlying computing system must be predictable. The time required by all operations must be bounded for the timing of the system to be called predictable. This implies that the worst-case timing of all operations is known. Real-time systems typically are implemented with multiple asynchronous threads. This is because they typically need to react to events and control asynchronous devices.
Another common requirement is priority. Because the criticality of certain events and the number of events that need to be handled are different, the notion of priority must be supported in order to ensure a time-critical task is not delayed due to a non-critical task. This problem can result from letting the non-critical task run with the same priority of the time-critical task. For this concept of priority inversion the tasks need to have the ability to communicate with each other. Therefore, the real-time system must provide synchronization and communication facilities. In short words, a real-time system must be predictable with a mimimal overhead.
There are many other theoretical aspects of real-time computing, such as scheduling theory, which we'll leave to the References section of this article. As you may have guessed, we are talking about soft real-time when discussing WLRT. This talk of hard and soft is valuable in understanding what to expect from the product and the use cases it is intended for. With this in mind, here are other terms and definitions used when discussing concepts around WebLogic Real Time: