|
|
||
John Catherino's BlogDistributed ArchivesSimple Inter-JVM communication... The Grail!Posted by cajo on September 03, 2007 at 04:19 PM | Permalink | Comments (18)I am very pleased to announce a most significant breakthrough from the the cajo project, in the ease with which distributed computing can be accomplished in Java; and in only 20 kilobytes. It works with all JREs, 1.3 and later. (And before you Rocket Scientists out there ask; yes, it's also 64-bit clean ;) Just three methods: (click the link, for greater detail) void export(Object object);That's it. These allow for complete interoperability between distributed JVMs. It just can't get any easier than this. Any object can be exported for remote object invocation, irrespective of the classes it implements, or interfaces it extends. An exported object can be used by a client, simply if it is compatible with the signature requirements specified by the client. Argument and return type coërcion is applied, in compliance with the language specification. Comfortably, the exported methods can be used with the same syntax and language conventions as local methods. However, it is always well to keep in mind the Eight Fallacies of Distributed Computing. [pdf warning] Strictly speaking the simple 3 method Grail interface could be implemented by other distributed frameworks; Jini, EJB, Spring, etc. So I've placed the interface specification into the public domain: To leave that as a bit of an open challenge! ;-) OK, time for an example: Server.java import gnu.cajo.Cajo; // The cajo implementation of the Grail public class Server { public static class Test { // remotely callable classes must be public public String foo(Object bar, int count) { System.out.println("foo called w/ " + bar + ' ' + count + " count"); return "Thanks"; } public Boolean bar(int count) { System.out.println("bar called w/ " + count + " count"); return Boolean.TRUE; } public boolean baz() { System.out.println("baz called"); return false; } } // but needn't be defined in the same class public static void main(String args[]) throws Exception { // unit test Cajo cajo = new Cajo(1198, null, null); cajo.export(new Test()); System.out.println("Server running"); } }Compile via: javac -cp grail.jar;. Server.java Execute via: java -cp grail.jar;. Server Now for a client: Client.java
import gnu.cajo.Cajo;
interface ClientSet { // client interfaces need not be public
void baz();
boolean bar(Integer quantum);
Object foo(String barbaz, int foobar);
} // the order of the client method set does not matter
public class Client {
public static void main(String args[]) throws Exception { // unit test
Cajo cajo = new Cajo(0, null, null); // port does not matter for clients
Thread.currentThread().sleep(100); // allow a little discovery time
Object refs[] = cajo.lookup(ClientSet.class);
if (refs.length > 0) {
System.out.println("Found " + refs.length);
ClientSet cs = (ClientSet)cajo.proxy(refs[0], ClientSet.class);
cs.baz();
System.out.println(cs.bar(new Integer(77)));
System.out.println(cs.foo(null, 99));
} else System.out.println("No servers found");
System.exit(0);
}
}
Compile via: javac -cp grail.jar;. Client.javaExecute via: java -cp grail.jar;. Client That's all there is to it. Detailed information, including source code, can be found here, also the main project site is a very helpful resource. Technically it's still beta, and will be officially added to the cajo project soon, however there are no known issues at this time. So please feel free to kick the tyres, and take her out for a spin! Enjoy, and as always, your comments and feedback are encouraged. -John The cajo what?Posted by cajo on August 30, 2005 at 07:44 PM | Permalink | Comments (2)The cajo project is a very compact framework to enable completely transparent use, and transport of, ordinary unmodified Java objects; between Java Virtual Machines. It allows distributed computers to effectively coalesce; into a seamless, Virtual Virtual Machine. Its ease of use is undoubtedly its most intriguing feature. The foundation of its operation is its transparent method invocation mechanism. It allows dynamic interchangeability of local and remote objects, with no source impact. As a result, the framework requires no interfaces, no XML, no annotations, and works with all JREs; 1.2 and higher. This makes cajo a unique, 'drop-in' technology; which can distribute literally any application, without re-designing it. The framework applies four basic technologies; referred to as IPMB. Click on the links below, for more detailed information. Items – Remote objects: An item is an ordinary object, which is made remotely accessible. This can be done with as little as one line of code. The framework allows the public methods of the object to be invoked remotely. Proxies – Mobile objects: A proxy is an ordinary object, which is transparently duplicated inside another VM. A proxy allows otherwise remote code, and data, to be accessed locally. Multicast – Object discovery: Multicasting provides a mechanism whereby a remote object reference can be broadcast, and be received, by all listening VMs. It provides the ability to both transmit, and to receive these broadcasts. BeanShell – Object scripting: BeanShell provides an interactive, or file driven scripting environment, using pure Java. It is extremely useful; for quick jobs, experiments, and debugging. Items and Proxies integrate cleanly, as regular objects. All these capabilities, and several more very interesting classes, come in its 38kB codebase jar. It has no dependencies on any frameworks; other than a Java Runtime Environment 1.2+, and optionally, the BeanShell jar. The java.net community really works!Posted by cajo on August 19, 2004 at 06:44 PM | Permalink | Comments (0)Some of you may know me as the host of the cajo project. In fact, the topic of my blog entry today is that thanks to java.net; there are a lot more of you than I thought! I was just informed about the logger project; it allows java.net project owners to view access statistics for their projects. What I found out astonished me. So much so, that I thought it important to share this discovery with you. I started my project after a lot of introspection, (pause for geeky-Java-pun laughter :) For those of you who have not yet visited, the cajo project deals with virtualizing barriers between virtual machines; it allows objects to both interoperate, and travel between them, transparently. While implemented simply, I thought; this is sort-of abstract, and I wondered: Would anybody be interested? Well, I was amazed to find more than 25 thousand visitors, just this year. On top of that, over 350 thousand page views this year. I never expected anything like this! (Some must be search engine hits, but unless Google got infatuated, it is still a lot of people) So First I have to sincerely thank all of you who came to visit. Now instead of wondering: Will anybody notice? I am starting to think that this is an idea with some real peer-reviewed merit. I truly hope this project helps you; and I am very glad to be of help. And oh yes, please, spread the word! Secondly, I am also delighted to have the opportunity to bring this idea to so many interested people! My deepest thanks to Sun, who made this possible; with this site, and through the development of Java; both at no charge! You have given the little developer all the tools of the big-guys, and as result; a real chance to make a difference.
Thirdly, for those of you thinking; is my idea good enough to be a project? There is only one way to find out; please try it! For those of you already running projects, if you have not already; please check out the logger project, it has very interesting information. And finally, as dutiful project leader: for those of you who have not yet visited the cajo project; please give it a look. The odds seem promising that you will find it enlightening.
Inside the World Wide Virtual MachinePosted by cajo on August 01, 2004 at 10:08 AM | Permalink | Comments (0)As I mentioned in my previous blog, the World WideVirtual Machine is a very exciting free space for the development of robust scalable fault-tolerant distributed applications. The cajo project is a small free framework defined to simply and easily realize this vision. Its reception by the java.net community has been both strong and positive. So in response to this, I thought it would be worthwhile take a little time to explain the philosophical concepts of the WWVM. For the developers of the World Wide Virtual Machine, there is a fundamental viewpoint, which can be stated as follows: The network is a vast collection of objects, ready to be used to create other objects.If you stop to think about it, this is not too different from what exists in a typical single Virtual Machine design: There is the runtime library, and a collection of other local objects, both used to create applications. In fact, any application can be defined as follows: An application is an object, which itself is composed of, a collection of objects.As you can see, the WWVM is not a really large conceptual jump, especially considering all the exciting possibilities it enables. So let's take a look at some more WWVM fundamentals. It has been stated that an application is a collection of objects, and it has also been stated that the network is a collection of objects; so necessarily the WWVM must have a very clear definition of what an object is:
In the WWVM there are no primitive types per se; such as char and int. These are considered purely special case optimizations, of value solely within a local Virtual Machine. Also there is no inheritence of network objects. The WWVM focus is solely on the use of objects, by objects. Distributed objects are used solely via their public method interface. The following security philosophy is inherent in the WWVM: It is expected that all proxy objects will be hosted in a JNLP/Applet-type sandbox.This makes the development and use of the WWVM no more risky than using ordinary applets, or WebStart applications; in fact, proxy codebases are typically unsigned. In other words; using the WWVM is safe. At the cajo project, we are delighted to welcome new developers into the WWVM. It is a fascinating free environment that will only grow richer with greater participation. We welcome you to come look inside. It really does create some very exciting opportunities for an entirely new type of Internet. (And of course, it also works equally well for the development of powerful distributed LAN applications :-) The World Wide Virtual MachinePosted by cajo on March 17, 2004 at 08:29 AM | Permalink | Comments (4)Disclaimer: This entry is in no way meant to slight the many other fine distributed frameworks out there. Its just that this one is designed for us non-rocket scientists. :-) I host a free project here on java.net called the cajo project. It allows any Virtual Machine to easily expose access to any of its selected objects to Remote Virtual Machines, as well as to send any of its selected objects to RVMs. It offers a very simple yet highly flexible framework for applications to work together. Most importantly, any existing object can be made remotely usable, with no changes to its source; an application simply adds this framework, not restructures around its requirements. I have found this unique amongst distributed frameworks. A client can obtain a remote reference to an exposed object in one of two ways. It can request one explicitly, using just the name of the server, and the name under which the exposed object is registered, if it knows these things. In the framework, this is called static binding. It can also listen for object reference broadcasts, sent from RVMs. This is called dynamic binding. The references can then be freely shared in turn with other remote objects. Exposing an object for remote reference is done conversely; it can be bound locally under a name, or be broadcast to all listening VMs, even both. Clients can invoke the remote objects methods, and receive the resulting return, just as though it was a local object. How does the client know how to use a remote object? The object can implement a getDescription() method, it would provide detailed usage information. The object often implements a getProxy() method, it would generally return a graphical user interface component with which to interact with the remote object. The framework also features a standard generic client, which can be run as applet in a browser, or as an application via JNLP, to remotely host the GUI component. Any VM can send an object (or remote object reference) to an RVM, as an argument to one of its methods, or by returning it as a method result. The objects will physically exist locally in the RVM, i.e. in the same address space, as its own objects. These objects are known as proxies in the context of this project, as they exist to act in a remote location, on behalf of their sender. The previously mentioned the getProxy() method is used to return a GUI proxy object. The framework borrows from the best concepts of Jini, CORBA, and DCOM, but it is far smaller, as powerful, and much simpler to use. The core framework consists of only two packages; a total of only 13 small class files. It can be so small and easy to use, as it does not impose any application semantics beyond those outlined above. It comes with a detailed example file, ample documentation, and several support fora. It is completely free, licensed under the GNU LGPL, to allow both free and proprietary applications to operate together. The framework is currently running on all Java Runtime Environments; J2EE, J2SE, and even J2ME. It is in active use on Linux, Windows, Solaris, and OSX systems. The goal of the project is to foster the creation of a WWVM. This is an exciting shared space of applications and object libraries, where they all appear and are used as though they were local, to foster the creation of new dynamic, interactive application networks. All VMs are free to join, from big mainframes, to tiny PDAs. (You can use any JVM compatible language, even Java) Please come visit the WWVM community, all are welcome. Participants needed. :-)
| ||
|
|