Tout un travail de spécification a commencé pour définir :

• les nouveaux besoins pour pouvoir adapter le produit à leurs clients;
• les interfaces et les flux d’échange entre les deux solutions.

Dès que les premières phases de développement sont finies, nous avons commencé les premiers tests d’intégration. Premier constat : Aucune variable de session n’est sauvegardée. La raison était que nous testions avec Internet Explorer, qui lui et depuis sa version 6, bloque les cookies contenus dans les en-têtes HTTP se chargeant à l’intérieur d’IFrame.

En effet, IE implémente ce qu’on appelle la “Platform for Privacy Preferences” ou P3P. P3P est un standard W3C qui permet aux sites Web de définir leurs politiques de protection de données personnelles de façon standardisée et structurée compréhensible par les machines (donc les navigateurs implémentant le standard). L’internaute, en définissant les paramètres de confidentialité au niveau de son navigateur, permettra ou pas à ce site web de collecter des informations, d’accepter des cookies…Ce système a beaucoup de limites qui ne font pas l’objet de ce post. On s’intéresse plutôt à résoudre la problématique : comment faire si votre application web est contrainte de tourner dans une IFrame ?

Vous l’avez donc compris, la configuration par défaut au niveau d’IE bloquera votre cookie si vous vous ne déclarez pas en tant que site de confiance. Selon les spécifications, votre politique P3P peut être communiquée sous deux formes : la forme compacte et la forme complète. La forme complète implique la description de la politique sous format XML, décrite dans un fichier que les navigateurs implémentant le standard iront chercher sous w3c/p3p.xml (emplacement par défaut pouvant être redéfini avec une balise link). La forme compacte implique la description de la politique en envoyant un entête HTTP (associé à la réponse avec laquelle vous essayez d’envoyer le cookie). La clé de cet entête est : “P3P”. Sa valeur est une succession de codes abrégés. Sans rentrer dans les détails de ces codes bien expliqués dans les spécifications, pour permettre à IE d’accepter vos cookies même si votre site web se charge à l’intérieur d’une IFrame, la valeur de cet entête devrait être : CP=”IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT”.

Exemple : Si vous développez une application web Java, pour ajouter cet entête dans une JSP, il faudrait ajouter la ligne suivante :

<% response.addHeader("P3P","CP=\"IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\""); %>

Eliminate consecutive duplicates of list elements.
If a list contains repeated elements they should be replaced with a single copy of the element. The order of the elements should not be changed.
Example:
user> (compress ‘(\a, \a, \a, \a, \b, \c, \c, \a, \a, \d, \e, \e, \e, \e))
(\a, \b, \c, \a, \d, \e)

(defn compress "P08" [xs]
  (reduce #(if (= (last %1) %2) %1 (concat %1 (list %2)))
  ‘() xs))

The reduction function would check if the last element of its first argument equals its second argument, which would be the element of xs being processed. It the they are equal, it would just return the first argument as is, otherwise it would add the xs element to the end of the first argument list and return it.

Here’s how it would work on the characters list shown above:

(’() \a)=>(\a) because \a and (last ‘()) which is nil are not equal
((\a) \a)=>(\a) because (last (\a)) which is \a is equal to the second argument \a
:
:
((\a) \b)=>(\a \b) because \a and \b are not equal
:
:
((\a \b \c \a \d) \e)=>(\a \b \c \a \d \e)

P09

Pack consecutive duplicates of list elements into sublists.
If a list contains repeated elements they should be placed in separate sublists.
Example:
user> pack(’(\a, \a, \a, \a, \b, \c, \c, \a, \a, \d, \e, \e, \e, \e))
(\a, \a, \a, \a), (\b), (\c, \c), (\a, \a), (\d), (\e, \e, \e, \e))

(defn pack "P09" [xs]
  (reverse (reduce
   #(if (= (ffirst %1) %2)
      (cons (cons %2 (first %1)) (rest %1))
      (cons (list %2) %1 ))
   ‘()
   xs)))

P10

Run-length encoding of a list.
Use the result of problem P09 to implement the so-called run-length encoding data compression method. Consecutive duplicates of elements are encoded as tuples (N, E) where N is the number of duplicates of the element E.
Example:

user> (encode ‘(\a, \a, \a, \a, \b, \c, \c, \a, \a, \d, \e, \e, \e, \e))
((4,\a), (1,\b), (2,\c), (2,\a), (1,\d), (4,\e))

