During this exercise you will work with AWED's implementation which is part of the distribution JAsCo. The goal of this exercise is threefold:
This exercise presents a class test.Messenger. This class basically implements a shell that supports three commands represented by three keywords. The pair of keywords active and inactive change the state of the client (active/inactive), the keyword Exit exists the client. The client reads input from the keyboard.
Using aspects the basic shell is extended to implement a simple chat client that communicates using multicasting with other clients. Using remote pointcuts the aspects listen to what is written in remote clients and print it on the screen. The files test.MessengerAsp.asp (the aspect definition) and test.MessengerCon.con implement the described solution.
The files that implement the solution are presented here:
The objective of this part is to present a more complex problem involving remote sequences by implementing an extension of the previous exercise. Your aspects should now implement a client that only listens to other clients when it is active.
The files that implement the solution are presented here:
The third part of this lab consists in implementing replication using AWED on top of JBoss Cache.
A brief overview of JBoss replicated caching. JBoss Cache is a replicated transactional cache, i.e., the coherence of the data in the caches forming a common cluster is ensured by guarding updates using transactions. A JBoss cache can either be configured to be local, in which case no data is replicated to other caches on other machines, or it can be global, which means that all changes are replicated to all the other caches (on all other machines) that are part of the cluster.
The replication concern in JBoss Cache is crosscutting: it is scattered over large parts of its implementation and tangled with other scattered concerns. Understanding of the existing code as well as modifications of the standard behavior of JBoss Cache are hindered by this crosscutting.
The main class that represents the data structure used to store data is TreeCache (that implements a tree :-)) located in the package org.jboss.cache. An instance of this class stores the cache contents on a specific machine.
To separate crosscutting concerns from the main code JBoss Cache uses interception filters, an AOP-like mechanism used to redirect a method call to other functionalities: for example, once a TreeCache instance receives a call to the method put to store a datum in the cache, a MethodCall object is created and passed the object through a chain of filters, each of which treats a crosscutting concern, e.g., replication or transactions. Even though the concept is clean in practice the solution still results in tangled code. The filters are located in the package org.jboss.cache.interceptors.
The files that implement the solution are presented here: