Changes for Release 0.1.7

• Actor Extension Mechanism
• osl.service.Service and Service Invocation
• Miscellanious
  • New YP service features
  • Status Window Close Button
  • Makefile Dependencies
  • Mark's Mystery Project
  • Foundry Manual
• Bug Fixes
  • Constructor Exception

• Actor Extensions: I've decided to junk the osl.manager.ActorExtension interface in favor of a more dynamic approach. Previously, implementations which wanted to provide extended services to an actor could do so by extending ActorExtension. These extensions are presented to the user actor as an object reference, making them directly accessible. The main problem with this approach is that it doesn't work very well if the set of services needs to change at run-time. This is the case for the meta-level stuff I'm working on, and will probably be the case for any agent work based on the foundry. So, I've decided to go with a registration approach where an actor implementation must register a local method before it can be accessed by an internal actor. The registration function is in ActorImpl:

    protected void registerExtension(String extensionName);
  

  Note that it is protected so that only extensions of ActorImpl can register new methods. You register a method by calling this registerExtension with the name of the method. For example:

    registerExtension("foo");
  

  registers the method foo which must be defined in the run-time class of the ActorImpl which receives the call. User actors access these methods by using the method Actor.extension(...) which takes a String naming the extension to invoke, and from zero to twenty Objects which will be used in the extension invocation. The Java reflection packages are used to automatically select the correct registered extension and invoke it, returning any value to the caller. The ExtensionException class is a container for any exception thrown during the invocation.

• osl.service.Service and Service Invocation: There are two big changes for foundry services. The first is that osl.service.Service is now an abstract class rather than an interface. This had to be done so that we could support the second change, which is an alteration of how services are invoked. The service invocation interface has been changed so that it is easier for services to offer a variety of different functions. In the old version, there was only the serviceInvoke method with the prototype:

    public Object serviceInokve(Object arg) throws ServiceException
  

  While this works fine for simple services, anything which takes more than a single argument is kind of a pain to handle. The programmer is also forced to demultiplex arguments in cases where a service may export several different functions. The new service invocation interface is very similar to the new version of actor extensions described above. The new prototype in Service is:

    public Object serviceInvoke(String method, Object[] args) throws ServiceException
  

  where method names a method to invoke in the service, and args is an array of arguments to pass to the method. As with actor extensions, service implementations must "register" their service methods in order to export their behavior. Registration is done by calling Service.serviceRegisterMethod. For example, the YP service registers two methods as follows:

    serviceRegisterMethod("ypLookupRemoteManager");
    serviceRegisterMethod("ypMapActorToManager");
  

  The user-accessible version of invokeService now has a structure similar to extension. The canonical prototype is:

    Object invokeService(ServiceName, Method, [ Arg1, ..., ArgN]) 
      throws ServiceNotFoundException, ServiceException
  

  where N goes as high as twenty. The method Service.serviceInvoke is hardcoded to use the reflection packages to automatically look up and invoke the appropriate registered method in the service. Any result is returned back to the caller as usual, with ServiceException wrapping any errors. See osl.exmaples.remoteping.PingBoot for an example of the new syntax in action. Unfortunately, service invocations may be called from several areas within the foundry, so this change had to be propagated to ActorManager, ActorImpl and Actor. In short, some of your stuff may brake now (needless to say, you'll definitely have to rewrite any services you may have implemented).

• Miscellanious:
  • New YP service features: The YP service is now capable of mapping an ActorName to the ActorManagerName of the manager which currently manages the actor. Going along with the changes in service invocation described above, the YP service exports two methods:

    •   ActorManagerName ypLookupRemoteManager(String hostName)
      

      Returns the ActorManagerName of the manager running on the node given by hostName, which may be an IP or text-based host name.

    •   ActorManagerName ypMapActorToManager(ActorName actor)
      

      Returns the ActorManagerName of the manager currently managing the actor with name actor. Note that this information may be stale if actor is capable of migration.

  • Status Window Close Button: Thomas the Dane has provided a patch which adds a "close" button to the status window (which pops up if you don't specify the -nowin option). This button closes the status window without shutting down the foundry node. Also, all the stuff that is normally displayed in the status window is now logged to the "System" log as well (i.e. STATUS_DIR/foundry/logs/System).

  • Makefile Dependencies: Unlike other compilers, javac doesn't provide a way for building dependency targets in make files (a la gcc -M). I toyed with the idea of writing a JavaCC based tool which would do just that, but fortunately someone else already did it for me. I used JavaDepend (see http://pluto.njcc.com/~slinky/land_of_science.html) to build dependency targets for all of the foundry packages. The dependencies are set up so that only one `make' is required after a source file is changed (rather than the previous scheme where you either had to do a `make clean', or figure out which dependent files would need to be recompiled). I don't want to require JavaDepend (and jgl from ObjectSpace) to be installed in order to compile the foundry, so the dependencies will be hardcoded into each new release (as opposed to providing an explicit `make depend' target). Developers are responsible for adding their own dependencies to the code, although this will be done for them if an extension becomes a part of the official distribution.

  • Mark's Mystery Project: Removed the osl.manager.adl package from the distribution. Doesn't make much sense to put thesis research junk in the pristine distribution.

  • Foundry Manual: The Foundry manual is now about ten pages long. About the only thing useful at the moment is the chapter 2 "Hello World!" example. Hopefully I'll get more time to work on this in the near future.

• Bug Fixes:
  • Constructor Exception: Fixed a minor bug which incorrectly reports an ArrayIndexOutOfBoundsException rather than the expected NoSuchMethodException. This bug would pop up if you tried to instantiate an actor which didn't supply a default (i.e. no arguments) constructor.