When people hear about real-time computing they often make the mistake of thinking that these have to be fast systems and are nearly always used for control of mechanical systems. It is true that in most cases the response times required are fast, but speed is not what defines a real-time system. The true core of a real-time environment is that the system will guarantee to perform some task within a pre-defined time so that the system`s behavior becomes fully deterministic.
For enterprise class applications what are the advantages (and possibly disadvantages) of deployment on a real-time system? In many cases there is no great advantage. Once the non-functional requirements of a system (load capacity, average response time, peak-load response time, and so on) have been met the application can be deployed and the customer is satisfied. Should something happen that makes a request to, say, an HR application take rather longer than usual the user simply has to wait longer; there is no measurable impact. However, for many financial, enterprise class applications failing to do something within a given time can easily be equated to a cost, possibly a very large one. Financial markets, by their very definition, are extremely volatile and computer trading systems mean that prices can change at the rate of many times a second. If one part of a system decides to make a trade based on the current price and the actual trade gets delayed for whatever reason even a small change can result in a significant loss of money. If this delay happens frequently the system soon becomes less of an advantage and more of a liability.
Java, the language, and the Java Enterprise Edition platform have proved to be very popular for the development of enterprise applications. The ease-of-development, performance and reliability all make Java extremely attractive to developers. However, the Java platform does not support real-time applications, and even running a Java application on a real-time operating system will not make the application deterministic. The biggest obstacle to deterministic behaviour of a Java application is the way memory management is handled by the Java virtual machine (JVM). Unlike earlier languages like C and C++ Java uses a garbage collector to reclaim memory that is no longer being used by an application. The reason for this is to eliminate ‘memory leaks`, where a developer forgets to explicitly free memory that is no longer being used. Since the amount of memory in a machine is finite, if this error occurs in some kind of loop eventually the system will run out of memory. (That`s not to say you can completely eliminate memory leaks in Java; if a developer maintains references to objects the garbage collector will still not be able to reclaim the memory).
The garbage collector uses a background thread to monitor the heap space where objects are stored. The garbage collector identifies objects that are no longer referenced and reclaim the unused memory. Much of this work involves copying objects from one address to another within the heap. To prevent the possible corruption of data all application threads (referred to as mutator threads) must be paused when this is happening. On modern JVMs these pauses will not be noticeable for well tuned desktop applications. Even for most enterprise applications the use of the concurrent-mark-sweep collector (also known as the low-pause collector) will reduce pauses to levels that are acceptable for most applications. However, for certain classes of enterprise applications like those described earlier, non-deterministic behaviour and therefore Java is not suitable.
To solve this problem a Java Specification Request (JSR) was created to design and implement a real-time specification for Java (RTSJ). This was, in fact, the very first JSR created under the Java Community Process when it was started in 1998. The expert group had several guiding principals in the creation of the specification. Three of these principals are worth noting when considering the applicability to enterprise applications:
1. Backwards compatibility, so that any class file generated by a Java compliant compiler would run on a RTSJ virtual machine.
2. No syntactic extensions. No new keywords or syntactic changes would be made to the Java language. This is partly a result of the first point, but is also essential to enable Java developers to easily migrate to RTSJ and use existing development tools such as NetBeans.
3. Predictable execution. This would be the first priority when making design decisions. The impact of this is that sometimes the typical computing performance may be reduced. This is one reason that an RTSJ system should be considered carefully for general enterprise applications.
The RTSJ specification describes eight areas of extended semantics for Java:
1. Scheduling
2. Memory management
3. Synchronization
4. Asynchronous event handling
5. Asynchronous transfer of control
6. Asynchronous thread termination
7. Physical memory access
8. Exceptions
Threads within the RTSJ can be one of three types, non real-time, soft real-time and hard real-time. A non real-time thread is somewhat obvious, in that it does not have a specific deadline when some action must be completed. It can be scheduled when convenient by the JVM and any impact of the garbage collector is immaterial. Soft real-time threads are ones that do have a deadline for completion of an action. However, there is a certain amount of leeway so that if the action gets completed shortly after when it should have done everything will still continue without any problems. For hard real-time threads they absolutely must complete the action by the deadline; if they do not an unrecoverable error has occurred. RTSJ applications can have threads of all three types running simultaneously. The choice of what type of thread to use is down to the designer of the application and the level of importance attached to the work of a thread.
Source:
http://www.infoq.com/articles/real-time-java
For enterprise class applications what are the advantages (and possibly disadvantages) of deployment on a real-time system? In many cases there is no great advantage. Once the non-functional requirements of a system (load capacity, average response time, peak-load response time, and so on) have been met the application can be deployed and the customer is satisfied. Should something happen that makes a request to, say, an HR application take rather longer than usual the user simply has to wait longer; there is no measurable impact. However, for many financial, enterprise class applications failing to do something within a given time can easily be equated to a cost, possibly a very large one. Financial markets, by their very definition, are extremely volatile and computer trading systems mean that prices can change at the rate of many times a second. If one part of a system decides to make a trade based on the current price and the actual trade gets delayed for whatever reason even a small change can result in a significant loss of money. If this delay happens frequently the system soon becomes less of an advantage and more of a liability.
Java, the language, and the Java Enterprise Edition platform have proved to be very popular for the development of enterprise applications. The ease-of-development, performance and reliability all make Java extremely attractive to developers. However, the Java platform does not support real-time applications, and even running a Java application on a real-time operating system will not make the application deterministic. The biggest obstacle to deterministic behaviour of a Java application is the way memory management is handled by the Java virtual machine (JVM). Unlike earlier languages like C and C++ Java uses a garbage collector to reclaim memory that is no longer being used by an application. The reason for this is to eliminate ‘memory leaks`, where a developer forgets to explicitly free memory that is no longer being used. Since the amount of memory in a machine is finite, if this error occurs in some kind of loop eventually the system will run out of memory. (That`s not to say you can completely eliminate memory leaks in Java; if a developer maintains references to objects the garbage collector will still not be able to reclaim the memory).
The garbage collector uses a background thread to monitor the heap space where objects are stored. The garbage collector identifies objects that are no longer referenced and reclaim the unused memory. Much of this work involves copying objects from one address to another within the heap. To prevent the possible corruption of data all application threads (referred to as mutator threads) must be paused when this is happening. On modern JVMs these pauses will not be noticeable for well tuned desktop applications. Even for most enterprise applications the use of the concurrent-mark-sweep collector (also known as the low-pause collector) will reduce pauses to levels that are acceptable for most applications. However, for certain classes of enterprise applications like those described earlier, non-deterministic behaviour and therefore Java is not suitable.
To solve this problem a Java Specification Request (JSR) was created to design and implement a real-time specification for Java (RTSJ). This was, in fact, the very first JSR created under the Java Community Process when it was started in 1998. The expert group had several guiding principals in the creation of the specification. Three of these principals are worth noting when considering the applicability to enterprise applications:
1. Backwards compatibility, so that any class file generated by a Java compliant compiler would run on a RTSJ virtual machine.
2. No syntactic extensions. No new keywords or syntactic changes would be made to the Java language. This is partly a result of the first point, but is also essential to enable Java developers to easily migrate to RTSJ and use existing development tools such as NetBeans.
3. Predictable execution. This would be the first priority when making design decisions. The impact of this is that sometimes the typical computing performance may be reduced. This is one reason that an RTSJ system should be considered carefully for general enterprise applications.
The RTSJ specification describes eight areas of extended semantics for Java:
1. Scheduling
2. Memory management
3. Synchronization
4. Asynchronous event handling
5. Asynchronous transfer of control
6. Asynchronous thread termination
7. Physical memory access
8. Exceptions
Threads within the RTSJ can be one of three types, non real-time, soft real-time and hard real-time. A non real-time thread is somewhat obvious, in that it does not have a specific deadline when some action must be completed. It can be scheduled when convenient by the JVM and any impact of the garbage collector is immaterial. Soft real-time threads are ones that do have a deadline for completion of an action. However, there is a certain amount of leeway so that if the action gets completed shortly after when it should have done everything will still continue without any problems. For hard real-time threads they absolutely must complete the action by the deadline; if they do not an unrecoverable error has occurred. RTSJ applications can have threads of all three types running simultaneously. The choice of what type of thread to use is down to the designer of the application and the level of importance attached to the work of a thread.
Source:
http://www.infoq.com/articles/real-time-java
+2
Enter your comment:
Mahi 08-01-2009
For any web application , end user expects the target screen with in a span of time ( depends on various factors).In this netizen world performance tunning plays a vital role for web Applications.
