Mop 1.0-m1

If you're a Maven user, or better yet if you're a user of software that is published in a Maven repo, checkout Hiram's Blog post on Mop. Mop is a cool utility that downloads and executes Java apps (and all of their dependencies) from Maven repos.

MeshKeeper 1.0-m1 released!

I'm please to introduce our first milestone release of MeshKeeper!

MeshKeeper is a platform of services that allow Java applications to discover, launch, coordinate, and control remote processes across a grid of computers.

My colleague Hiram Chirino and I developed MeshKeeper to assist us in creating robust distributed tests for Fuse Message Broker based on ActiveMQ. We wanted an easy, dynamic and platform agnostic mechanism for distributing test objects around a grid of machines.

At the most basic level MeshKeeper is process launching framework. It consists of a MeshKeeper control server and any number of agents listening for requests to launch processes:

At the process launching level, MeshKeeper gives you the ability to discover agents and allows you to launch, monitor and destroy processes in your grid. We've tried very hard to make getting started easy. From an application standpoint all you need to do is include the MeshKeeper api jar on your classpath, and you can start launching processes. MeshKeeper will deploy an embedded control server and launch agent under the covers.

But that is just a small piece of what MeshKeeper provides. The MeshKeeper API provides several different interfaces that allow you to easily work with distributed java components:

Check out the MeshKeeper website for examples relating to these interfaces (some not done yet :))

• Launching: Allows you to launch processes in a platform neutral fashion throughout the grid. This also provides mechanism for distributing your local classpath to remotely launched java applications.
  
• Remoting: Allows you export java objects in the grid and let's you perform RMI style invocation on them
• Registry:Allows you to discover registered objects or data in the grid (quite powerful when combined with Remoting)
• Eventing: Once you've distributed your objects in the grid, Eventing helps you coordinate their activity.
• Repository: Let's you distribute artifacts (files, jvms etc) in the grid for use by distributed components.

MeshKeeper also provides a really lightweight container that allows you to host your java objects on target machines.

I could go into a lot of detail about each of these, but for the sake of brevity once it's all put together you can do things like:

public static class MyClass implements Serializable{  public Properties getSystemProperties()  {    return System.getProperties();  }}public void hostMyClass() throws Exception{  MeshKeeper mk = MeshKeeperFactory.createMeshKeeper();  MeshContainer container = mk.launcher().launchMeshContainer("fastbox");  //Returns a proxy version of my class using MeshKeeper Remoting  //support:  MyClass myClass = container.host("propFinder", new MyClass());  //We can use the proxy to print the system properties on the  //target system.   myClass.getSystemProperties().list(System.out);    //If we don't need it anymore unhost  container.unhost("propFinder");  container.kill(); }

In the above snippet, we create a MeshContainer on the agent machine called "fastbox" using your application's classpath. We then host MyClass in the container (under the covers using Remoting) ... the only requirement is that MyClass be Serializable. Once it's there we can invoke methods on it just as if it were running in our own jvm! In this example we simply get the host machine's System properties and list them locally.

Anyway, give MeshKeeper a try and let us know what you think!

RMI vi JMS 1.0

Hiram just released RMI via JMS 1.0! Check out his blog post here. It takes regular old java.rmi, and makes it much easier to use. I find regular rmi to be pretty irritating since it requires your remoted objects to implement the Remote interface and throw RemoteExceptions. RMI via JMS loosens up these restrictions making it easier to convert your existing application interfaces into remote ones.

And as Hiram points out it throws in a bit of ASM trickery through cglib, so you don't even have to export your classes with interface specifications to begin with (though it's probably still a good idea to do so).

Beyond that it allows asynchronous method invocations with the use of rmiviajms's @oneway annotation.