Comparing cajo to other frameworks

William of Ockham: Pluralitas non est ponenda sine necessitate.
Faced with multiple similar options, the simplest is preferable.
(aka Ockham's razor)

Leonardo da Vinci: Simplicity is the ultimate sophistication.

Note: Please do not regard these comparisons as denigrating any of the fine frameworks outlined below. It is just that the cajo project can perform all of their functionality, and even much more, very simply. If it could not do all this, it would not be worth developing the project in the first place. The tone of the comparisons is of the form: "Here is what that framework does in a nutshell, and here is why cajo is much simpler, and more flexible".

• J2EE: An enormous framework for the development of business application servers, called containers in its vernacular. J2EE provides API resources to manage communications, threading, transactions, and resources. The cajo framework is an evolution beyond the traditional client/server architecture perspective. It provides a clean foundation on which separate Virtual Machines can offer up, and use, functionality as objects, as simply as it does local ones.

• EJB: Much closer to the design idea behind the cajo framework, yet still J2EE constrained. EJB is a server-side component architecture, similarly cajo is a component architecture but with an object-to-object interaction focus. EJB requires a J2EE container environment in which to operate, cajo has no requirements for any special frameworks, it is designed to even run on J2ME platforms, like mobile phones. EJB has specialized classifications of components, broadly categorized as entity, session, and message driven beans. In the cajo framework objects are simply objects, their scope and purpose are application specific, no differently than for local objects.

• JMS: Another technology included in the J2EE platform. JMS focus is on messaging between objects. Since cajo allows remote objects to appear local, it is used far more richly than simply for messaging.

  Note: For legacy enterprise applications it is recommended to use cajo in addition to J2EE. It is most effective to reserve the use of heavyweight J2EE purely for interoperability with other supplier's J2EE products, or other legacy software. I.e. try to use J2EE only where mandatory, and cajo for everything else.

• Jini: It might be called the motivation for the creation of the cajo framework. They both are frameworks to allow spontaneous internetworking of objects, which can easily adapt to change and nodal failure. Jini imposes significant architectural structure on its objects, whereas cajo is entirely freeform. This causes the Jini framework to be considerably larger than cajo. The largest impetus for the creation of the cajo project, has also been the largest stumbling-block for the adoption of Jini: The Jini Technology Specific Attachment to the SCSL, aka the JTSA. An extremely restrictive license, in particular, Section IV, subsection D; it legally prohibits open source Jini projects from use outside the research community, and provides no option for use in free software projects. It even tries to dictate the only countries that may even see its source! In contrast, the cajo project is freely licensed under the GNU LGPL; everybody is free to use it, everywhere.
  Update: Sun has recently agreed (Mar-05) to open the Jini interface specifications, and selected source code, under the Apache license 2.0. This is a bold move, but to be successful it still requires acceptance by copyright holders of other critical Jini code, otherwise potentially devastating license traps will continue to exist.

• JavaSpaces: A Jini dependent service for collection and distribution of object resources. It is often thought of as difficult to set up and use, as it requires simultaneously operating support applications. The use of JavaSpaces may also subject one's application to the license terms of the JTSA. In the cajo framework, an effective equivalent to this functionality can be provided far more simply, and intuitively, with only a single-line; which just remotes a Hashtable. The persistency of the collection can be easily maintained by simply writing the table to disc. Additionally, and quite unlike JavaSpaces, the table itself can also be passed around between Virtual Machines.

• Agents: Frameworks such as aglets involve sending specially constructed, configured, and well known objects to agent servers. Here these agent objects gather application specific information of interest to the sender, and return it. This is an interesting technnique, and while very easily implemented using cajo, it is outside the core project scope. The cajo framework does not dictate any application architecture, it is a drop-in technology. All agent based systems are designed as such from scratch.

• Grids: A form of utility modelled parallel processing service. It is an interesting concept, and can be implemented very easily with cajo. The grid processors need simply provide proxy hosts. The proxies can dynamically load themselves, as many as needed, and over as many virtual machines as necessary. They can then freely communicate with each other, as well as the host, or hosts, from which they were sent. This concept is often confused with the cluster approach. With grids, the nodes are heterogeneous, and separated by large distances; while clusters have homogeneous nodes, in very close proximity. Grid nodes are typically added and removed dynamically, whereas cluster node counts are very stable. One of the real strengths of the cajo framework is that it enables the application design for either, to be essentially identical.

• Applets: An oft neglected component of the Java runtime, this is actually a specialty of the cajo framework! It is very easy to export any user interface to a remote machine as an Applet. It also works just as transparently with WebStart. The user interface is actually sent as a Component, to enable the collection of remote GUIs in a composite local frame. The codebases are typically deployed unsigned, to assure complete client security.

• WWVM: OK, this one is a plant The World Wide Virtual Machine is actually a viewpoint, extolled by the cajo project. It posits that the network will become a vast collection of useful objects, with which to freely link, and dynamically interoperate. It will allow the development of rich, highly robust, fault-tolerant, and self-healing distributed applications. It represents a revolutionary step beyond the utility offered for application development by purely local collections of objects. To paraphrase another popular slogan; in the WWVM: "The internet is the virtual machine".