Aglets 2.5

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.

Here I post some screenshots from the new alpha release.

WhiteCat: role descriptors done right!

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.

Eclipse Helios incorpora EGit

La nuova versione di Eclipse, denominata Helios, incorpora nei repository ufficiali p2 il supporto a Git denominato EGit. Una buona notizia per chi, come me, è ormai un abitudinario dello sviluppo con questo fantastico strumento di revisione.

WhiteCat: other branches merged!

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.

WhiteCat extemely well commented

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.

WhiteCat: a little octopus merge with several features

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.

Annotation injection thru Javassist

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:

1. get the annotation and its toString() value;
2. manipulate the string value in order to get the annotation fully qualified name;
3. load the annotation class from its name thru reflection;
4. work on the obtained class.

Not really clean, but good enough for WhiteCat to work.

OpenSolaris sopravvierà?

Ho recentemente letto questo ineteressante articolo sul futuro di OpenSolaris...francamente speravo che questo fantastico sistema operativo avesse alle spalle una community un po' piu' robusta. Spero comunque che la situazione si risollevi presto!

Fixed a problem with the public role removal

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.

Componenti o Plug-ins?

Qual'è la differenza fra un componente e un plug-in? Molti degli studenti che si laureano non hanno questa nozione, eppure oggi si parla sempre piu' spesso di componenti e plug-ins, possibile che non venga insegnata correttamente? Eppure è piuttosto semplice!

Componente: un componente è una black box fatta per essere riutilizzata in diversi contesti. Il componente non ha conoscenza del contesto in cui viene applicato. Un esempio di componente potrebbe essere un logger su file: il componente sa cosa deve fare (loggare), non sa però dove viene usato (ad esempio in un programma server, in un client, in una applicazione didattica,...) e può essere esteso (ad esempio per ottenere un logger su database).

Plug-in: un plug-in è una black box che estende un componente o un altro plug-in, può essere usato in diversi contesti ma deve conoscere i contesti ove verrà usato. Un esempio di plug-in è un menù crafico che permette di accedere a determinate funzioni.

La principale differenza è proprio nella conoscenza del contesto di utilizzo: il plug-in estende in una direzione specifica e quindi deve sapere Icosa e come estendere un altro sistema.

Aglets History

Today I made a really mess with the Aglets Git repository! It happened that I pushed a not yet merged branch, because I was in a rush and my brain was outside somewhere walking...

What I was doing was converting the whole Aglets history from the old CVS repository to the Git one I created one year ago. 

Now the repository is fine again, and I've also done a few changes in some examples and classes that did not compile before.

Eclipse e "Add Java Exception Breakpoint"

Il debugging di una applicazione è un'operazione molto complessa e difficilmente pianificabile, poiché si sa quando si inizia ma non si sa bene quando si finisce.

Il debugging in presenza di errori ed eccezioni è stato reso piu' semplice nei linguaggi come Java dallo stack trace, che indica il punto in cui una eccezione si è verificata. 

Eclipse rende ancora piu' semplice la scoperta di errori/eccezioni con una funzionalità che non tutti gli sviluppatori conoscono e usano: add java exception breakpoint. Come suggerisce il nome la funzione consente l'inserimento di un brakpoint in posizione indefinita che scatta ogni qualvolta una determinata eccezione viene lanciata. In sostanza quindi si tratta di un breakpoint "fluttuante" che si attiva ogni volta che l'eccezione specificata viene generata. La funzione è quindi molto comoda per controllare il proprio codice senza dover mettere breakpoint sparsi per il progetto (o i progetti) alla ricerca del punto attorno al quale si genera l'eccezione.

Linea Mare: la solità puntualità e organizzazione

Mi sono trovato a dover venire a casa dalla riviera con la Linea Mare ATCM, un servizio molto utile e ben pensato, ma che mi è sembrato mal gestito (come altri servizi ATCM). La situazione è semplice: due autobus partono da zone differenti della riviera, si ricongiungono all'autostazione di Modena e proseguono in due direzioni diverse (Carpi e Sassuolo rispettivamente). 

