 |
-- JohnCatherino - 13 Nov 2004
Characteristics of the cajo framework
- Priorities: The most important consideration in the design of the cajo project is that is must work in all Java runtime environments, 1.2 and higher. This means, as tempting as some of the new features may be, there is simply too large an installed base to make this practical. That said, there has also been no really cool new feature that we could not successfully recreate, using plain-old Java2. However, this does not mean that your applications are in any way restricted. For example, while cajo allows all devices, from mobile phones, to desktop workstations, to work together; you are free to use all the latest and greatest language, and runtime features, so long as your cooperating devices support them.
- Features: One of the most important features of the framework is that applications do not have to be structured around it. This is quite unique among distributed frameworks. This makes it extremely easy to incorporate the framework into existing applications. As we like to say: You don't design your applications to cajo, it simply drops-in! Simple object oriented design is all that is required. Its two main strengths are in the ease in which it allows Virtual Machines to join together dynamically to create a seamles virtual computer; and its ability to remote rich user interfaces very simply.
- Limitations: Being RMI based, naturally cajo only works between Java applications. For pre-Java legacy applications this can entail a significant porting effort. However, this is more than offset by the magic of mobile code. Being able to send an object to another Virtual Machine, including its class definitions, is a wondrously powerful feature; which is provided only through Java.
- Performance: Since cajo is a small, highly efficient layer built atop RMI, its performance is definitely no worse than other Java technologies like Jini, or J2EE?, in fact it is typically much better! It does entail a little more overhead than using basic socket protocols, however the power and transparency RMI provides is well worth the cost; and would ultimately have to be recreated manually, to provide all of the framework's functionality.
- Persistence: The primary storage mechanism used in the cajo project is the zedmob. This is a contraction of two words: Zipped and Marshalled Object. It allows remote references, and even remotely loaded objects, to be saved to disc, or passed to other remote Virtual Machines. A zedmob is persistent in that its existence is entirely independent of the lifetime of the Virtual Machine using it.
- Scalability: The scalability of the framework comes in two forms; sometimes called static and dynamic. Static scalability means a single application can very easily migrate its objects between multiple Virtual Machines, to accomodate increased load, or reliability concerns. Dynamic scalability means objects can readily join together, to create emergent functionality. This second technology is very exciting, and still in its infancy.
- Security: There are many facets to security. For server reliability; hosting proxy objects could invite the possibility of a Denial of Service attack. A proxy object could request more resources than the host can provide, potentially hobbling its Virtual Machine. Alternatively; security in communication can be provided in several ways. For example, the communication could be conducted over SSL, however, the blanket of overhead must also be taken into consideration. To counter this, there is also a transparent way to individually encrypt sensitive objects; this can prove both significantly faster, and even more secure!
- Simplicity: The core framework is very small, and can be quickly understood completely. Yet for all this simplicity, it provides even more flexibility and power than the larger and more complex, heavyweight frameworks out there. Finally it allows you to focus purely on your design!
- Flexibility: The framework provides capability unprecedented with conventional RMI: Clients can use remote objects, without knowing their functional interface at compile-time! For dynamically adaptive designs, this is an extremely valuable feature, unavailable in the vast majority of other frameworks. (If not all.)
|