 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
 |
|
 |
|
WOPR is an experimental message-passing distributed object development framework for java.
An application developed with WOPR is organized into several customisable modules which send messages to other modules in order to communicate. A module can be viewed as a remote thread with several message queues as its inputs, and several outputs.
Because each module is independent from the others, it is possible to deploy an application over the network onto several JVMs (or machines). Furthermore, an application can be altered at runtime (e.g. to change a connection between one module and another, to replace a module by a new one, to change a module's parameter, etc).
See a simple example.
People like screenshots (so do I), so if you want to see the WOPR in action have a look at those ones. They show the example deployed on two WOPR instances.
General architecture overview
 |
Latest news
| February 28th, 2005 |
After several months of inactivity, WOPR Version 0.1.0
has finaly been released !! All points listed on the roadmap are now fully implemented. The differences between this release
and the previous one mainly concern internal stuff. The class design of the module package for example has been slightly improved
to gain in flexibility and stability.
This project was started last summer basically to experiment some image processing algorithms. I was looking for something with which I can easily define video sources, filters, etc... and then send the video output to a filter, and the filter output to another filter and so on. Something a bit like LabView you know, where you place your modules and interconnect them together. In addition, I wanted something that can be modified at runtime and, more importantly, something with distributed computing capabilities. I didn't find anything like that in the open source community so I decided to develop it myself. By the way, it was an excellent exercice since I was new to java and needed some training for my real job. I'm quite satisfied with the framework so far even though it is still a bit limited. It would need for example some serious improvements regarding the message queues, but I'm already able to experiment what I wanted to and it is sufficient for the moment. Now with hindsight, if I had to write it again, I would probably choose a different way. Instead of developing almost everything from the ground up, I would look at some very interesting frameworks like Spring or PicoContainer as well as some J2EE technologies like JMX. But I would probably not go with an application server like JBoss though. If I'm doing a bit of history, it's because I reached a point where the chances of a new update of the framework will become increasingly slim. I might port it to the new java 5.0 but it won't be before this summer, Apple is a bit slow when it comes to java, especially when a new version of their prefered (but really nice) OS is about to come... |
| November 27th, 2004 |
New sources have been released.
Well, the 0.1.0 has still not been released, but all 3 phases are now completed. The WOPR can be
fully deployed on remote machines and is now able to download missing classes from other remote WOPR
instances.
To allow download of classes from remote locations, each WOPR instance runs an embedded http server (jetty). The RMI interfaces have been updated in order to allow a client application to add to a project new URLs. By using URLs, not only is it possible to point to WOPR embedded http servers but also to standalone servers. I've added a new ant project: wopr-library. It is intended to contain all concrete modules like the standard ones (e.g. NodeModule) as well as the example modules. I've also moved all the test classes to a new ant project: tests. By doing all those changes the ant scripts are simpler and the whole project is easier to maintain. The seperation of the concrete modules from the main jar will give the possibility to launch 'thin' WOPR instances, that is instances with only the minimum code needed to run empty, and then download the required classes if a project is loaded. Last but not least, I've added some shell scripts in the 'bin' directory to make the launch of the different applications (wopr, cli and rmiregistry) easier. However, WOPR is developed on UNIX (Mac OS X actually) and the scripts have only been written for UNIX. Support for Cygwin and Windows batch file will be added later on. |
| October 17th, 2004 |
New sources have been released.
To prepare the implementation of the last part
of phase 3 (upload classes and resources to remote WOPRs), I've done some
refactoring. The most significant change is the move of the external layer from CORBA
to RMI in order to take maximum advantage of the language.
Among other changes, the access to the RMI registry is now done through JNDI and is fully configurable. I'm not really happy with rmiregistry though since it only supports a flat namespace. A hierarchical name structure like in the CosName service is far better when you have to deal with a large amount of objects. But as long as I don't have to manage too much modules, rmiregistry is sufficient. I've improved the ant scripts as well, so it is now possible to compile and deploy everything from the root directory. Now if everything goes well the next release will include the last part of phase 3 and will by the way close the development of the first version which will be 0.1.0. |
| Sept. 20th, 2004 | The example has been updated and now reflects the example provided with the source distribution. There is a description about how to run the example in the file .README. |
| News archive | |