(defn encode "P10" [xs]
  (map #(list (first %) (count %)) (pack xs)))

This solution reutilizes the pack function defined in the previous problem. Once the list of items is packed, we map every element (which is a list) to a pair defined by any item of the list, the first for instance and the list’s length.

P11

Modified run-length encoding.
Modify the result of problem P10 in such a way that if an element has no duplicates it is simply copied into the result list. Only elements with duplicates are transferred as (N, E) terms.
Example:

user> (encode-modified ‘(\a, \a, \a, \a, \b, \c, \c, \a, \a, \d, \e, \e, \e, \e))
((4,\a), \b, (2,\c), (2,\a), \d, (4,\e))

(defn encode-modified "P11" [xs]
  (map #(if (= 1 (last %)) (first %) %) (encode xs)))

We rely on the encode function we defined in the tenth problem to do the actual work, and then we apply a mapping function on the result that for the pairs (count, item) with a count of one returns only the item, leaving the others as is.

P12

Decode a run-length encoded list.
Given a run-length code list generated as specified in problem P10, construct its uncompressed version.
Example:

user> (decode ‘((4, \a), (1, \b), (2, \c), (2, \a), (1, \d), (4, \e)))
(\a, \a, \a, \a, \b, \c, \c, \a, \a, \d, \e, \e, \e, \e)

(defn decode "P12" [xs]
  (reduce concat (map #(repeat (first %) (last %)) xs)))

We start by unpacking the encoded list elements by using the repeat function which given a count and an element, it yields a list of count elements.
Afterwards, it’s simply a matter of concatenating the lists elements using the concat function (which concatenates two lists).

P13

Run-length encoding of a list (direct solution).
Implement the so-called run-length encoding data compression method directly. I.e. don’t use other methods you’ve written (like P09’s pack); do all the work directly.
Example:

user> (encode-direct ‘(\a, \a, \a, \a, \b, \c, \c, \a, \a, \d, \e, \e, \e, \e))
((4,\a), (1,\b), (2,\c), (2,\a), (1,\d), (4,\e))

(defn encode-direct "P13" [xs]
  (reverse
   (reduce
    (fn [res x]
      (let [pair (first res)
	        count (first pair)
	        e (last pair)]
	    (if (= x e)
	      (cons (list (inc count) x) (rest res))
	      (cons (list 1 x) res))))
    ‘() xs)))

Basically what I’ve done here is combine the pack and encode functions. This solution starts by applying the following reduction function:
Given the current result res (which starts as an empty list) and an item x from the list to encode:

• Initialize the following locals:
  • pair: represents the current pair (count, item) of the encoded result list. To simplify matters, I’ll store the pairs in the result list in reverse order
  • count: the first element of pair
  • e: the encoded item which is stored as the second element of the pair
• If the current list element is equal the the current pair element, increment the latter’s count. We do this by creating a new result list with the pair (e or x, count+1) as it’s head and the rest of the old result list as it’s tail.
• Else, add a new pair to the result with a count of 1 and x as it’s element
• In both cases, I use cons to construct the result list, which explains why I’m constructing the result in a reverse order

It remains to reverse the result to get the expected result.

P04

Find the number of elements of a list.
Example:
user> (length ‘(1, 1, 2, 3, 5, 8))
6

My first solution relies on recursion to find out the length of a list:

• The length of an empty list is zero
• The length of a non-empty list is 1 plus the length of that list without its first element

The code shown below is a direct transcription of this:

(defn length "P04" [l]
  (if (empty? l) 0 (inc (length (rest l)))))

Another solution relying on reduce:

(defn length "P04" [xs]
  (reduce (fn [l x] (inc l)) 0 xs))

I’ve already described how reduce operates on a list, but in a nutshell, it’ll pick the first element of the list and feed it with the initial value (0 in this case) the the reduction function, which increments the 0 (representing the list’s length). The result of the reduction (1), along with the next element of the list will be fed again to the reduction function, and the whole process will be repeated until all the list elements are consumed, yielding the list’s length in the end.

You’ll notice that I used the fn form to define the reduction function instead of the shorthand notation (written with the # symbol). When I try to define a reduction function that doesn’t reference %2 (the second parameter) using the shorthand notation, reduce would throw a “Wrong number of parameters” exception:

(defn length "P04" [xs]
  (reduce (inc %1) 0 xs))

Wrong number of args passed to: user$eval–2528$fn
[Thrown class java.lang.IllegalArgumentException]

I’ll quote here a tweet from Michael Fogus, the Co-Author of “The joy of clojure” explaining why:

#() will not gen a 2-arg fn without a reference to %2. Use the (fn [x y] ..) form, or use a %2. Or (reduce #(apply + %&) [1 2 3])

P05

Reverse a list.
Example:
user> (reverse ‘(1 1 2 3 5 8))
(8 5 3 2 1 1)

My first solution relies on recursion to find out the length of a list:

• The reverse of an empty list is an empty list
• The reverse of a non-empty list xs is the list whose first element is xs’s last element and whose rest is the reverse of xs’s rest

The code shown below is a direct transcription of this:

(defn reverse-s99 "P05" [l]
  (if (empty? l)
    nil
    (cons
     (last l)
     (reverse-s99 (butlast l)))))

Again, another way to do it would be to use reduce:

(defn reverse-s99 "P05" [xs]
  (reduce (fn [r x] (cons x r)) ‘() xs))

Basically, this starts with an empty list r, and iterates over xs’s items adding each one of them to r’s beginning.

P06

Find out whether a list is a palindrome.
Example:
user> (palindrome? ‘(1 2 3 2 1))
true

(defn palyndrome? "P06" [l]
  (= l (reverse-99 l)))

No comment !

P07

Flatten a nested list structure.
Example:
user> (flatten ‘((1 1) 2 (3 (5 7))))
(1 1 2 3 5 7)

(defn flatten "P07" [l]
  (reduce
   #(concat %1 (if (list? %2) (flatten %2) (list %2)))
   ‘()
   l))

It’s getting a bit cryptic. What this does is:

• Start with an empty result list
• For every item of the list to flatten, if it’s (%2) a list, flatten it, otherwise create a list out of it. In both cases, add all of the resulting list items to the result list

I had no former experience with anything like lisp before, and anytime I touched the .emacs file, a pile of weird error messages would show up when starting emacs. So I thought it might be a good idea to learn the lisp’s syntax so I’d at least know what was that unbalanced quote I kept seeing in .emacs snippets in the internet.

With time, I started appreciating more and more lisp’s minimalistic syntax, and here I am now, spending more and more time toying with Clojure, a modern Lisp variant that runs on the JVM (my platform of choice, being a Java developer for a couple of years already).

Before that, I learned me some Scala, and to help myself get rid of my imperative programmer reflexes (for loops, variables, etc.), I started coding the solutions for the excellent s99 problems using Scala. It was a joyful although painful experience: Painful because my mind would find the imperative solution first, but I had to refrain from using it while knowing that Scala’s constructs would let me do it, and rather keep reminding myself that the functional solution would have no variables. Joyful because I had to challenge my thought process to not pick the familiar path and tackle problems differently.

Now that I’m trying to learn Clojure, I figured I’d do the same and solve the s99 problems using Clojure. The problems are generic enough and not tied to any specific language.

In the following you’ll find the first 3 problems and their (hopefully) explained solutions.

Disclaimer: I’m still in my baby steps with Clojure and did the best I could with the little I know so far. I would be glad to hear the other clojurists opinions on my approach and any constructive criticism.

P01

Find the last element of a list.
Example:
user> (last ‘(1 1 2 3 5 8))
8

My one-liner solution:

(defn last-99 "P01" [l]
(reduce #(do %2) l))

I’m reducing the list and only keeping the second element. The reduce function would apply its first argument (a function) on the first 2 elements of the list, then on the result of this application and the third list element, etc.

Here’s how the reduction function would walk the list ( 1 1 2 3 5 8 ) :

(1 1)=>1
(1 2)=>2
(2 3)=>3
(3 5)=>5
(5 8)=>8

I highlighted the result and the first argument of every line to visually show that the result of a reduction is fed as an argument to the next reduction.

Another solution relying only on basic list functions (first and rest, who with cons are the bare minimum operations you need with lists to implement almost all the other list operations) would be:

(defn last2 "P01" [l]
(if (empty? (rest l))
(first l)
(last2 (rest l))))

The version will test if the list without its first element (which is what rest does) is empty, if so it’ll return the first element and if not, it’ll return the last element of the list remainder. Another way to view this is that the last2 function would consume the first element of the list until there remains only one, and return it.

P02

Find the last but one element of a list
Example:
user> (penultimate ‘(1, 1, 2, 3, 5, 8))
5

Another one-liner solution:

(defn penultimate "P02" [l]
(first (rest (reverse l))))

Basically I return the first item of the list after reversing it and removing its first element. For the list ‘(1 1 2 3 5 8), this would go as :

reverse: (8 5 3 2 1 1)
remove the head: (5 3 2 1 1)
return the first item: 5

I’m not very happy with this solution as it relies on reverse, a rather complex operation. It’s like implementing multiplication using the power or sine function. Besides, the 5th problem is about implementing reverse. Another simpler (in that it only uses first and rest) solution would be :

(defn penultimate2 "P02" [l]
(if (empty? (rest (rest l)))
(first l)
(penultimate2 (rest l))))

This solution, while being longer, only relies on basic functions (empty?, rest and first).

P03

Find the Kth element of a list.
By convention, the first element in the list is element 0.
Example:
user> nth(2 ‘(1, 1, 2, 3, 5, 8))
2

Yet another one-liner solution:

(defn nth-s99 "P03" [n l]
(if (= 0 n) (first l) (nth-s99 (- n 1) (rest l))))

This solution relies on the following principle: the 3rd element of a list is the 2nd element of that list without its first element. Applying this principle on the second statement would give that the 2nd element of a list is the 1st element of that same list without its first element.

It would the go that finding the nth element of any list can be brought back to finding the first element of a list. The trick is to remove the list’s first item n times, which is exactly what the solution shown above does.

• Le code est en Java (et non un langage de script à apprendre);
• Le développeur a l’option de concevoir son interface graphique de façon déclarative (en XML);
• L’intégration avec les composants serveur est plus souple.

Dans cet article, nous allons surtout se focaliser sur ce dernier point qui n’a pas été illustré dans les démos et les tutoriaux du site officiel du framework. Pour cela, nous allons essayer de développer une simple application client/serveur de gestion de contacts. Pour faire au plus simple, les fonctionnalités seront réduites à ajouter un contact ou modifier un contact existant.

Une version abrégée de cet article a été publiée dans le numéro 132 (Juillet 2010) du magazine «PROgrammez». La version PDF de l’article est mise à votre disposition en téléchargement gratuit. Le code source de l’exemple donné est fourni (voir ci-dessous).

PARTIE CLIENTE

L’écran principal se composera d’une liste de contacts et un bouton pour ajouter un contact à la liste. Un clic sur une entrée de la liste permettra à l’utilisateur de modifier les détails du contact.

Les deux écrans sont conçus déclarativement dans les deux fichiers table.xml et addContact.xml.

<TableView wtkx:id="tableView"
	styles="{includeTrailingVerticalGridLine:true}">
	<columns>
		<TableView.Column name="firstname" width="100"
			headerData="Prenom" />
		<TableView.Column name="lastname" width="100"
			headerData="Nom" />
		<TableView.Column name="email" width="60"
			headerData="E-Mail" />
		<TableView.Column name="phone" width="60"
			headerData="Téléphone" />

	</columns>
</TableView>

Extrait (correspondant au tableau de contacts) de table.xml

<Form styles="{rightAlignLabels:true}" wtkx:id="submitform">
	<sections>
		<Form.Section>
			<Label Form.label="ID" textKey="id" />
			<BoxPane Form.label="Nom">
				<TextInput textKey="lastname" />
			</BoxPane>
			<BoxPane Form.label="Prénom">
				<TextInput textKey="firstname" />
			</BoxPane>
			<BoxPane Form.label="Téléphone">
				<TextInput textKey="phone" />
			</BoxPane>
			<BoxPane Form.label="Adresse E-mail">
				<TextInput textKey="email" />
			</BoxPane>
		</Form.Section>
	</sections>
</Form>

Extrait (correspondant au formulaire) de addContact.xml

Notre classe Contact a les propriétés ID (id), Prénom (firstName), Nom (lastName), E-mail (email) et téléphone (phone). Noter que dans le composant TableView de table.xml, la propriété ‘name’ de chaque colonne correspond à la propriété de la classe Contact correspondante; et que dans chaque TextInput du formulaire d’ajout/modification de addContact.xml, la propriété textKey correspond aussi à la propriété de la classe Contact correspondante.

A part la classe Contact (modèle de donnée), la partie cliente de notre application se compose de 4 classes :

• Une classe Contacts qui joue le rôle du contrôleur (qui implémente trois interfaces d’écoutes d’événements)

• Une classe TableContactsWindow (vue) qui représente la fenêtre principale contenant la liste des contacts

• Une classe EditContactWindow (vue) qui représente la fenêtre d’ajout/modification d’un contact

• Une classe RemoteContactModel (modèle) qui sera responsable de la communication avec le serveur

Nos trois interfaces d’écoute d’événements (implémentées par le contrôleur) sont:

• ContactUpdateListener pour répondre à deux événements : demande (par l’utilisateur) d’ajout d’un contact et demande (par l’utilisateur) d’édition d’un contact.

• ContactSubmitRequestListener pour répondre à l’événement de demande (par l’utilisateur) de sauvegarde d’un  contact.

• ContactAccessListener pour répondre à deux événements : la fin du chargement de la liste des contacts et la réussite de la sauvegarde d’un objet contact.

LES VUES

La classe TableContactsWindow garde une référence sur un écouteur d’événements ContactUpdateListener (c’est la table de contacts qui déclenche les événements associés) et a deux propriétés : le tableau de contacts et la fenêtre contenant le tableau. Le constructeur prend en paramètre l’écouteur et demande à Pivot de parser table.xml pour construire la fenêtre et la table :

		WTKXSerializer wtkxSerializer = new WTKXSerializer();
		try {
			window = (Window)wtkxSerializer.readObject(this, "table.xml");
		} catch (IOException e) {
			e.printStackTrace();
		} catch (SerializationException e) {
			e.printStackTrace();
		}
		table = (TableView)wtkxSerializer.get("tableView");

Ensuite, on ajoute un gestionnaire pour l’événement de clic sur une ligne de la table (modification d’un contact) et pour l’événement de clic sur le bouton ‘Ajouter’ :

//Ajoute un gestionnaire d'événement pour le clic sur une ligne du tableau
table.getComponentMouseButtonListeners().add(new ComponentMouseButtonListener.Adapter() {
	@SuppressWarnings("unchecked")
	@Override
	public boolean mouseClick(Component component,
		org.apache.pivot.wtk.Mouse.Button button, int x, int y, int count) {
		List<Contact> contacts = (List<Contact>)table.getTableData();
		//Récupère l'indice de la ligne cliqué
		int index = table.getRowAt(y);
		//Notifie le contrôleur de la demande d'édition d'un contact
		controller.editContactRequest(contacts.get(index), TableContactsWindow.this);
				return false;
			}
		});

		PushButton addButton  = (PushButton)wtkxSerializer.get("addButton");

		//Ajoute un gestionnaire d'événement pour le clic sur le bouton 'Ajouter'
		addButton.getButtonPressListeners().add(new ButtonPressListener() {
			@Override
			public void buttonPressed(Button button) {
				//Notifie le contrôleur du clic sur le bouton 'Ajouter'
				controller.addContactRequest(TableContactsWindow.this);
			}
		});

Elle admet aussi une méthode setContacts pour remplir la table avec une liste de contacts :

public void setContacts(List<Contact> result) {
		//Met à jour la table des contacts
		table.setTableData(result);
	}

Notons ici, qu’en appelant les méthodes setTableData et getTableData (qu’on a appelé dans le gestionnaire d’événement lors d’un clic sur une ligne du tableau), Apache Pivot se charge du mapping entre les propriétés de la classe Contact et les colonnes du tableau.

La classe EditContactWindow garde une référence sur un écouteur d’événements ContactSubmitRequestListener (c’est la fenêtre d’édition qui déclenche l’événement de demande de soumission) et a les propriétés suivantes :

• la fenêtre de tableau de contacts associée (à laquelle ajouter ou depuis laquelle modifier le contact)
• la fenêtre d’édition
• le formulaire d’édition
• l’objet Contact en cours d’ajout/d’édition

Le constructeur prend en paramètre le contrôleur et la fenêtre de tableau de contacts associée, demande à Pivot de parser addContact.xml pour construire la fenêtre d’édition et le formulaire:

		WTKXSerializer wtkxSerializer = new WTKXSerializer();
		try {
			editWindow = (Window)wtkxSerializer.readObject(this, 					"addContact.xml");
		} catch (IOException e) {
			e.printStackTrace();
		} catch (SerializationException e) {
			e.printStackTrace();
		}

		form = (Form)wtkxSerializer.get("submitform");

Ensuite, on ajoute un gestionnaire pour l’événement de clic sur le bouton de soumission du formulaire :

		PushButton submit = (PushButton)wtkxSerializer.get("submitButton");
	submit.setAction(new Action() {
		@Override
		public void perform() {
		//Met à jour l'objet contact avec les valeurs des champs du formulaire
		//Apache Pivot se charge de faire l'association
		//entre les propriétés de la classe Contact et les champs du formulaire
		form.store(contact);
		//Notifie le contrôleur de la soumission du formulaire
		listener.contactSubmit(contact,EditContactWindow.this);
		//Ferme la fenêtre d'edition
		editWindow.close();
		}
	});

La classe EditContactWindow admet aussi une méthode setContact pour mettre à jour l’objet Contact en cours d’édition :

public void setContact(Contact contact) {
	this.contact = contact;
	//Les champs du formulaire se remplissent avec les infos du contact
	//Apache Pivot se charge de faire l'association
	//entre les propriétés de la classe Contact et les champs du formulaire
	form.load(contact);
}

Notons ici qu’en appelant les méthodes load et store de l’objet Form, Pivot se charge de mapper les propriétés de la classe Contact avec les champs du formulaire.

LE MODELE

A ce niveau de l’article, nous n’allons pas détailler la classe RemoteContactModel (nous allons le faire dans la partie qui traite la communication client/serveur) qui incarne le modèle dans notre application. Sachons seulement que cette classe implémente l’interface ContactModel, et est chargée de deux opérations :

• Récupérer la liste des contacts (opération à la fin de laquelle elle déclenche l’événement contactsRetrieved)

• Poster un objet Contact pour ajout ou pour mise à jour (opération à la fin de laquelle elle déclenche l’événement contactSaved)

LE CONTROLEUR

La classe Contacts joue le rôle de contrôleur en implémentant les 3 interfaces d’écoutes et en gardant une référence vers la vue TableContactsWindow et le modèle ContactModel. Pour être notre point d’entrée de l’application, elle implémente l’interface org.apache.pivot.wtk.Application. Pivot appellera alors la méthode startup :

//Crée la fenêtre de table de contacts
		tcw = new TableContactsWindow(this);
		//Instancie le model
		model = new RemoteContactModel(this);
		//Demande au modèle de récupérer la liste des contacts
		model.retrieveAllContacts();
		//Affiche la fenêtre sur l'ecran principal
		tcw.getWindow().open(display);

Dans cette méthode, on instancie une fenêtre de tableau de contacts, on la remplit avec la méthode updateTable (qui ne fait que demander au modèle de récupérer la liste), et enfin on l’affiche sur l’écran principal (l’objet display qu’on reçoit en paramètre).

La classe Contacts, jouant le rôle de contrôleur, est responsable de gérer les événements :
1. Demande d’édition d’un contact : instanciation d’une fenêtre d’édition et lui passant le contact à éditer

public void editContactRequest(Contact contact, TableContactsWindow source) {
		//Crée une fenêtre d'édition de contact
		EditContactWindow ecw = new EditContactWindow(this,source);
		//Met l'objet Contact cliqué pour édition
		ecw.setContact(contact);
		//Affiche la fenêtre
		ecw.show();
	}

2. Demande d’ajout d’un contact : instanciation d’une fenêtre d’édition et lui passant un nouvel objet contact « vide »

public void addContactRequest(TableContactsWindow source) {
		//Crée un nouvel objet Contact "vide"
		Contact newContact = new Contact(null, "", "", "", "");
		//Crée une fenêtre d'édition
		EditContactWindow ecw = new EditContactWindow(this,source);
		//Met le nouveau contact pour édition
		ecw.setContact(newContact);
		//Affiche la fenêtre d'édition
		ecw.show();
	}

3. Demande de soumission d’un contact : demande au modèle de sauvegarder (poster) l’objet

public void contactSubmit(Contact contact, EditContactWindow source) {
		model.saveContact(contact);
	}

4. Chargement de la liste des contacts : met à jour la table des contacts avec la nouvelle liste.

public void contactsRetrieved(List<Contact> contacts) {
		tcw.setContacts(contacts);
	}

5. Sauvegarde d’un contact : demande au modèle un rechargement de la liste des contacts

public void contactSaved() {
		model.retrieveAllContacts();
	}

LA PARTIE SERVEUR

Du côté serveur, on a deux composants essentiels :

• Une Servlet qui gère les requêtes de la partie cliente

• Un DAO pour récupérer et sauvegarder les contacts

Nous verrons les détails de la servlet plus en détail dans la troisième partie. Pour le moment, sachez qu’elle communique avec le DAO pour sauvegarder un objet posté par le client, ou pour récupérer une liste de contacts à renvoyer au client.

Pour simplifier les choses, nous avons opté pour une implémentation en mémoire du DAO, en tant que map dont les clés sont les ID et les valeurs sont les contacts associés.

public class MemoryContactDAO implements ContactDAO {

	private static Map<Long, Contact> data = new HashMap<Long, Contact>();
	static Long lastId;

	public List<Contact> getAll() {
		List<Contact> contacts = new ArrayList<Contact>();
		for(Contact c:data.values()){
			contacts.add(c);
		}
		return contacts;
	}

	@Override
	public Contact getById(Long id) {
		return data.get(id);
	}

	@Override
	public void save(Contact contact) {
		if(contact.getId() != null){
			data.put(contact.getId(), contact);
		}else{
			lastId ++;
			contact.setId(lastId);
			data.put(lastId, contact);
		}

	}

L’INTERACTION CLIENT/SERVEUR

Apache Pivot dispose d’une API pour lancer des requêtes HTTP depuis la partie cliente. Deux classes de cet API sont utilisées dans notre classe modèle de la partie cliente.

Pour récupérer la liste des contacts, on lance une requête HTTP de type GET, et une fois exécutée avec succès, on notifie le contrôleur de la réponse reçue.

public void retrieveAllContacts() {
		//Crée une requête GET
		GetQuery getQuery = new GetQuery(HOST,PORT, "/"+APP_NAME+"/Contact",false);
		//Affecte le serialiseur de contacts
		getQuery.setSerializer(SerializerFactory.getContactSerializer());
		//Lance la requête en affectant un écouteur pour gérer le retour de la réponse
		getQuery.execute(new TaskListener<Object>() {
			@Override
			public void taskExecuted(Task<Object> task) {
				//task.getResult() = Réponse Objet désérialisé assumé en tant que liste de contacts
				//On notifie le controller de la liste récupérée
				controller.contactsRetrieved(((List<Contact>)task.getResult()));
			}
			@Override
			public void executeFailed(Task<Object> task) {
				//Ne fait rien du tout si erreur
			}

		});
	}

Pour sauvegarder (poster) un objet contact, on lance une requête HTTP de type POST, et une fois exécutée avec succès, on notifie le contrôleur.

public void saveContact(Contact contact) {
		//Crée une requête POST
		PostQuery post = new PostQuery(HOST,PORT, "/"+APP_NAME+"/Contact",false);
		//Affecte le serialiseur de contacts
		post.setSerializer(SerializerFactory.getContactSerializer());
		//Affecte l'objet Contact soumis (qui sera sérialisé)
		post.setValue(contact);
		//Lance la requête
		post.execute(new TaskListener<URL>() {

			@Override
			public void executeFailed(Task<URL> arg0) {
				//Ne fait rien du tout si erreur
			}

			@Override
			public void taskExecuted(Task<URL> arg0) {
				//On notifie le controller que la requête s'est bien déroulée
				controller.contactSaved();
			}
		});

	}

Vous avez peut être remarqué dans le code qu’on affecte à notre objet requête un sérialiseur. Les sérialiseurs de Apache Pivot peuvent faire l’objet d’un article qui leur est dédié. Sachez que Apache Pivot ne fait pas de différence entre sérialiseurs et désérialiseurs, et que dans ce contexte (requête GET), il s’agit plutôt d’un désérialiseur pour permettre à Pivot de « comprendre » la réponse renvoyé par le serveur (task.getResult()). Dans cette application, on a utilisé le BinarySerializer, qui ne fait qu’une sérialisation (pour les objets postés) et une désérialisation (pour les objets reçus) en binaire. Evidemment, ce type de sérialiseur est rarement pratique, nous l’avons choisi juste par simplicité et parce que c’est nous qui développons la partie cliente ainsi que la partie serveur. Par contre, si nous voudrons utiliser notre partie serveur pour exposer des services consommés par d’autres types de clients (Web, Application .NET…), le BinarySerializer est un choix à proscrire. Ce que Pivot apporte dans cette partie, c’est la sérialisation et la désérialisation transparente pour le développeur qui ne manipule que des objets. Remarquez que task.getResult() nous a retourné une liste de contacts, et que pour poster un objet contact, on n’a eu à faire que post.setValue(contact).

Apache Pivot dispose aussi d’une API pour traiter les requêtes HTTP du coté serveur. En effet, Pivot nous offre la classe QueryServlet. Dans notre application, la servlet de la partie serveur hérite de QueryServlet. Lorsqu’on hérite de QueryServlet, on doit implémenter (redéfinir) :

• La méthode newSerializer qui retourne le sérialiseur/désérialiseur que Pivot utilise pour sérialiser les objets retournés au client, et désérialiser les objets reçus du client

• Une méthode par type de requête HTTP à gérer

Dans notre cas, nous utiliserons le BinarySerializer comme retour de la méthode newSerializer : c’est ainsi que le client a sérialisé ses données, c’est ainsi donc que le serveur devrait les désérialisé. De plus, nous devrons redéfinir la méthode doGet et doPost pour gérer les deux types de requêtes que le client envoie.

protected Object doGet() throws ServletException, ClientException {

	//Récupère le DAO
	ContactDAO dao = DAOFactory.getContactDao();
	//Cas où la requête porte sur tous les contacts
	List<Contact> all = dao.getAll();
	org.apache.pivot.collections.List<Contact> result = new org.apache.pivot.collections.ArrayList<Contact>();
	//Transforme une java.util.List en l'implémentation List de Pivot
	for(Contact c:all){
		result.add(c);
	}
	//Retourne la liste
	//Apache Pivot se chargera par la suite de sérialiser la liste
	//et de l'inclure dans une réponse HTTP
	return result;
}

protected URL doPost(Object value) throws ServletException, ClientException {
	//Apache Pivot s'est déjà chargé de désérialiser l'objet envoyé
	//dans la requête POST et nous l'a passé en paramètre
	Contact contact = (Contact)value;
	//Récupère le DAO
	ContactDAO dao = DAOFactory.getContactDao();
	//Enregistre(ajoute ou met à jour) le contact envoyé
	dao.save(contact);
	try {
		String app = this.getContextPath();
		return new URL("http://localhost:8080"+app+"/Contact");
	} catch (MalformedURLException e) {
		e.printStackTrace();
	}
	return null;
}

Remarquez dans les deux méthodes, qu’on ne manipule pas les objets HTTPServletRequest, ni HTTPServletResponse. Les signatures des méthodes doGet et doPost sont différentes de celles des servlets « normales » (javax.servlet.http.HttpServlet). Le développeur, encore une fois, ne manipule que ses objets du modèle de donnée. Apache Pivot se charge de nous passer l’objet posté par le client (après désérialisation) comme paramètre de la méthode doPost et se charge aussi de formuler la réponse au client (après sérialisation) à partir de l’objet que nous retournons dans la méthode doGet.

Par cet article, nous avons montré quelques aspects de Pivot, comme la conception déclarative des interfaces utilisateurs ou le binding entre les objets (Contact) et les composants (TableView et Form), mais nous avons voulu surtout insisté sur le développement coté serveur à l’aide de Pivot, un aspect qui a été jusqu’à maintenant négligé dans les tutoriaux et les démos de référence du framework.

Télécharger le code source de l’exemple.

At first, we thought that adding this functionality would require performing complex developments and altering the basic document upload action.
We later discovered that this feature was already implemented in Alfresco Share though it is not documented anywhere (neither in official Alfresco documentation nor in the community sites and blogs).

If you take a look at  the file “tomcat\webapps\share\WEB-INF\classes\alfresco\site-webscripts\org\alfresco\components\upload\flash-upload.get.html.ftl”, you’ll notice that while the upload form already contains the required code to generate a select input for the document type, its visibility is conditioned by the test “contentTypes?size == 1”.

         <div id="${args.htmlid}-left-div" class="fileupload-left-div">
            <span class="fileupload-percentage-span hidden"> </span>
            <select class="fileupload-contentType-select <#if (contentTypes?size == 1)>hidden</#if>">
               <#if (contentTypes?size > 0)>
                  <#list contentTypes as contentType>
                     <option value="${contentType.id}">${msg(contentType.value)}
                     </option>
                  </#list>
               </#if>
            </select>
         </div>

And so, it only takes filling in the contentTypes variable in the webscript Javascript controller with the custom document types for the select input to be shown to the final user.

The “contentTypes” variable’s declaration and initialization can be found in this file:  “tomcat\webapps\share\WEB-INF\classes\alfresco\site-webscripts\org\alfresco\components\upload\flash-upload.get.js”. This variable consists of an array of objects with 2 fields:

• id: the Alfresco content type identifier.
• value: the content type label’s key in the webscript properties file.

Find below an example of how to initialize contentTypes variable with multiple content types:

   var contentTypes = [
   {
      id: "cm:content",
      value: "cm_content"
   },
    {
      id: "custom:docJuri",
      value: "custom _docJuri"
   },
    {
      id: "custom:autres",
      value: "custom _autres"
   },
   {
      id:  "custom:presse",
      value: "custom _presse"
   },
   {
      id: "custom:biblio",
      value: "custom _biblio"
   }
    ];

As a result, here’s how the upload form will look like:

Figure 1. Upload form

Now, you should be able to easily define types for your documents when adding them to the repository, as with Alfresco explorer, and then fill in their custom metadata as showing in Figure 2.

Figure 2. Edit metadata form

Hope it was useful, your comments are welcome.

Les processeurs à cœurs multiples et hybrides arrivent à la tête du classement établi par Gartner pour les technologies de rupture pour 2008 à 2012. Ces technologies sont depuis entrées dans le mainstream. Ainsi, le défi de supporter les processeurs de nouvelles générations est devenu une nécessité. Ceci nous amène à nous interroger sur les possibilités de migration pour les applications existantes. La migration  pour les processeurs modernes peut poser plusieurs problèmes aux développeurs. Nous avons donc choisi de mettre l’accent sur les erreurs communes en développement 64 bit et les techniques les moins intrusives pour paralléliser son application.

Cet article a été publié dans le numéro 130 (Mai 2010) du magazine «PROgrammez». La version PDF de l’article est mise à votre disposition en téléchargement gratuit.

Processus 64 bit

Est-il suffisant de recompiler le code avec un compilateur 64 bits ?
La recompilation est suffisante pour plusieurs types de programmes. On vérifiera que l’application utilise seulement des librairies compilées en 64 bit, car un processus 64 bit peut exécuter uniquement du code 64 bit. Dans des applications triviales, cette étape suffit à elle seule. Cependant en réalité rien ne garantit que les libraires utilisées aient une version 64 bit, la conversion et d’autant plus compliquée si leurs codes source sont indisponibles. Dans ce cas, on pourra envisager des scénarios de communication interprocessus entre l’application et la bibliothèque en question. Outre cela, la compilation ne garantit pas le bon fonctionnement de l’application. De nouveaux bugs et anomalies peuvent avoir lieu. Allant des erreurs d’affichage jusqu’aux failles de sécurité les plus sévères dues à un dépassement de tampon « buffer overflow » par exemple. La mauvaise manipulation des pointeurs, la lecture des fichiers binaires ainsi que l’usage du code assembleur sont des sources potentielles de bugs. Prenons un exemple simple de programme qui a un comportement différent selon l’architecture matérielle.

int main(int argc, char* argv[])
{
	///Le type size_t est 64bit pour le
	///compilateur 64bit.
	size_t size = sizeof(myObject);
	///L’affectation peut engendrer une
	///perte de données.
	long a = size;

	///%x assume que le type est 32 bit
	printf(”%x\n”,a);
	printf(”%x\n”,size);

	return 0;
}

La procédure main ne compte que 5 lignes, pourtant on peut identifier déjà deux bugs. Le type size_t a une valeur 64 bit pour un compilateur 64 bit. Le type long est un type 32 bit, la conversion : long a = size;
Peut engendrer donc la perte de données, car la taille du type size_t est supérieure à celle du type long. De plus %x qui permet de formater l’affichage en hexadécimal ne prend en compte que les valeurs 32 bit. On pourrait corriger la fonction d’affichage pour le programme précédent on en remplaçant %x par %I64x pour l’architecture x64. Essayons à présent de corriger l’opération d’affectation, on pourrait songer à remplacer le long par le type long long. Le programme fonctionne correctement pour l’architecture x64, mais il ne retourne plus la bonne valeur pour l’architecture x86 ! Ceci était prévisible puisque long long est un entier 64 bit. À l’évidence, la solution la plus simple serait de remplacer le long par size_t. Ce petit programme de quelques lignes montre que la correction de ce type d’erreurs est loin d’être aisé.

#ifdef _WIN64
  #define xformat "I64"
#else
  #define xformat ""
#endif

int main(int argc, char* argv[])
{
	///Le type size_t est 64bit pour le
	///compilateur 64bit.
	size_t size = sizeof(myObject);
	///L’affectation peut engendrer une
	///perte de données.
	size_t a = size;

	///%x assume que le type est 32 bit
	printf(”%x” xformat “\n”,a);
	printf(”%x” xformat “\n”,size);

	return 0;
}

Les deux erreurs dans le programme précédent sont causées par le changement de taille pour le type size_t. Ci-dessous une liste de quelque type prédéfinis en c++ et leurs tailles respectives pour les architectures 32 et 64 bit.

Le tableau ci-dessus montre qu’une classe contenant des attributs de type pointeur par exemple, n’occupe pas la même taille en mémoire pour un programme 64 bit et 32 bit.

Structures de données

Malgré la puissance brute des processeurs modernes, certains programmes compilés en 64 bit peuvent avoir une baisse de performance accompagnée généralement d’une augmentation importante en consommation de mémoire. L’augmentation en consommation mémoire n’est pas seulement due au changement de taille pour les types de base. En effet, il y a de fortes chances qu’un mauvais alignement des structures est la cause de cette augmentation. Considérons un cas ou ces effets secondaires se manifestent.
Soit la structure suivante :

struct heavyStruct
{
	char b;
	int *a;
	int  u;
};

En 32 bit cette structure occupe une taille de  12 octets en mémoire. Par contre en 64 bit elle aura une taille de 24 octets. Observons le cas d’une structure qui a exactement les mêmes attributs que « heavyStruct » mais qui ne sont pas dans le même ordre. On pourrait s’attendre que cette dernière aura naturellement une taille identique que « heavyStruct » mais il n’en est rien ! En effet en 64 bit elle aura une taille 16 octets et en 32 bit elle reste égale à 12 octets. Retenons donc ceci, la taille d’une structure n’est pas égale à la somme des tailles de ces attributs. Dans la plupart des cas, ce fait n’a pas un impact perceptible sur la consommation en mémoire. Toutefois, l’ordre des attributs à l’intérieur d’une structure peut limiter la consommation en mémoire de l’application, notamment lorsqu’il s’agit de crée un tableau de grande taille.

struct lightStruct
{
	int *a;
	int  u;
	char b;
};

La taille d’un struct n’est pas égale à la somme des tailles de ces attributs comme le montre la figure suivante, les cases en rouge sont ceux occupés par les données de la structure tandis que ceux en gris représente l’espace gaspillé.

heavyStruct

Un agencement meilleur des attributs permet d’optimiser l’usage de mémoire.

LightStruct

Conclusion

Les erreurs du au changement de taille des types prédéfinis sont très fréquentes. Et comme nous l’avons vu il y a de fortes probabilités que ces erreurs auront des conséquences dramatiques sur le comportement de l’application.

Systèmes multi-cœurs

Nous avons vu quelques pièges à éviter lors de la migration d’applications pour une architecture 64 bit. Malheureusement, cela ne suffit plus à tirer avantage des processeurs à cœurs multiples. En effet si notre application est monothread son processus sera exécuté sur un seul cœur. Mais que ferait-on pour comment paralléliser son application existante, sans être amené à la réécriture du code source ?
Bien entendu, on peut utiliser les threads Windows ou ceux de POSIX, mais pour la migration d’application on préfère utiliser la technologie la moins intrusive. La solution qui répond le plus à ce besoin est la technologie OpenMP. Car elle ne nécessite pas de modifier la structure de l’application. Est c’est une technologie standard multi plateformes supportées supportée par plusieurs compilateurs C/C++.
Supposons que nous avons à notre disposition une technologie qui nous permet de paralléliser assez rapidement des portions de notre code existant. Si par exemple on parvient à paralléliser 60 % de notre code. Quel est le gain de performance maximal que l’on peut obtenir ?
La loi d’Amdahl très utilisée en informatique permet d’avoir une idée sur la performance maximale que l’on peut atteindre en parallélisant une portion P du code sur N cœurs :

Si l’on parvient par exemple à paralléliser 60 % (P = 0,6) du code sur un système à quatre processeurs (N = 4) alors on peut s’attendre à une augmentation des performances allant jusqu’à deux fois la vitesse pour un seul processeur. Pour un ordinateur ayant 16 processeurs en parallèle le gain peut atteindre 2.35 fois la performance pour un seul processeur. En revanche si 100 % du code est parallèle alors sur un système à 16 processeurs le gain est multiplié par 16. En règle générale plus il y a de proportion du code source tournant en parallèle plus le programme est extensible (scalable).

Granularité des threads

Lorsqu’il s’agit de paralléliser son application, la solution la plus simple serait de décomposer le programme en tâches indépendantes. La décomposition est souvent fonctionnelle. Par exemple dans un jeu vidéo on peut exécuter le système sonore, l’intelligence artificielle et le rendu sur des threads séparés. Cette solution est assez répondue néanmoins lorsque le nombre de cœurs dépasse le nombre de blocs parallèles, les performances ne seront plus améliorées avec l’ajout d’autres cœurs au système. Une granularité grossière des threads ne permet pas toujours d’augmenter l’extensibilité du programme.
Une granularité fine des threads permet une plus grande extensibilité. On doit créer les threads, assigner à chaque thread la tâche qu’il doit exécuter et finalement terminer leurs exécutions. L’implémentation manuelle de cette méthode peut apporter des gains considérables en termes de performances, mais elle est généralement assez difficile à réaliser. Encore une fois, la technologie OpenMP peut simplifier les choses en proposant d’automatiser la gestion des threads.

Le couteau suisse du développeur

La migration peut être facilitée à l’aide des outils d’analyse et d’inspection automatique. Ils permettent de détecter plusieurs erreurs classiques en programmation parallèle, telle que les deadlocks et race conditions. En outre à l’aide de la visualisation graphique on peut détecter facilement les goulots d’étranglement dans une application.
Une gamme d’outils incontournables est Intel® Parallel Studio.

Exemple d’application

Afin de mieux présenter les spécificités des processeurs de nouvelles générations, nous avons choisi de réaliser un simple système de particule. Car il présente un cas typique ou une région du code ralenti l’ensemble du programme.
J’aimerais rappeler qu’un système de particule est une simulation d’un grand nombre de points dans l’espace soumis à un ensemble de forces comme la gravité. Il est souvent utilisé en infographie pour simuler l’apparence de nombreux phénomènes naturels et pour créer des effets spéciaux. Nous n’avons pas la prétention de créer un système complexe de A jusqu’à Z, mais seulement de retenir les détails les plus importants de la migration.
L’idée de base était de trouver un cas d’application ou il y a un goulot d’étranglement au niveau des calculs effectués par le CPU. Les données relatives aux particules sont conservées dans la mémoire à haute performance du GPU. Les données sont encapsulées dans des “buffer objects” pour minimiser le transfert de données entre processeurs et carte graphique.

À chaque frame, on calcule la nouvelle position, vitesse et accélération de chaque particule. Ce temps de calcul est plus important que le temps pris par le rendu des particules par la carte graphique. Pour peu qu’on arrive à optimiser cette partie du code source, la vitesse d’exécution sera nettement améliorée. Mais avant d’entamer l’étape d’optimisation, examinons de plus près notre code pour y déceler d’éventuelles erreurs.
La boucle permettant de mettre à jour les particules est sous la forme :

	for (ptrdiff_t i = 0;i<particleSystem->getParticleNumber();i++)
		particleSystem->Update(i);

Le type « ptrdiff _t»  a une taille de 32 bit pour les systèmes 32 bit et 64 bit pour les systèmes 64 bit. Ce qui le rend idéal pour les indexes des tableaux. Par ailleurs, il permet d’éviter de sacrifier inutilement de la mémoire pour les systèmes 32 bit. Et peut être utilisé invariablement quelque soit le système.
La boucle peut être réécrite de la façon suivante, dans l’intention d’expliciter les instructions de la fonction de mise à jour.

void particleSystem::Update()
{
	ptrdiff_t i;
	for (i = 0;i<particleNb;i++)
	{
		ForceZ += sinf(ForceZaxis[i]);
		//L’acceleration est la somme des forces divisée par
		//la masse de la particule.
		particle[i].acceleration = ForceZ / particle[i].mass * ez;
		//On met à jour la vitesse de la particule.
		particle[i].velocity += particle[i].acceleration;
		//On met à jour la position de la particule.
		particle[i].position += particle[i].velocity;
}
}

La fonction de mise à jour pour une particule donnée ne nécessite pas la connaissance de l’état des autres particules. Elles agissent indépendamment et par conséquent on peut imaginer que cette tâche peut être répartie sur plusieurs threads. Chaque thread mettra à jour un certain nombre de particules. Le problème ne nécessite aucune solution de synchronisation avancée. Sans doute, la solution doit être très simple, dans le cas d’OpenMP elle l’est, mais dans bien d’autre cas elle nécessite la modification du code. Pour indiquer au compilateur que la boucle peut être parallélisé, il suffit d’ajouter la directive :

pragma omp parallel for shared(particle)

Notons au passage que dans le cas où le support d’OpenMP est désactivé le compilateur ignore tout simplement cette ligne et on obtiendra la version sérielle de notre application.

	#pragma omp parallel for shared(particle)
for (i = 0;i<particleNb;i++)
	{
		ForceZ += sinf(ForceZaxis[i]);
		//L’acceleration est la somme des forces divisée par
		//la masse de la particule.
		particle[i].acceleration = ForceZ / particle[i].mass * ez;
		//On met à jour la vitesse de la particule.
		particle[i].velocity += particle[i].acceleration;
		//On met à jour la position de la particule.
		particle[i].position += particle[i].velocity;
	}

La granularité des threads est un facteur important lors de la parallélisation de l’application. L’ajustement de la granularité en OpenMP se fait par le biais de la clause : schedule(type, nombre)

schedule(static, 100)

On indique que la capacité du lot est égale à 100. Par conséquent à chaque thread on affecte 100 itérations.

#pragma omp parallel for schedule(static, 100) private(i)
\ shared(particle, ForceZ)
for (i = 0;i<particleNb;i++)
	{
		ForceZ += sinf(ForceZaxis[i]);
		//L’acceleration est la somme des forces divisée par
		//la masse de la particule.
		particle[i].acceleration = ForceZ / particle[i].mass * ez;
		//On met à jour la vitesse de la particule.
		particle[i].velocity += particle[i].acceleration;
		//On met à jour la position de la particule.
		particle[i].position += particle[i].velocity;
	}

Considérons à présent l’instruction suivante permettant d’effectuer la somme des éléments d’un tableau :

ForceZ += sinf(ForceZaxis[i]);

On peut indiquer à OpenMP d’optimiser l’opération de sommation. En spécifiant le nom de la variable et l’instruction. L’opération de réduction permet de se débarrasser des sémaphores de synchronisation. Dans le code suivant la variable ForceZ ne nécessite pas de primitive de synchronisation grâce à l’opération de réduction.

#pragma omp parallel for schedule(static, 100) private(i)
\ shared(particle) reduction(+:ForceZ)
for (i = 0;i<particleNb;i++)
	{
		ForceZ += sinf(ForceZaxis[i]);
		//L’acceleration est la somme des forces divisée par
		//la masse de la particule.
		particle[i].acceleration = ForceZ / particle[i].mass * ez;
		//On met à jour la vitesse de la particule.
		particle[i].velocity += particle[i].acceleration;
		//On met à jour la position de la particule.
		particle[i].position += particle[i].velocity;
	}

Résultats

Nous avons testé le temps d’exécution de l’application sur différents processeurs. Nous remarquons une baisse de performance pour la version sérielle de l’application pour le processeur Intel Xeon malgré qu’il est le plus puissant des processeurs testés. La version parallèle de l’application est nettement plus performante, en effet elle est 2.26 fois plus rapide que la version sérielle pour le processeur Intel Xeon.

La courbe suivante montre l’extensibilité de notre application. La version parallèle permet en effet d’exploiter la puissance des processeurs testés.

Conclusion

Nous avons vu dans cet article quelques pièges à éviter lors de la migration d’applications pour les processeurs modernes. Une des technologies clefs pour une migration progressive est la technologie OpenMP. Ceci étant dit il reste encore de nombreuses voies à explorer afin d’exploiter au mieux les capacités des ordinateurs modernes et notamment l’exploitation de la puissance de calcul du GPU. Le standard OpenCL comme le fut OpenMP ouvre de nouvelles possibilités pour les développeurs pour paralléliser leurs applications.

Références et ressources

• http://developer.amd.com/documentation/articles/pages/6220067.aspx
• http://software.intel.com/en-us/blogs/2010/02/16/search-of-64-bit-errors-in-array-implementation/
• http://software.intel.com/en-us/articles/granularity-and-parallel-performance/
• http://msdn.microsoft.com/en-us/magazine/cc300794.aspx
• http://msdn.microsoft.com/en-us/library/3b2e7499%28VS.80%29.aspx
• http://www.viva64.com/content/articles/64-bit-development/?f=64-bit-migration-7-steps.html

GWT offre des primitives basiques pour la création d’un arbre, qui sont :

• Le composant TreeItem : représente un nœud dans l’arbre et peut contenir de sous nœuds du même type.
• Le composant Tree : représente la racine de l’arbre et peut contenir des TreeItems

Construire un arbre revient donc à créer autant d’instances de TreeItem que nécessaire et des les assembler pour obtenir l’hiérarchie souhaitée.
Cependant, cette méthode n’est pas applicable dans le cas où :

• On dispose d’un grand nombre des nœuds (des centaines voire des milliers)
• La récupération des nœuds est coûteuse : accès à la base de données et/ou au réseau

Dans des cas pareils, mieux vaut être paresseux et ne charger des nœuds que quand nécessaire (ne charger les fils d’un nœud que quand l’utilisateur l’ouvre).
Dans le cadre de ce billet, et comme source de données pour l’arbre, on suppose disposer d’un service exposé en RPC dont voici l’interface :

package com.iptech.client;

import java.util.ArrayList;

import com.google.gwt.user.client.rpc.RemoteService;
import com.google.gwt.user.client.rpc.RemoteServiceRelativePath;

@RemoteServiceRelativePath("treeService")
public interface TreeService extends RemoteService {
	ArrayList<String> getChildren(String parent)
			throws IllegalArgumentException;
}

Dans l’implémentation de ce service, j’ai introduit (via un sleep) un délais de 2 secondes, pour simuler l’obtention d’une ressource coûteuse et pour que le comportement paresseux de l’arbre soit plus visible.

public class Application implements EntryPoint {
	private static final String CHARGEMENT_EN_COURS = "Chargement en cours ...";
	private final TreeServiceAsync treeService = GWT.create(TreeService.class);

	public void onModuleLoad() {
		TreeItem root = new TreeItem(CHARGEMENT_EN_COURS);

		Tree browseTree = new Tree();
		browseTree.addItem(root);

		treeService.getChildren(null, new TreeRootCallback(browseTree));

		browseTree.addOpenHandler(new OpenHandler<TreeItem>() {

			public void onOpen(OpenEvent<TreeItem> event) {
				if (needsLoading(event.getTarget())) {

					treeService.getChildren(event.getTarget().getText(),
							new TreeItemCallback(event.getTarget()));
				}
			}
		});
		RootPanel.get().add(browseTree);
	}

A noter que l’interface TreeServiceAsync (qui est la version asynchrone de TreeService) n’est pas présente dans le code source de cet exemple car elle sera généré automatiquement par GWT Maven plugin lors de la construction du projet.

Je commence donc par créer l’instance du composant du composant Tree et d’y ajouter un élément avec le message “Chargement en cours …”

J’invoque ensuite le service présenté plus haut pour récupérer la liste des nœuds racines de l’arbre. Cet appel se fait de façon asynchrone, d’où l’utilisation d’un callback dont voici le code :

public static final class TreeRootCallback implements
		AsyncCallback<ArrayList<String>> {

	private Tree browseTree;

	public TreeRootCallback(Tree browseTree) {
		super();
		this.browseTree = browseTree;
	}

	public void onFailure(Throwable caught) {
		caught.printStackTrace();
	}

	public void onSuccess(ArrayList<String> names) {
		browseTree.removeItems();
		for (String name : names) {
			TreeItem ti = new TreeItem(name);
			ti.addItem(CHARGEMENT_EN_COURS);
			browseTree.addItem(ti);
		}
	}

}

A la réception de la réponse, le callback supprime les éléments de l’arbre (le message “Chargement en cours …” plus précisément) et pour chaque chaîne retournée :

• Crée un item avec la chaîne comme texte et l’ajoute à l’arbre
• A chaque item crée ajoute un fils avec le message “Chargement en cours …“

Retournons à la méthode onModuleLoad.

L’étape suivante consiste à attacher à l’arbre un listener qui intercepte les évènements d’ouverture d’un nœud, et si ce dernier nécessite le chargement de ses fils (dans le cas où il a un seul fils et que ce dernier a le texte “Chargement en cours …“), fait appel à treeService en lui passant un autre callback dont voici le code :

public static final class TreeItemCallback implements
		AsyncCallback<ArrayList<String>> {

	private TreeItem treeItem;

	public TreeItemCallback(TreeItem treeItem) {
		super();
		this.treeItem = treeItem;
	}

	public void onFailure(Throwable caught) {
		caught.printStackTrace();
	}

	public void onSuccess(ArrayList<String> names) {
		treeItem.removeItems();
		for (String name : names) {
			TreeItem ti = new TreeItem(name);
			ti.addItem(CHARGEMENT_EN_COURS);
			treeItem.addItem(ti);
		}
	}
}

Ce second callback ressemble beaucoup au premier, excepté qu’il opère sur un TreeItem au lieu d’un Tree.

A ce propos, j’étais étonné du fait que Tree et TreeItem n’ont pas un ancêtre commun, bien qu’ils sont très similaires conceptuellement (tous les deux sont des conteneurs d’autres TreeItems, ce qui se fait trahir par le fait qu’ils partagent plusieurs méthodes avec le même nom et signatures).

Code source

Un projet maven avec le code source complet de ce qui a été présenté dans ce billet est disponible sous la licence MIT sur GitHub à l’adresse suivante : http://github.com/jawher/gwt-lazy-tree/

Une fois ce projet récupéré, il suffit d’exécuter la commande “mvn gwt:run” dans son dossier pour exécuter et tester cette application.

Apache Pivot est un framework de développement d’applications Internet riches (RIA). Du buzz autour de ce framework est en train de se produire sur la toile. Bien qu’entamé en 2007, Apache Pivot est mentionné de plus en plus ces derniers jours grâce à sa promotion au rang de “Top Level Project” par la fondation Apache en Décembre 2009.

En théorie, cela veut dire que les développeurs du framework, qui a rejoint Apache Incubator en Janvier 2009, respecte les principes et les process de la fondation, se basant sur la méritocratie. En pratique, cela signifie que le projet devient plus visible, et une certaine communauté de développeurs se formera autour du projet. On verra certainement plus de billets de blog, des exemples, de la documentation et des critiques autour du framework. La quantité et la qualité dépendra certainement du succès de celui-ci.

Tout développeur Java peut se demander comment se positionne Apache Pivot par rapport à JavaFX. Sur la page FAQ du projet, les développeurs présentent Pivot et JavaFX comme répondant à des besoins “légèrement” différents avant d’admettre que les deux technologies ne sont pas pour autant exclusives et que -je cite- “Pivot represents what we think Sun should have done instead of JavaFX.” (traduction: Pivot représente, à notre avis, ce qui aurait du être fait par Sun au lieu de JavaFX.)

A mon avis, Pivot se positionne comme une alternative sérieuse à JavaFX pour tout développeur Java travaillant sur un projet RIA. Les raisons sont assez claires:

• Le code est en Java (et non un langage de script à apprendre);
• Le développeur a l’option de programmer son interface graphique déclarativement (en XML);
• L’intégration avec les composants serveur est plus souple.

Dans la page de la proposition de projet à Apache Incubator, quelques comparaisons existent (formulées par les développeurs de Pivot) avec Swing, GWT et JavaFX.

Mon intention n’est pas de dire que Pivot est le framework de développement RIA par excellence, loin de là. A mon sens, ce n’est qu’un projet qui débute, mais qui reste prometteur.

Je vous invite à aller découvrir les démos et les tutoriaux, qui peuvent, je pense, être complétés par un exemple intégrant un traitement coté serveur avec Pivot. Un exemple que nous allons essayer de vous le proposer dans un prochain billet.

L’usage des documents électroniques dans les processus de collaboration, de communication et de prise de décision ne cesse de s’intensifier: Les décisions stratégiques se basent, entre autres, sur des analyses documentées. La communication intra et inter-entreprise, qui se base sur les messages électroniques et les sites web, se doit de cibler une large audience et représente un media de choix pour communiquer avec les partenaires et les clients.

Les éditeurs logiciels se sont très tôt intéressés au domaine de la gestion des contenus de l’entreprise ou Entreprise Content Management (ECM). Au fil des années la pile logicielle (l’ensemble des logiciels inter opérant au sein d’une entreprise pour compléter un processus métier) s’est complexifiée et a vu une multitude d’intervenants opérants entre eux. Cette interopérabilité est essentielle et même stratégique dans certains cas. Elle est aussi couteuse car les éditeurs sont peu enclins à dévoiler leurs protocoles et leurs interfaces, ceci venant s’ajouter à une hétérogénéité des langages informatiques.

A défaut de pile ECM intégrée, les entreprises se sont donc tournées vers le développement de solution ad-hoc. Tâche qui peut s’avérer ardue et qui aboutit, généralement, à un produit non réutilisable et difficile à maintenir.

Ceci n’est pas sans rappeler les problèmes auxquels furent confrontés les développeurs dans les années 80 avec les systèmes de gestion des bases de données (SGBD). Ce problème a été résolu par l’adoption de standards (ODBC, SQL …) par l’ensemble des fournisseurs de SGBD. Cette solution ayant fait ses preuves, les principaux protagonistes du monde ECM, c’est-à-dire Microsoft, EMC et IBM ont élaborés un nouveau standard nommé CMIS (Content Management Interoperability Services) pour mettre fin à cette véritable tour de Babel des ECM.

La première version de a été soumise fin 2008, et très vite elle a suscité l’intérêt de plusieurs acteurs du marché logiciel tel Alfresco, SAP et Drupal …

Suite à cet engouement, l’organisme de standardisation OASIS adopta le projet pour en faire une norme de l’industrie des ECM. Dès lors, les implémentations de CMIS ont commencés à apparaitre et le premier à en proposer une fût Alfresco suivi par ECM et IBM. Mais Microsoft ne proposa aucune solution pour son produit SharePoint et ce n’est que vers février 2009, que l’on voit apparaitre un article sur MSDN traitant du sujet.

Microsoft SharePoint : une success story

SharePoint est devenu au fil des années un des produits phares de Microsoft (plus de 1 milliards de dollars (US$) en licences vendues durant l’année 2008). Cette large implémentation en entreprise a favorisé l’éclosion d’une communauté très active autour de SharePoint notamment à travers le programme MVP de Microsoft, Codeplex et les clubs SharePoint un peu partout dans le monde.

La part du marché des ECM qu’occupe Microsoft est tellement importante que plusieurs entreprises se sont spécialisées dans l’édition de connecteurs spécifiques pour des logiciels tiers interagissant avec SharePoint. Microsoft devant cet engouement pour le développement sous SharePoint a fait preuve de bonne volonté; en intégrant les protocoles de communication SharePoint dans ses initiatives Open Protocol et Open specification. Ceci a conduit à l’apparition de plusieurs produits compatibles comme par exemple l’intégration de SharePoint dans OpenOffice.org.

La norme CMIS est dans la droite lignée de cette ouverture de Microsoft et sa participation à l’élaboration des standards. Mais malgré ses bonnes intentions, Microsoft reste en retard par rapport à ses concurrents en ce qui concerne l’implémentation des services CMIS, menaçant ainsi son adoption en tel que standard de l’industrie.

CMIS4SharePoint :

S’inscrivant dans un objectif de veille technologique, CMIS4SharePoint est avant tout une étude de faisabilité. L’objectif initial était de démontrer qu’une implémentation de CMIS en utilisant uniquement le modèle objet SharePoint était possible.

Au fil des développements, et après quelques concessions dues à la structure même de SharePoint. Il s’est avéré que cette implémentation était opérationnelle. La décision fût alors prise de faire profiter la communauté de ce développement, c’est ainsi que IP-Tech propose la première implémentation du standard CMIS pour la plateforme SharePoint.

L’architecture nécessite plusieurs aménagement du serveur SharePoint car il se base sur le .NET Framework 2.0 or nous utilisons WCF pour exposer les web services SOAP et REST. Ceci ne peut se faire qu’avec le .NET Framework 3.5 et un « tweak » de SharePoint pour rajouter le support de WCF.

Un scenario simple illustrant l’utilisation de CMIS, peut être la mise en place d’un outil pour l’utilisation offline de SharePoint. Cet outil peut s’avérer très utile pour fournir une meilleure expérience utilisateur dans l’utilisation de SharePoint, car il bénéficie de la puissance de calcul des clients lourds. Aussi on peut envisager sa réutilisation pour d’autres ECM, tel Alfresco ou FileNet. Ainsi, si l’entreprise procède à une migration elle sera presque transparente pour l’utilisateur final. Il conservera la même interface graphique et les mêmes habitudes de travail évitant le réapprentissage imposé par chaque changement d’ECM.

Pour illustrer la facilité qu’apporte l’abstraction CMIS à la création des outils, nous avons développé un client qui liste le nom et l’URL de l’ensemble des bibliothèques de documents disponible dans un site SharePoint.
Pour tester CMIS4SharePoint il faut commencer par créer sur une machine cliente (autre que le serveur SharePoint) un nouveau projet Console sous Visual Studio 2008. On appellera ce projet “ClientTestCMIS”.
Après la création de ce projet, faites un clique droit sur le projet dans explorateur de solution, et sélectionnez “Ajouter référence de services” (Add Service Refrence).

Dans la boite de dialogue qui s’est ouverte, saisissez l’adresse de votre service, appuyez sur “Go” puis sélectionnez le service retrouvé, comme l’illustre cette capture :

Renommez le Namespace du service puis validez.
Maintenant Visual Studio a généré un proxy qui reprend tout les services exposé, il ne reste plus qu’a implémenter le programme dont voici le code source:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using ClientTestCMIS.CMISReference;

namespace ClientTestCMIS
{
    class Program
    {
        static void Main(string[] args)
        {
            //création du proxy qui va nous permettre de consommer les services
            RepositoryServiceClient repositoryClient = new RepositoryServiceClient();

            //ouverture de la liaison
            repositoryClient.Open();

            //envoi de la requête pour l’obtention de
            //la liste des repositories (des bibliothèque de documents)disponible dans le site SharePoint
            cmisRepositoryEntryType[] repositories = repositoryClient.GetRepositories();

            //fermeture de la liaison
            repositoryClient.Close();

            //affichage du nom et de l’url de chaque bibliothèque de document
            foreach (cmisRepositoryEntryType item in repositories)
            {

                Console.WriteLine(”Name={0}\nURL={1}\n”, item.repositoryName, item.repositoryURI);

            }
        }
    }
}

Perspectives

L’avenir de CMIS4SharePoint est totalement lié à l’intérêt qu’il suscitera auprès de la communauté. Du chemin reste à faire avant de pouvoir proposer une implémentation totalement opérationnelle mais ceci ne saurait tarder.

CMIS4SharePoint peut être utilisé comme une base pour de applications plus élaborée afin de promouvoir l’utilisation de CMIS. Car un standard qu’on n’exploite pas est un standard qui ne sert à rien. CMIS ne subira pas le même sort que les autres tentatives de standardisation des ECM et tout comme JCR il ne sera pas classé comme « une norme de plus ! » (Just another standard !).