AlcionTech

Je reprends ici deux billets d'actualité publiés sur mon blog personnel :

• le premier, qui a fait suite à l'indisponibilité des mails Google de ce 24 février. Ce billet fait suite à celui posté ici même, qui ventait les mérites des "Google Apps" : malgré la récente indisponibilité des mails et la "mini-crise virtuelle" qui a suivi, je persiste à croire que Google offre des solutions tout à fait viables pour les PME (mails, calendriers, etc.), avec de nouvelles fonctionnalités qui vont dans ce sens (Google pour mobiles, consultation et rédaction de mails hors-ligne, etc.).
• le deuxième est un résumé de la conférence de lancement de Quotero 1.0 (à laquelle j'ai assisté), une GED Open Source.

UPDATE 09/20/2007: V1.5 released with several code improvements to be cross-Browser compliant. This version uses the localhost web proxy by default (see why here) and the scriptaculous library.

When you manage a set of application software, more often than not it's time wasting to check if it's still up to date by browsing home site by home site. Here comes the freely available Dashboard of software release versions annexed to this article.
It's based on a xml file where you store data about your own configuration, application by application in a similar way to the sample below.

	<application>
		<!-- URLradical is taken from the wikipedia url-->
		<URLradical>Apache_Tomcat</URLradical>
		<currentVersion>6.0.13</currentVersion>
	</application>

The dashboard is a HTML page which retrieves data from both the xml file and wikipedia using Microsoft.XMLDOM and Msxml2.XMLHTTP objects. Everything is done client-side. In other words, no http server is required.

The screenshot of the dashboard related to our continuous integration platform tells us at a glance that new versions of Apache Tomcat, Apache HTTP server and Subversion have already been released since the release of the platform.

Known limitations:

1. depends on the content of wikipedia pages (more precisely the infobox software tag. For example, Apache Continuum has no infobox yet, thus the error in the screenshot).

Oracle a annoncé hier lors de la conférence EclipseCon que Toplink sera cédé à l’Open Source sous l’égide du Projet Eclipse.
Tout sauf des spécificités liées à Oracle AS est concerné (même les fonctionnalités encore en cours de developpement)

Le portail ultime ? Capable de fournir à chaque employé les applications dont il a besoin, sur son bureau. En prenant en compte la gestion des droits, et un déploiement totalement managé, particulièrement adapté aux grandes flottes.

C'est en tout cas l'a vision d'IBM qui vient de lancer, via sa filiale Lotus, le framework "Expeditor" pour assembler tout type d'IHM, a priori dans un contexte Windows, et reposant sur Eclipse et Websphere.

La concurrence ? Est clairement visé Microsoft, dont la nouvelle technologie Avalon/XAML, devenant dans l'ère Vista la couche de présentation de .NET, pourrait prétendre à l'ubiquité, sinon à l'universalité.

Une fonction originale de ce remplaçant de Websphere Everyplace : la capacité d'assembler des portlets (JSR169) qui tournent directement sur le poste client et fonctionnent donc en déconnecté... à condition de disposer de 512Mo de RAM. Et bien sûr, ça tourne également sur Linux.

Java est enfin devenu compatible avec les applications temps réel. Le principe du garbage collector empêchait en effet une exécution prédictible, capable de garantir des temps de réponse sous un délai imparti. Aujourd'hui, l'implémentation de référence permet de gérer des lantences quantifiées de l'ordre de 20 microsecondes.
http://java.sun.com/javase/technologies/realtime.jsp

Première étape : la concrétisation de la JSR001, the "Real Time Specification for Java", qui définit des modifications profondes : une API et des ajouts à la JVM. En résumé :

• Deux nouveaux types de threads, dont un ne pouvant pas être interrompu par le garbage collector, et assurant un respect absolu des priorités (ce que l'implémentation standard ne garantissait pas) sur 28 niveaux
• Deux nouveaux espaces mémoire, ne faisant pas l'objet de garbage collection : l"immortal memory", jamais désallouée (prudence !), et la scoped memory (détruite à la sortie du scope). Des fonctions de l'API permettent l'allocation dans ces espaces.
• Deux mécanismes spécifiques aux applications temps réel : la prise en compte d'événements asynchrones ("happenings") et d'un chronométrage à la nanoseconde,
• L'accès direct à la mémoire physique permettant de coder des drivers en java plutôt qu'en C/C++ appelé par JNI. Ici aussi, prudence !
  

Deuxième étape : la disponibilité de machines virtuelles implémentant cette nouvelle norme. C'est chose faite, nous en avons au moins deux :

• L'implémentation Sun (Java Real Time System ou JavaRTS), sous forme d'add-on au JDK 1.4.1, fonctionnant uniquement sur Solaris/Sparc pour l'instant (la promesse d'autres plates-formes a été faite, avec la limitation que JavaRTS repose entièrement sur les qualités temps-réel de l'OS sous-jacent, Solaris en l'occurrence)
• L'implémentation de TimeSys, qui est lead sur la maintenance de la spécification et auteur de l'implémentation de référence : http://www.timesys.com/java/
  

Le modèle retenu permet de créer des systèmes complexes nécessitant de la logique temps-réel (réponse en temps imparti) combinée avec de larges portions de code n'ayant pas les mêmes exigences, codées en java "standard". A noter également des implémentations de corba tirant parti de ces nouvelles propriétés.

En 1998, CORBA a failli devenir le standard de communication pour les applications distribuées. En 2006, Corba n'occupe plus que quelques niches dans un écosystème qui s'est à présent enrichi de RMI, des Webservices, et de l'EAI. Cet article pointe comment les déficiences du processus de standardisation ont conduit à cette situation. Une leçon à retenir quand nous faisons des choix technologiques : privilégier les principes éprouvés, qui marchent, qui ont été testés. http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=396