OBSOLETE SECTIONS
This page contains sections of the Java Review (from 1998, 2001, etc.) which have been retired either because they were replaced with longer discussions or because they are no longer of critical relevance to the state of the Java platform.
javabeans
The JavaBeans API was introduced with the JDK 1.1 and offers developers a standard way of creating re-usable components which can communicate with each other — it competes against Microsoft's ActiveX. The BDK (Bean Development Kit) is distributed separately and includes the beanbox program for linking beans and examining their details.
The Java Activation Framework (JAF) is a set of classes which ensure that when a system (e.g. a browser, any Java program) encounters an arbitrary piece of data, the type of the data is automatically determined and an appropriate bean is activated. It is used in the JavaMail API in a way analogous to that of MIME in standard mail systems.
The InfoBus standard extends the JavaBeans standard by defining how beans can share data with each other, rather than just responding to each other. A set of beans can be connected on an InfoBus by sharing common interfaces.
Extra notes:
- Enterprise JavaBeans (EJBs) are very different to JavaBeans. They have separate APIs, are server-side rather than client-side, and are inter-process rather than intra-process.
|
Developing a bean with Sun's BDK
|
Sun's JavaBeans page
|
corba
CORBA (Common Object Request Broker Architecture) is a middleware standard which came before EJB and can now work with it. In the 1980's the 2-tier LAN client-server model had become popular; in the 1990's CORBA and Microsoft's Windows-specific DCOM competed as more generalized distributed object infrastructures. CORBA, invented and managed by the OMG (Object Management Group) representing a consortium of companies, is a set of standards specifying services and protocols for enabling communication between objects created in different languages (e.g. C++, Java, COBOL). CORBA is complementary to Java; where Java is OS-independent, CORBA is language-independent. Many EJB products support CORBA, allowing you to connect to legacy applications.
A CORBA system is supervised by ORBs (Object Request Brokers). Objects bind to an ORB, and can then call methods on other objects on the ORB and other ORBs — ORBs communicate using a protocol called IIOP. Each object declares the methods it is making public in IDL (Interface Definition Language), a language independent of any implementation languages. CORBA also specifies a number of services, including a Naming Service (similar to JNDI), an Event Service (for asynchronous communication), an Object Transaction Service (OTS), a Concurrency Control Service, and a Security Service.
ORBs include Iona's OrbixWeb, Borland's VisiBroker, and IBM's ComponentBroker.
RESOURCES
The Object Management Group (responsible
for the CORBA standard)
Sun/JGuru's introduction to using CORBA with Java 2
Visigenic — VisiBroker is downloadable
A sample Chat application
with Java and CORBA
rmi
EJBs communicate using RMI (Remote Method Invocation) as the underlying protocol. RMI is an older Java technology which has been a core package in the language since JDK 1.1. It allows objects to call methods in other objects across networks as if they were local.
Unlike weightier distributed object systems like CORBA and DCOM, RMI is proprietary and limited to Java. However, it is a simpler, more lightweight solution, and forms the base layer of most Java distributed technologies. Moreover, Sun has created a standard whereby RMI can run over IIOP, thus allowing some integration between systems built on CORBA and systems built on RMI. Also, since JNI (Java Native Interface) makes it possible to make calls outside of Java, the performance advantages of specialized C++ engines are not necessarily denied to a distributed system using RMI.
A basic RMI application involves a client and a server. The server code must include an interface (in ordinary Java code) to the class it is making available over the network. The implementation of that interface (typically the class's name ends in "Impl") needs to import the java.rmi.* classes and it will also need the java.rmi.server.UnicastRemoteObject as a superclass. In the main body of the implementation class the security manager is set to the RMI security manager to enable the default Java security restrictions to be relaxed. Furthermore the object must be named in the registry using Naming.rebind. (RMI's registry services are inferior to those of CORBA.) Also a constructor which calls its superclass constructor (UnicastRemoteObject) must be defined, and, of course, the methods of the interface must be implemented.
The client for its part has little to do — if it uses Naming.lookup to get the object registered in the server, it can call any method on that object that has been defined in the interface.
RESOURCES
jini
Another distributed objects technology which runs on top of RMI is Jini. Jini comprises an API and runtime conventions that facilitate the creation and deployment of distributed systems. This may sound a bit like EJBs, but whereas the EJB framework is aimed at abstracting business logic from distributed services in back-end systems, Jini is aimed at having networks of devices interact and adapt to change. For instance, if a printer is added, this should be automatically picked up without any special configuration by users. This is like the idea of "plug and play," but there is an emphasis on the device itself having a certain intelligence, at least enough to announce itself to the network.
RESOURCES
J2EE introduced the concept of a service-providing container environment in which server-side components called EJBs could operate. Typically an application developer writes the business logic in the EJBs, then uses a tool to automatically generate container classes which are wrapped around the EJBs and ensure that they share resources, use transactions, are mapped to database records, etc. One or more containers run inside the server. To be J2EE-compliant, application servers come with a container framework. In the future it may be possible to have a container from one vendor inside a server from another vendor, but this relies on Sun defining a container-server contract.
The specification distinguishes between entity beans, stateless session beans, and stateful session beans. Entity beans are Java classes which map directly to records in the database, with member variables representing table fields — e.g. BankAccount might be an entity bean. On top of entity beans, stateless session beans are frequently built: these provide business methods which may be called on a request from a Web user. They keep no state between requests, unlike stateful session beans, which can be used for processes spanning multiple Web requests such as adding items to a shopping cart.
Each EJB class must have a home interface and a remote interface. The home interface defines methods that clients can use to find, create, and destroy and EJB of the required type. The remote interface defines the business logic methods which a client can then call on the EJB. The bean itself effectively implements all the methods of these interfaces; however, requests from client code do not reach it without passing through a proxy called an EJB Object. When you write a bean and generate a container, this is a crucial part of the container code, and is specific to that bean class. It ensures that all the distributed services mentioned above apply in the process of calling the bean.
Popular J2EE application servers include WebLogic (from BEA), Websphere (from IBM), and Enhydra (Open Source). The screenshots below illustrate the process of deploying a bean with Weblogic and running the server.
