Java is being marketed as the ultimate platform for re-usable components. Is this true? If so, how? Find out and judge for yourself whether Java can make this promise true.
Before we continue, we need to ask ourself what a component actually is. What do we know about a component:
In spite of the many definitions of components, these three component properties are more commonly accepted. In the perspective of object-orientation this leads to the following main conclusion:
A component can consist of one or more classes, exposing only part
of the functionality in all those classes to the outside world.
Thus we see that componentizing and object-orientation can perfectly live together. The good thing about the Java platform is that it is object-oriented by nature, and has some good approaches for introducing componentization.
In Java there are various strategies possible for component-driven development. Over-time new Java standards have been introduced, since the early Java versions did not say anything regarding this topic: you had objects, and that was it.
Currently (2000), the following component strategies are possible using the Java platform:
This strategy has been possible with Java ever since it was released to the public in 1995. In Java, every piece of programming logic or data has to 'exist' inside classes. This is the only way in Java, enforcing object-orientation all the way.
By collecting classes that together implement a common piece of logic, or expose a common set of data, one could consider this to be a 'component'. Using Java's way to organize classes, that collection of classes could be organized in one part of the package hierarchy, thus making it clearer that this is one component.
Example: classes A, B and C share a common interest, for example "insurance calculations". Applications that want to use these classes, only need parts of those classes. Thus, a fourth class can be introduced called "InsuranceCalculator" (introducing one exposable class is not always feasible, in which case the exposure of each class in the component's package, and its APIs, must be carefully examined). The structure ends up as follows:
package: com.javagazette.insurance.calculate public classes: InsuranceCalculator other classes: A, B, C
This is a straight-forward approach, but misses an important point: re-usability. It is completely up to the people that develop this component to make it properly re-usable and expose the correct APIs. There is no standard way of doing this when using this approach.
Solution to this is to define standard interfaces for components that every component needs to implement. A common framework could be introduced in the project that knows how to deal with those interfaces (how to instantiate, how to lookup component instances, etc). However, this starts becoming complex, and leads us to the next strategy...
As component-driven development became more and more popular, and as it became clear that Java lacked the necessary services for this, a group of industry leaders was asked by JavaSoft to start working on a standard for doing this in Java.
The result was the Enterprise JavaBeans (EJB) architecture. Part of the goals of the EJB architecture was the following:
More specifically this means that an enterprise javabean is a component, which still fits in the definition introduced earlier in this article: it exposes part of a collection of classes that share a common interest.
Designing and developing an EJB results in the following mandatory parts that end up being the component (the EJB):
To make a long story short: with EJB you get a standard lookup mechanism (deployment descriptor defines what the lookup name is), transaction management, standard way to expose only parts of the component, standard deployment mechanism resulting in a jar file and thus a consistent way to recognize a Java component.
The EJB standard has a lot more to it, but that goes too far for this article. At the end of the article there is a list with EJB resources that might be useful if you want all the details.
JINI is an initiative by JavaSoft to come up with a standard lookup and discovery mechanism for components. JINI was originally targeted towards actual devices, such as tv sets, video recorders, microwaves, etc. Those devices could then suddenly be discovered by any other device, and those devices would know how to communicate.
From a software perspective, JINI is especially interesting for a totally different reason: if all Java components (let's say EJBs) would find each other using JINI, we would suddenly have a fully distributed software application, that would be virtually one, but in reality be scattered over many locations and different machines.
In the EJB standard a lookup of an EJB still results in a reference to an EJB inside the same application server. The application server could be clustered over multiple machines, but it is clear that the lookup boundary is pre-defined.
If all the components would use JINI for making themselves available to the world, a lookup of a specific component would resolve in a component instance anywhere on the network. The most interesting thing is that a JINI-registered component could unregister itself (the machine goes down for example), and re-register itself from a completely different location (new machine plugged into the network, or a backup machine takes over). This means that the lookup boundary can dynamically change.
Before getting too enthusiastic: JINI is not meant to solve what the EJB standard solves. So it does not provide database mappings, deployment descriptors, etc. This means that components that work together through JINI could sometimes be implemented using EJB (strategy 1), sometimes as a plain collection of Java classes (strategy 2), or perhaps even using CORBA (out of the scope of this article)!
Java does provide interesting ways to do component-driven development. There are many strategies, of which we saw the three most common ones. EJB provides the baseline for components, JINI makes components truly distributed, and even without those two one can perfectly develop components (it does require more discipline).
The conclusion can be that Java has all the ingredients to make component development possible. The only thing it is waiting for, is you to start working with it!