What is the current version of the Java 2 Enterprise Edition?
The Java platform versioning is quite confusing. This is even more true since Sun split the original platform into three editions. Although it was a good step for decoupling application development, it has led to more effort in terms of version management.
To answer the question, Sun released Release 1.3 of the enterprise edition (J2EE) on September 24, 2001. This is different from Release 1.3 of the JSE (Java Standard Edition), which was released more than a year ago. Currently the latest version of J2SE is 1.3.1 and the 1.4 version is in the beta release stage.
There's a dependency between the editions. J2EE uses the J2SE libraries, therefore the J2EE released versions need to be compatible with the latest J2SE versions. If you get to the granular APIs, they have their own versioning. For example, the J2EE Connector Architecture is in Release 1.0 and the Servlet API is in Release 2.3
Java 2, the current release of the Java platform, is the umbrella that encompasses the latest versions of all the API editions mentioned above. So the J2ME, the J2SE, and the J2EE APIs are all a part of the Java 2 platform.
Can an RMI server run on a Java client?
Yes, it can. The main components of an RMI-based application are an RMI client, RMI server, and RMI registry. The RMI server can run on a machine that hosts a VM that supports the RMI library. Support for RMI is required of all Java VMs.
In the traditional client/server scenario, a Java client application connects to a Java server application; the Java server application does the bulk of data processing and business logic on the server side. If you aren't connecting via the HTTP layer, i.e., your connectivity isn't based on access through a Web server via servlets/JSPs, you'll probably use RMI for connectivity. Typically, the RMI server will run as a part of your Java server application. That is, the implementation of the RMI-based interfaces for your application will be on the Java server application.
However, this isn't necessarily true. If you wanted to use RMI for some processing on the Java client and return the results to the Java client, you can achieve that also. In this case the RMI server will run on the Java client and the RMI client will run on the Java server. An example of this is when you want to push data to the Java client and invoke a method on the client to process that data on the Java client-side after receiving it from the Java server.
Is EJB a specification or an actual Java component?
Both. The EJB specification defines the design and implementation for Enterprise JavaBeans, which are Java components. An interesting point to note in documents covering EJBs is that both the singular and plural word form is used to refer to EJBs. For example, Enterprise JavaBeans is a specification. Enterprise JavaBeans are Java components.
Is EJBObject a Remote object?
Actually EJBObject (javax.ejb.EJBObject) is an interface that extends java.rmi.Remote interface. Note that an "EJBObject" interface and an "EJB Object" class (notice the space) are two different entities. An "EJB Object" class is an actual class that is autogenerated by the application server. The "EJB Object" object is a delegator object that exposes all the methods of your actual EJB (entity/session/message-driven) implementation.
When developing an EJB component, the first thing you need to do is define an interface (e.g., MyInterface) that extends the javax.ejb.EJBobject interface. In doing so, you'll add your business logic methods to the methods already defined in the EJBObject interface. These methods are used by the container to manipulate your EJB component - methods to find the bean, get a reference to the bean, etc. During deployment the container will generate a class that provides an implementation for all the methods for MyInterface, including delegator classes for the methods that you define. This class is your "EJB Object" class implementation of your "MyInterface" interface.