lunedì 26 luglio 2010

It took very much time to get to the new alpha release of the Aglets Mobile Agent Platform. The version is the 2.5, that creates an hole between the previous one, 2.0.2, but since there are so many improvements the I decided to make it clear that this is a version that has touched almost every part of the platform.

There are important changes, the much visible of which is the new GUI that is based on Swing and no more on AWT. The GUI has not been simply converted from AWT to Swing, but it has also been restructured in order to be simpler and more friendly to use, as well as of course include the new features.

Behind the hood, the platform now supports the sleeping of an agent in a manner similar to Thread.currentThread().sleep(), and a lot of classes have been adjusted to be type safe and better organized. This means that Aglets now requires a newer version of Java, in particular at least J2SE 6. The reason for that is the adoption of a fully integrated localization system that is based on J2SE 6 Resource Bundle, wrapped in an AgletTranslator object that allows the user, as well as agents, to get localized texts and icons.

Other improvements are related to the general management of the internal data structures, that has changed from slightly to deeply depending on the case.

You can download a zip archive containing the alpha release from here.

I will thank everyone that assisted me in this long process, and I will apologize for this late releasing.

This release makes also the old web site to become unavailable, relying instead on the default Sourceforge web content (as shown below). The reason for this is that the old site was still linking the AgentGroup @ Unimore, that didn't help me within Aglets and, in fact, copied and paster part of my work within this project releasing it as their own! It is evident if you see the papers related to Aglets: the first in the list ((Leveraging strong agent mobility for Aglets with the Mobile JikesRVM framework. Scalable Computing: Practice and Experience) contains parts of the second article (Strong Agent Mobility for Aglets based on the IBM JikesRVM) that was written before with my contribution. So to get it short, I removed the web site with all references to Unimore. The following is how the site was appearing and how it appears now.

giovedì 22 luglio 2010

WhiteCat includes the concept of role descriptors it inherited from its precedessor, BlackCat.
A role descriptor is a layer of meta-information around a specific role implementation. The idea is that an agent can deal with a role descriptor in order to see what the role aims are, which operations the role provides and which events each operation will generated and/or receive. As readers can see, a role descriptor is not a single complex and big object, but a set of nested small objects each one tied to a specific piece of role information. This means that a role will have a RoleDescriptor as its top descriptive object, and the latter will contain one or more OperationDescriptor, that in turn can contain one or more EventDescriptor. This is the structure of role descriptors in BlackCat, that has been rewritten almost equally in WhiteCat.
In the last couple of commits I've changed this structure to a more flexible and powerful one. First of all, a role descriptor does not have anymore operation descriptors, but "task descriptors". A task descriptor describes a task (e.g., a method call). Most interesting is the Task itself, an interface to allow the composition of method calls and other tasks in order to obtain a very complex executional unit. Having the task abstraction, a role description now contains pure executable objects that will do a method call (or a method call chain) on a specific role. The task descriptor is useful to allow the agent to better understand the meaning of a task and to select it before it is executed. So the main difference between the BlackCat role descriptors and the WhiteCat ones is that in the new version the role descriptor contains also executable code as a task definition, as well as its description. The event descriptor has been kept unchanged, except that since the first version of WhiteCat it explicitly specifies if the event is incoming or outgoing.
A task can be executed or composed with another task, and this allows for a great reusability as well as modularity.

Another importan change is that now WhiteCat allows for annotation based descriptors: the role developer can annotate his role with special annotations in order to allow the system to infer the role descriptor automatically. The system now includes a interface, called IRoleDescriptorBuilder, that can analyze a role implementation (IRole) and create the descriptor depending on the annotation values.
This integration has several advantages, the most important of which is that the developer can write a single file (the role class implementation) letting the system to infer the role descriptor and the tasks. Of course, this can be overridden by a formal role descriptor expressed, for instance, as XML.

I've merged other two branches within the WhiteCat project and published them on the public available SourceForge repository.

These changes involve the locking mechanism and the role repository. The latter has been refactored in order to keep advantages of the Spring configuration. Spring is taking more and more space within WhiteCat, as demonstrated from the removal of the old Configuration class.

The locking mechanism has been completely rewritten. The locking is a mechanism that allows the role developer to mark (annotate) a proxy method in order to avoid its execution while the proxy itself is undergoing role manipulation. This is useful in order to avoid critical races on proxy mutators. The locking is managed by the ProxyStorage, that is an object that keeps track of all available proxy instances and their manipulation status, providing support for getting the last-updated proxy with a specific proxy identification. The locking mechanism is implemented with an AspectJ aspect that, before the execution of a locked method (i.e., a method with the @Lock annotation), consults the proxy storage in order to see if the proxy is going under manipulation, and in such case can (i) delay the method execution or (ii) avoid the method execution throwing an exception. Each time the role booster starts a role manipulation operation it instruments the proxy storage to lock the proxy, so that the system is aware that the above proxy is going to be manipulated by a proxy. The proxy storage has obtained a "make up" and now stores a wrapper object, called the ProxyStatus, that contains the last manipulated instance of the proxy, some statistics (e.g., how many time it has been manipulated) and a locking object, that is the one the locking mechanism relies on. This means that each proxy has its own locking object, that is used to synchronize Java threads.

