CORBA products provide a framework for the development and execution of distributed applications. But why would one want to develop a distributed application in the first place? As you will see later, distribution introduces a whole new set of difficult issues. However, sometimes there is no choice; some applications by their very nature are distributed across multiple computers because of one or more of the following reasons:
• The data used by the application are distributed
• The computation is distributed
• The users of the application are distributed
Data are Distributed
Some applications must execute on multiple computers because the data that the application must access exist on multiple computers for administrative and ownership reasons. The owner may permit the data to be accessed remotely but not stored locally. Or perhaps the data cannot be co-located and must exist on multiple heterogeneous systems for historical reasons.
Computation is Distributed
Some applications execute on multiple computers in order to take advantage of multiple processors computing in parallel to solve some problem. Other applications may execute on multiple computers in order to take advantage of some unique feature of a particular system. Distributed applications can take advantage of the scalability and heterogeneity of the distributed system.
Users are Distributed
Some applications execute on multiple computers because users of the application communicate and interact with each other via the application. Each user executes a piece of the distributed application on his or her computer, and shared objects, typically execute on one or more servers. A typical architecture for this kind of application is illustrated below.
Prior to designing a distributed application, it is essential to understand some of the fundamental realities of the distributed system on which it will execute.
The Java Remote Method Invocation Application Programming Interface (API), or Java RMI, is a Java application programming interface that performs the object-oriented equivalent of remote procedure calls (RPC).
1. The original implementation depends on Java Virtual Machine (JVM) class representation mechanisms and it thus only supports making calls from one JVM to another. The protocol underlying this Java-only implementation is known as Java Remote Method Protocol (JRMP).
2. In order to support code running in a non-JVM context, a CORBA version was later developed.
Usage of the term RMI may denote solely the programming interface or may signify both the API and JRMP, whereas the term RMI-IIOP (read: RMI over IIOP) denotes the RMI interface delegating most of the functionality to the supporting CORBA implementation.
The programmers of the original RMI API generalized the code somewhat to support different implementations, such as a HTTP transport. Additionally, the ability to pass arguments "by value" was added to CORBA in order to support the RMI interface. Still, the RMI-IIOP and JRMP implementations do not have fully identical interfaces.
AND NOW JSHOOTER
JShooter (Reflect in Network Framework)
What is JShooter?
JShooter is a framework for distributing application programs on the network. Certainly, you have used RMI, Corba and JMS. Each of aforementioned technologies has its own special problems and at the same time enjoys extraordinary advantages. However, you must be careful about the expenses caused by these technologies. In most cases RMI, Corba and JMS increase the productions’ costs unbelievably. However in other cases they confuse programmers. Years ago, Reflect Oriented Programming was the focus of attention within professional programmers, then Aspect Oriented Programming came into the programming world but instead of reducing the programmer’s task, it causes the professional programmers and even the amateur ones to be confused in many cases. One of the most important capabilities of JShooter is that it makes the “Reflect Oriented Programming” easier to use.
For more information about JSHOOTER goto
download it's doc and shine enterprise library