John Catherino's Blog: Patterns Archives

Posted by cajo on June 19, 2008 at 06:58 PM | Permalink | Comments (10)

What is the fundamental premise of messaging, and how is it different from RPC?

Essentially, messaging focuses on the concept of loosely coupled, event/information delivery; between one or more producers, and one or more consumers. RPC focuses on the concept of tightly coupled synchronous functional invocation; between a client and a server. What would happen if we applied cajo technology to coalesce these two concepts?

This is precisely what the newly updated cajo Queue class does. Queue instances are initially constructed by providing a topic object. This object is a mutually agreed upon class, between producers and consumers, which provides the context for why the community is using this particular Queue instance. For example: the topic object could be something as simple as a string – "Wine Enthusiasts" or as elaborate as a HashMap of subtopics and values.

Consumer objects can be either local or remote to the JVM in which the Queue object is operating, and register using its enqueue method. Producer objects can also be either local or remote, and create events by invoking arbitrary methods on a Queue object reference. These invocations return immediately for producers; and are asynchronously invoked on all registered consumers. The invocation's successful return to the producer, guarantees that the event has been accepted. As the object's name implies; producer invocations are queued, as necessary.

For example:

// Producer actions: queue.ping(); // invokes the method ping() on all consumers queue.position("37.391008, -122.082073"); // new location queue.fill(x, y, width, height, Color.red); // mask area // note: queue does not implement any of these methods itself // they are invoked on the consumers, only if they support them

The real gist of fusion takes place in the concept of method invocation on the Queue object. A producer may invoke a method taking no arguments; this is traditional notification messaging. A producer could invoke a method taking a single argument; this is traditional data messaging. Finally, a producer could invoke methods taking multiple arguments; this is traditional RPC, but loosely coupled, i.e. functional messaging -- exhibiting three key features:

* The function signatures are independent of any class or interface definition
* The potential one-to-many relationship, between the producer and its consumers
* The consumer is not required to implement the functions being invoked by the producer

The Queue class performs the consumer invocations asynchronously from the producer's; it discards any direct return values, and exceptions from the consumers. Therefore, if the producer wanted feedback from consumers, it could provide a callback reference as an argument, for example.

If there is only one producer, and one consumer, this is what is commonly referred to as point-to-point messaging. When there is one or more producers, and more than one consumer; this is what is commonly referred to as publish/subscribe messaging. With the Queue class approach, these are just variations in how the object is used.

Lastly, just for fun, the Queue class is serialisable, meaning Queue objects can be passed between JVMs at runtime, (i.e. cloned) whilst retaining all producer and consumer links. The possibilities created by this, are nothing short of mind-boggling. ;-)

Best of all, Queue is implemented in a single class, consisting of less than 100 lines of code. I recommend giving it a try; it is extremely simple to use, highly intuitive, and very powerful. It is a handy new tool, to add to your kit.

Enjoy,

John

Dynamic Client Subtyping

Posted by cajo on December 07, 2006 at 08:44 PM | Permalink | Comments (0)

Given the enthusiastic feedback to the Take That .NET! blog entry; I thought I might expound a bit upon a small, but highly important bit, at the end of the example.

Oftentimes service objects implement a large, rich interface. Other times service objects implement several interfaces, grouping their functionality into distinct logical concerns. Quite often, a client needs only to use a small portion of an interface; or perhaps some methods from a few of the logical grouping interfaces, to satisfy its own needs.

The ability of a client to define its own interface, from ones defined by the service object, is known as subtyping in Java. (in contrast to subclassing) However, unlike conventional Java subtyping; Dynamic Client Subtyping means creating an entirely different interface. What makes this subtyping dynamic, is that it works with the original, unmodified service object.

This can be a very potent technique, for client-side complexity management.

Doubtlessly, an example would help.

Assume we had a service object representing an auto manufacturer, and it implements several interfaces in its own package; say auto.perspectives:

public interface Physical {
   Location currentLocation();
   Terms shipTo(Location location);
   Petrol petrolRequirement();
   int kilogrammes();
   int litresPer100kilometres();
}
public interface Visual {
   Colour colour();
   Image image();
}
public interface Financial {
   int costEuro();
   Set<Terms> terms(int downpaymentEuro);
}
public interface Advert {
   String description();
   int modelYear();
}
...

Then assume it had an implementation class in some other package; say auto.products:

public class AutoX implements Physical, Visual, Financial, Advert... {
   ...
}

Now let's assume a client, perhaps an auto broker, needed only a small portion of this. It could define its own interface, i.e. a subtype, in its own package; say broker.info:

public interface Commission {
   Location currentLocation();
   Terms shipTo(Location location);
   Colour colour();
   int costEuro();
   Image image();
   String description();
}

An extremely useful feature of the cajo project is that it allows ordinary objects to be used between Java Virtual Machines, exactly as they are used locally; without modification.

Assume we have an auto reference:

Object auto;

Suppose when the auto object is local to the client JVM:

auto = AutoFactory.selectAuto(Details...);

If the auto object is in a remote JVM:

auto = Remote.getItem("//somehost:1198/someAuto");

In either case, the auto object reference is customised thus:

Commission commission = (Commission)TransparentItemProxy.
   getItem(auto, new Class[] { Commission.class });

Now it will work exactly as you would expect:

System.out.println(commission.description());

Enjoy,

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.

Inside the World Wide Virtual Machine

Posted 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:

An object has 1 or more public methods,
An object has 0 or more non-public member objects,
An object's public methods interact with 0 or more private member objects, with 0 or more argument objects, to return 0 or 1 result object; or to throw an Exception.

In a single-VM design, there is only one general category of object: local ones. These run in the address space of the host VM. However, in the WWVM there are three fundamental object categories:

Local Objects: existing in the local VM address space.
Remote Objects: existing in the address space of a remote VM, linked by the network.
Proxy Objects: existing in the local VM address space on behalf of a remote VM, and may (or may not) be communicating with it.

Each of these objects, being fundamentally different, are obtained in different ways:

Local objects are instantiated, either via a new or newInstance method invocation; or are deserialized from an ObjectInputStream.
Proxy objects are obtained via a remote object method result, or exception.
Remote objects are obtained via a request from a remote VM; or via a remote VM broadcast. (sometimes called listening to radio station WWVM :-)

While each category of object is used identically syntactically; the objects themselves exhibit fundamental properties, based on their category:

A local object can be passed to a remote object, only if allowed by both sides, where it will exist there, as a proxy.
A remote object reference can be freely passed between all objects and Virtual Machines.
A proxy is unique to the runtime in which it exists, and cannot be passed to another VM.

Objects are passed to other objects, either as method arguments, method returns, or in method exceptions. A proxy may even provide a distributed user interface, by instantiating a Window, as needed, at its hosting VM.

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 Machine

Posted 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. It’s 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 object’s 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. :-)

Powered by
Movable Type 3.01D

java.net RSS Feeds