Finally, there is a new JUnit test that demonstrates and tests the locking mechanism itself.

According to the Ohloh code metrics, WhiteCat is extremely well commented: comments are at 62% of the project and this makes WhiteCat in the first 10% Java projects in Ohloh for code comments.

Well, this does not mean that WhiteCat is a good system, but that its development has been done (until now) in a very disciplined way. And this is particularly importan for OpenSource projects, because a good and clean documentation helps new users/developers to join the project itself.

The following is the quote from the Ohloh site:

Across all Java projects on Ohloh, 32% of all source code lines are comments. For WhiteCat, this figure is 61%.
This very impressive number of comments puts WhiteCat among the top 10% of all Java projects on Ohloh.

venerdì 16 luglio 2010

Today I pushed a little octopus merge (three branches) I have developed during last nights. This commit introduces a new set of features in the WhiteCat framework; such changes are for a long term view of the project and do not touch heavily the user's interface.

First of all now there are a few JUnit tests that, besides testing the framework, can be used as examples for understanding how WhiteCat internally works and how facilities and APIs should be used.

Then comes the support for a customizable proxy cloning. In the past, when a role manipulation was completing, WhiteCat invoked the updateProxy method on a proxy handler in order to copy the proxy status from the old instance to the new one. This works fine if the proxy and the proxy handler are tied together, since the proxy handler will not copy any "extended" status it is not aware of. This is fine for WhiteCat to work, but is not useful for a developer that wants to develop its own proxy class. To solve the problem a new interface has been added, ICloneableAgentProxy, that if applied to a proxy instrument WhiteCat to clone the old proxy instance. Please note that the cloning is manual, that is on the proxy developer, since it is not possible to use the standard Java cloning methodology since this will not allow WhiteCat to work and manipulate proxy classes. To summarize, if you have defined a new proxy and want to keep its internal status, use the ICloneableAgentProxy interface and implement the cloneAgentProxyState(..) method to control the copy field by field.

But how can a developer install his own proxies in the system? Here comes another interesting new feature: WhiteCat now can be fully configured using Spring! This means that the old configuration, based on properties, is no more used (and is deprecated) and it is possible to specify exactly which classes instances should be used as proxy handlers, agents, and even as role booster (so this means you can implement your own!). Of course, introducing Spring lead to a deep refactoring of the main internal structures in order to support dependency injection. The result is that now there are a lot of different interfaces, one for each configurable component.

There is now also a unique factory, implemented by the WhiteCat class. This is not a way to remove factories for configurable objects, but to have a single entry point to get an object instance. The idea is that each object should be created by its factory, and the factory itself should rely on Spring, while the WhiteCat class exposes a common interface to all the factories.

Finally, the most difficult change, is the introduction of a RoleOperation, a wrapper around all role manipulation informations (which agent, which proxy, which role, etc.). This is deeply used by the current role booster implementation, and this means that the booster is now instrumented by such role operation. This is a not fully completed implementation of the Command Pattern; it is lacking the execute command way, that could be added in the future. The adoption of the role operation abstraction opens new ways: it will be possible to fully implement a command pattern, to queue and manage multiple role operations, and to keep a track about who asked for what and what was the result.

martedì 13 luglio 2010

Today I have found an introspection problem within the Javassist library, I'm not sure is a problem of the library or of the bytecode manipulation. I found the problem while working around WhiteCat, that injects Java annotation into ordinary classes at run-time. Of course the injection works fine, but it is like the annotation is no more visible in an "ordinary" way. In fact, doing introspection against a manipulated class, I found that the annotations are there, but with a class name like $Proxy. Why is this problematic? Simply because it does not allow for a class-to-class comparison when working with annotations, and more important it does not allow introspection against the annotation itself (e.g., to get the annotations of an annotation).

The solution in order to do regular introspection is the following:

get the annotation and its toString() value;

manipulate the string value in order to get the annotation fully qualified name;

lunedì 12 luglio 2010

I committed a change to the RoleBooster that fixes a stupid but hard to find problem with the public role removal. Now the Role Booster can correctly remove a role from an agent proxy returning the "un-roled" version of the proxy.

Interestingly the Role Booster was not behaving nicely with a single role case: if an agent assumes a single role, and then wants to immediatly discard it, the booster was continuing to return the same proxy instance (or better, a new one cloned from the current one). For this reason now, when only the role interface is found on the current proxy, the instance returned is a superclass. This is fine with WhiteCat because the Role Booster guarantees that each "roled" proxy is a subclass of the starting proxy class, so the inheritance chain is growing to the bottom.