Problema: i passeggeri di una o dell'altra devono poter proseguire in una o l'altra direzione, quindi lo "scambio" è d'obbligo a Modena.

Soluzione ATCM: le due corriere devono arrivare a Modena allo stesso istante per poter permettere il trasbordo dei passeggeri.

Ovviamente la soluzione non funziona: basta che uno dei due autobus sia in ritardo per bloccare anche quello puntuale, come appunto è successo a me ieri che ho dovuto attendere 35 minuti fermo in autostazione.

Con un po' di buonsenso basterebbe effettuare il trasbordo dei passeggeri in una località prossima all'ingresso autostradale della riviera, come ad esempio Cervia, in modo da poter far viaggiare le due corriere autonomamente. Alternativamente si potrebbero sfalsare gli orari delle corriere facendole passare per il suddetto "punto di concentrazione" per meglio agevolare i passeggeri.

SWT vs JFace

Il titolo di questo post è sbagliato: non può esserci competizione fra SWT e JFace, ma solo collaborazione!

E' comunque opportuno spiegare cosa siano SWT e JFace poiché noto che c'è molta confusione sull'argomento, specialmente per chi proviene dal mondo Swing (praticamente tutti gli sviluppatori Java).

SWT è una libreria grafica ad alte prestazioni. In sostanza è un wrapper JNI attorno ai componenti grafici del sistema operativo, quindi attorno a componenti nativi. Questo confluisce le caratteristiche principali di SWT: le prestazioni (al pari del sistema operativo) e il look and feel (del sistema operativo). Per sistema operativo si intende in realtà la shell grafica, e quindi ad esempio Gnome per *nix, Carbon per Mac OSX e così via. Tuttavia SWT è una libreria di basso livello, ossia non fornisce le caratteristiche tipiche della programmazione ad oggetti, ma funziona solo come wrapper attorno ai componenti grafici nativi. In altre parole una tabella SWT non è capace di interpretare un albero di oggetti da visualizzare, ma solo un array di stringhe di testo da inserire ognuna nella propria cella. Questo fa storcere il naso a chi vuole lavorare con modelli complessi e vuole le astrazioni tipiche dell'OOP. Ecco allora che arriva JFace, che altro non è che un wrapper Java attorno a SWT e che consente la programmazione attraverso modelli, handler, eventi specifici. 

Sostanzialmente quindi SWT fornisce solo il livello grafico di basso livello, ed è compito del programmatore stabilire come tradurre i propri oggetti in testo da visualizzare, mentre JFace è una libreria ad oggetti che consente di lavorare agevolmente con gli oggetti del proprio business model da tradurre in visualizzazione grafica.

Tornando all'esempio della tabella, SWT accetta un array di stringhe di testo da posizionare nelle celle, e quindi è compito del programmatore scorrere il modello per trasformare tutto in un sol colpo in un formato testo. In JFace invece si hanno degli oggetti (detti provider) che consentono di scorrere il modello in maniera piu' agevole (ad esempio conoscendo l'indice della tupla) e di fornire un pezzo alla volta la forma testuale da visualizzare. Ovviamente le prestazioni sono pressoché identiche, la separazione dei due flussi è solo concettuale. 

JFace implementa un MVC molto piu' simile a quello di Swing, ma il cuore del sistema resta sempre e solo SWT.

pfSense & OpenVPN: verify error

Se pfSense rifiuta una conessione OpenVPN con certificati fornendo un VERIFY ERROR simile al seguente:

VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: 

/C=IT/ST=Italy/L=Sassuolo/O=MySite/CN=MySite_CA/emailAddress=xxx@xxx

significa che si è fatta confusione con i certificati e che si sta usando il certificato del server al posto del classico ca.crt (certificato che garantisce quello del server) nella configurazione del client OpenVPN.