AlcionTech

Modèles et meta-modèles :

• Un modèle est un graphe orienté obéissant à un méta-modèle.
• Les méta-modèles peuvent être issus d'organisme de normalisation (comme le méta-modèle UML, défini par l'OMG), mais on peut aussi en créer soit-même.
• Une transformation permet de convertir automatiquement un graphe d'un méta-modèle vers un autre.

Récursivité : Méta-modèles et transformations peuvent être représentés sous forme de graphe et sont donc des modèles. Par exemple pour définir le format des meta-modèles, on utilise un méta-méta-modèle (qui s'auto-décrit, au sens où il est lui-même son propre méta-modèle).

Analogie avec le monde XML :

• le modèle => document XML
• le méta-modèle => DTD ou XML-schéma
• la transformation => feuille de style XSL-T

Néanmoins XML ne sait représenter que des arbres ce qui est moins général qu'un graphe.

Exemple de transformation :

On peut définir un méta-modèle pour représenter la syntaxe du langage Java, puis définir une transformation diagramme de classe UML => méta-modèle Java, afin de personaliser la génération de code de son modeleur favori.

Application au MDA

Dans une approche MDA, on a généralement un PIM (Platform Independant Model) qui décrit le fonctionnel de l'application et qui est ensuite transformé en PSM (Platform Specific Model) suivant la plateforme ciblée (Java Spring/Hibernate, Java J2EE, .NET), ce dernier devant être à son tour transformé pour générer le code.

Liens :

• QVT : un standard de l'OMG pour définir des transformations :
• ATLAS Transformation Language : outil du projet Eclipse pour définir des transformations
• Présentation sur ATL

Il y a maintenant un peu plus de trois mois, des ingénieurs d'Alcion Group ont suivi une formation "Talend Foundation" sur l'ETL Open Source Talend Open Studio. Ils proposeront bientôt dans le cadre d'un Alcion Bar une conférence interne pour présenter ce produit intéressant.

Mais en attendant cette soirée, ils ont mis cette formation à profit en développant de nouveaux composants pour cet ETL, afin de mieux gérer les bases de données Informix (qui sont utilisées sur un des projets au forfait actuellement développés).

Alcion Group ayant décidé de jouer le jeu de l'Open Source, ces composants ont été cédés à la communauté :

• tInformixConnection, permettant d'initialiser une connexion à une base de données Informix ;
• tInformixCommit, permettant de faire un "commit" des opérations effectuées sur une connexion ;
• tInformixRollback, permettant de faire un "rollback" des opérations effectuées sur une connexion ;
• tInformixInput, évolution du composant original permettant de récupérer des données à partir d'une connexion existante ;
• tInformixOutput, évolution du composant original permettant d'insérer des données dans une table en utilisant une connexion existante ;
• tInformixRow, évolution du composant original permettant d'exécuter une requête SQL quelconque en utilisant une connexion existante ;
• tInformixSP, qui permet d'exécuter des procédures stockées et fonctions d'une base de données Informix ;

Je me permet de copier ici (avec quelques modifications) le contenu d'un post de mon blog personnel... qui lui-même reprenait un billet du blog java de developpez.com signalant la sortie de la nouvelle version de l'outil Leonardi.

Les principales nouveautés de ce produit étant décrites dans le billet que je site, je ne les recopierai pas. En revanche, je ferai une (très) rapide présentation de l'outil (un résumé des informations que l'on peut trouver sur le site de Lyria), ainsi que du paradigme MDA auquel il se rattache.

Je suppose que bon nombre d'entre vous connaît le site http://www.developpez.com/, la plus grosse communauté virtuelle de développeurs francophones (tous langages confondus), ses blogs techniques, et ses forums, qui sont une référence lorsqu'on butte sur un problème technique.

Depuis maintenant 3 jours, ce site a subi une grosse mise à jour, visant à accentuer le côté "communautaire":

• possibilité d'annoter les profils des membres (principe des évaluations Ebay ou des "messages sur le mur" de Facebook)
• possibilité de créer des albums de photos
• possibilité de créer (ou de rejoindre) des groupes d'utilisateurs par centre d'intérêt.

Derrière cette mise à jour, on peut voir une tendance assez généralisée du web à s'orienter vers les systèmes communautaires (Ebay ayant été un des précurseurs en la matière, en allant jusqu'à créer un vocabulaire dédié partagé entre "ebayeurs et ebayeuses"): les nouvelles fonctionnalités proposées par http://www.developpez.com/ rejoignant finalement celles proposées par d'autres sites communautaires (Facebook, LinkedIn, Viadeo, etc.).

En juin et en juillet, de nombreux projets liés à java ont bien évolué. Voilà un petit résumé de ces évolutions (outre la sortie de la nouvelle version d'Eclipse Ganymède à laquelle un billet complet a été dédié):

• Le JDK de Java 6 est passé en update 7. Cette nouvelle version inclut VisualVM, un outil de monitoring.
• Sortie de nouvelles versions de deux projets de l'Apache Software Foundation: Apache POI 3.1, l'API de manipulation des fichiers Microsoft Office et JMeter 2.3.2, un outil de tests de charge.
• Après Eclipse, c'est au tour de NetBeans de sortir une première "MileStone" de sa version 6.5.
• Le serveur d'application JBoss vient de sortir une première "Release Candidate" de sa version 5.0.

Par ailleurs, Sun a publié un compte-rendu des différentes présentations techniques qui y ont été faites lors de JavaOne session 2008.

Il existe de nombreuses règles de "bonnes pratiques" en programmation objet, dont certaines sont spécifiques au langage java. Il existe des formations et des ouvrages entiers consacrés à ce sujet: je n'ai donc absolument pas la prétention d'en faire la liste ici. En revanche, j'aimerais attirer l'attention sur le fait qu'il existe maintenant des outils faciles à mettre en oeuvre, et permettant de vérifier automatiquement un certain nombre de ces règles de "bonnes pratiques". Ils permettent d'améliorer significativement la qualité du code, pour un faible coup (à condition qu'ils soient déployés le plus tôt possible dans le processus de développement).

Depuis maintenant plus d'un an, la Wii s'est imposée comme un énorme succès commercial de Nintendo, principalement a cause de sa manette, la "Wiimote", et de son gameplay révolutionnaire. Celui-ci permet effectivement de passer de très bonnes soirées entre amis, mais a également donné l'idée à des chercheurs d'analyser son fonctionnement, afin d'y trouver d'autres applications. Cette page consacrée à la Wiimote du professeur Johnny Chung Lee explique en images son fonctionnement, en trois parties:

• une présentation du principe de fonctionnement de la Wiimote.
• une application pratique, dans le domaine de la bureautique et du travail collaboratif.
• une application à ce qui pourrait être "l'avenir de la télévision", avec une démonstration de "headtracking" impressionnante.

PS: si certains ont envie de bricoler et d'utiliser leur console autrement, le professeur Chung Lee a mis à disposition les codes sources de ses applications d'exemple (programmées en C#).

Je me fais un petit peu de pub:

Si vous êtes intéressés par les technos du Web 2.0 (javascript, html, css, php,...) et la représentation cartographique de données, je vous invites à faire un passage par mon site perso. Vous y trouverez plusieurs projets de veille technologique sur ces sujets, dont un à même eu le privilège d'être 'Mashup of the day" sur programmableweb.com.

• Mapified Kayak: une jolie couche de présentation pour le métamoteur de recherche de voyages Kayak, et la possibilité de rechercher plusieurs destinations et dates d'un coup (Google Maps + Kayak API).
• Overflown Countries: pour savoir quels pays vous survolez lors de vos voyages (Google Maps + Geonames API).
• Mapified Stock Indices: une présentation géolocalisée des variations d'indices boursiers asiatiques (Google Maps + Geonames + Dapper API).
• Mapified Rss: pour géolocaliser n'importe quel flux RSS et mettre en surbrillance les pays (Google Maps + Geonames API).
• GoogleMaps vs YahooMaps: les 2 cartes sur la même page pour comparer facilement les niveaux de zoom disponibles. Une fonction de synchronisation est fournie (Google Maps + Yahoo Maps API).
  

Bien que personnels, ces projets constituent également des démos pour présenter notre offre E-business et les compétences des ingénieurs d'Alcion dans ce domaine. Dans cette optique, si vous êtes vous-mêmes ingénieurs d'Alcion, n'hésitez pas à faire partager vos projets logiciels sur ce blog.

On sait bien que la patience de l'utilisateur d'une application informatique est une denrée précieuse qu'il convient de préserver au maximum, surtout lors d'une 1ère utilisation.
Les équipes de Yahoo! se sont intéréssés au problème dans le cadre des applis Web et ont élaborés des règles à étudier de près. Parmis celles-ci, la 10ème: "Minify JavaScript". En effet avec l'avènement d'AJAX, les clients légers ont souvent besoin de requêter auprès de serveurs des scripts de plus en plus lourds dont le temps de récupération peut parfois entamer largement le capital sympathie d'une appli.
Après avoir testé plusieurs solutions de compression, je vous recommande Javascript Compressor. Il m'a permis de réduire la taille d'un script en production de 35kO à 24kO. Cet utilitaire permet également d'obfusquer son code et donc de le protéger si jugé sensible. Ce cryptage a également des effets bénéfiques sur la taille puisque dans le cas de notre script précédement évoqué, on est passé à 15kO. Ce dernier restant bien sure complètement opérationnel...

Je profite de ce billet pour vous inviter à préparer vos vacances en visitant la page de ce projet de veille technologique de la DT autour des technos Web 2.0 (AJAX, Web Services, Google map, frameworks javascript): MapifiedKayak. Un peu d'indulgence svp, ce n'est qu'une beta...

Il est devenu très fréquent de voir des données affichées dans un composant cartographique de l'IHM d'une application. Les parisiens penseront peut-être tout de suite à celui de Velib' qui permet de localiser rapidement les stations et la disponibilités des vélos. Il est clair qu'une telle présentation est beaucoup plus ergonomique que le rendu dans une grille.
Pour atteindre un tel résultat, il convient de pouvoir répondre à 2 questions:

• Comment géotaguer ses données?
• Comment présenter ses données?

Comment géotaguer?
Il existe plusieurs services permettant de géotaguer ces données c'est à dire associer une longitude et latitude à une entité localisable (adresse, code postal,etc) . On recommendera ceux de Geonames.org et Google. Les formats de sortie sont au choix xml ou json.
On notera en particulier l'existence d'un service très intéressant de conversion de feed RSS vers geoRSS. C'est ce service qui est utilisé dans notre application sur les indices boursiers (voir billet précédent) ou bien pour localiser les dernières news planétaires.
Il peut parfois être intéressant de faire du géocodage inversé, c'est à dire associer une addresse (souvent approximative) à un couple (latitude, longitude). On trouvera ici plusieurs services intéressants. Notez que google ne propose pas (encore) de tels services.
Un autre besoin peut consister à localiser des addresses IP. Il existe là encore plusieurs services dont IP2Location utilisé par le fameux wikiscanner.


Nota: Pour des besoins locaux, Les BD sous-jacentes peuvent souvent être installées en local moyennant leur achat.

Comment présenter ses données?
L'insertion d'entités géotaguées dans une carte est assez direct chez Google map comme chez Yahoo! map. L'API Google utilise un objet GGeoXml dont le constructor prend le fichier de données géotaguées en paramètre. L'objet YGeoRss fait de même chez Yahoo! map.

Dans un billet précédent de ce blog, nous avions vu qu'il était possible de construire des flux rss (dapper) et de géolocaliser leur contenu (yahoo!pipe). Nous avions pris comme exemple les variations des indices principaux des bourses asiatiques.
La présentation par défaut sur la page du pipe a le bon goût d'exister mais convenons que le rendu n'est pas percutant. Il faut en effet cliquer sur chaque marqueur pour avoir les informations.
L'idéal serait d'avoir des marqueurs représentatifs de la variation de l'indice, vert quand positif, rouge quand négatif, avec une taille proportionnelle à cette variation.
Pour arriver à ce résultat, il faut un peu programmer. Un API maps est fourni par Google et Yahoo! donc nous allons travailler avec les 2 pour comparer.
Le principe est relativement simple, dans chaque carte (YMap et GMap), pour chaque pays présent dans le flux RSS, on ajoute un marqueur (YMarker, GMarker) personnalisé (YImage ou GIcon). La hauteur du marqueur est ajustée par la formule Math.round(Math.abs(fChange) * 20) et donc d'avoir une hauteur de 20px pour une variation d'indice de 1%. Le fichier source est disponible en annexe (fonction fFillYahooMapWithGeo et fFillGoogleMapWithGeo).
Les résultats sont visibles ci-dessous, avec à gauche Google en haut et Yahoo en bas.

Sur le plan fonctionnel, un léger avantage à Yahoo! qui permet d'afficher un label par un simple passage de la souris sur le marqueur alors que Google nécessite de cliquer dessus.
Les métriques ne font pas apparaitre de différences significatives entre les 2 API:

• Temps de chargement: environ 4s,
• Nombre de requêtes: légèrement plus pour Yahoo (71 contre 54),
• Octets téléchargés: environ 400kO,
• Nombre de lignes de code propres aux API: une dizaine.
  

Les 2 API offrant un services de géolocalisation, nous pouvons donc essayer d'utiliser directement le flux RSS de Dapper (non géo-localisé) et confier la tâche de géolocalisation aux API. Yahoo le permet très simplement en remplacant un paramètre d'entrée du constructeur de YMarker mais les requêtes sont synchrones (fonction fFillYahooMapWithoutGeo dans le source). L'API Google est plus délicate à mettre en oeuvre car il faut utiliser un objet GClientGeocoder et utiliser une fonction de callback.
Dans les tests, il a été constaté un léger ralentissement (environ 1s) avec cette méthode à cause d'une plus forte utilisation du réseau (17 requêtes de plus).

Avis subjectif de l'auteur:

• Aucune API ne se démarque de l'autre. Celle de Google est légèrement plus complexe mais compense par légèrement plus de fonctionnalités.
• Notre application est bien exigeante en bande passante et temps d'UC puisqu'elle nécessite de mettre en forme le HTML chez Bloomberg, de transférer ce flux de Bloomberg à Dapper qui est alors retraité en RSS, de transférer de Dapper à Yahoo pour géolocaliser, puis enfin de Yahoo au client. Si Bloomberg (ou un autre) fournissait directement le flux rss (idéalement déja géolocalisé et gratuitement), on ne serait pas obligé de faire tout cela :)
  

PS: La démo utilise l'objet XMLhttpRequest qui n'autorise pas chez Firefox les requêtes hors du domaine courant, alors que si chez IE. Donc

• si vous utilisez IE, mettez simplement "urlProxy":"" à la ligne 29 dans maps.htm,
• si vous utilisez Firefox, installez un serveur local (localhost) avec la page php_proxy_simple.php fournie en annexe,

Tim O'Reilly le considère comme le service qui va changer l'internet parce qu'il met enfin le web en tant que BD à la portée des non-informaticiens.
Ce service, c'est Yahoo!Pipes et ca permet de faire des aggégations très intéressantes.
Prenons l'un de ses exemples phares: le GeoAnotated Reuters News. Ce pipe récupère les 10 titres à la une dans un rss Reuters et alimente un service de conversion rss vers georss pour fournir un georss. Si vous regardez le source, vous verrez la présence des balises xml <geo:lat> et <geo:long>.
Ce flux est ensuite traité pour afficher les résultats dans une carte.

Evidemment, il ne vous a pas échappé qu'il était déja tout à fait possible de coder cela soi-même avec des HttpRequest pour peu d'avoir les compétences en javascript adéquates. La grande force de Yahoo!Pipes est d'offir une IHM masquant la complexité du code et de permettre le clônage des pipes produits.
Yahoo! Pipes et Dapper (vu dans le précédent billet) sont très complémentaires puisque le 1er peut produire le rss si celui-ci n'existe pas dans un site et le 2ème le manipuler aisément. Par exemple, si l'on souhaite représenter sur une carte les évolutions journalières des bourses asiatiques, on créé le Dapp à partir de Bloomberg, puis le pipe pour géolocaliser les bourses.

Les Rich Internet Applications présentent bien des avantages mais il faut leur reconnaitre un inconvénient majeur du point de vue de l'ingéniérie logicielle: l'obligation de gérer différents navigateurs.
Le marché des navigateurs est dominé par 2 acteurs: Microsoft Internet Explorer (avec environ 80% de PDM en légère décroissance) et Mozilla Firefox (avec environ 15% de PDM en légère croissance). Si IE6 domine encore (45% de PDM), IE7 prend petit à petit sa succession (35%). Du côté de firefox, la version 2 est devenue ultra-majoritaire. Le bilan est donc qu'il convient de veiller en ce moment à la compatibilité de son application avec 3 navigateurs dans le cas d'un développement destiné au grand public.
Il existe des technologies permettant de faire abstraction du navigateur comme les applets Java ou Flash mais cela oblige l'utilisateur à posséder une JVM ou des plugins spécifiques (dans la bonne version) ... et l'ingénieur les compétences.
Une des grosse tendance de ces dernières années est l'utilisation d'AJAX, ce qui revient à utiliser le javascript, le DOM et les feuilles de styles. Si les choses se passent bien en terme de portabilité avec la syntaxe du javascript, les ennuis apparaissent lorsqu'on accède au DOM, chaque browser ne gérant pas les mêmes entités. Les spécifications du W3C vont vers une standardisation mais celle-ci est lente. On retrouve exactement le même phénomène avec les feuilles de styles (les specs sont ici).

Pour y avoir passé plus d'heures que je n'aurais voulu sur différents projets, il est fondamental d'éviter le champ de mines du cross-browser compliance si l'on veut respecter les délais d'un projet de RIA. Pour cela on s'appuiera au maximum sur les librairies et frameworks disponibles en veillant à régulièrement tester le rendu dans les navigateurs cibles et surtout pas uniquement à la fin des développements.
Notez bien que les librairies ne font pas tout. La RIA Alcionbooks est par exemple non complètement fonctionnelle sous IE dans sa V1.0 malgré l'utilisation de scriptaculous et de nombreuses heures passées dessus par Eric.

Dans un univers opensource très mouvant, il est bon d'avoir quelques repères.

Le site Infoworld vient de sortie son cru 2007 des Bossie awards qui vise à distinguer les meilleurs logiciels opensource destinés aux entreprises. Il y a différentes catégories dont le software development.
On extrait particulièrement 3 résultats:

• Rich Internet application framework: OpenLaszlo
• AJAX toolkit: Tibco General Interface
• Continuous integration: Cruise Control

N'hésitez pas à donner votre avis sur ces résultats...

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).

UPDATE: Précisons que l'intégration continue peut très bien se coupler à n'importe quelle méthodologie de développement logiciel: cycle en V, Unified process, Scrum, Extreme Programming, ....

Un sujet actuel: l'intégration continue (continuous integration) est une stratégie de génie logiciel visant à répérer le plus rapidement possible les éventuelles régressions d'une application par passage de jeux de tests dès la mise en version du code.
On trouve une très bonne introduction sur le site de Martin Fowler, père du terme.
Alcion Group possède une plate-forme d'intégration continue pour .NET autour de Nant et CruiseControl dans le cadre du projet MGV et des études sont faites pour un avoir une pour J2EE (Maven, Continuum, ...).

Si vous même avait une expérience du sujet, n'hésitez pas à en faire part dans les commentaires.

Comme beaucoup le savent, la génération de nombres aléatoires n'a jamais été vraiment aléatoire en informatique.
En C++ par exemple, on utilise généralement les fonctions srand() et rand() fournies par la librairie standard.

Tout cela pourrait bien changer prochainement avec l'apparition d'un nouveau service online gratuit appelé Quantum Random Bit Generator qui permet d'obtenir de véritables nombres aléatoires en s'appuyant sur le phénomène physique quantique d'émission de photons dans les semiconducteurs.

A découvrir absolument...

Merci à Aurélien Drouet pour son intervention convaincante :

• Les slides de l'open bar d'hier soir
• le how-to de la démonstration
• ci dessous, une liste de liens précieux.

OSCache est une solution de cache opensource Java qui se présente sous trois formes : filtre de servlet, taglib JSP et API.

Nous avons employé cette solution dans le cadre de la refonte d’un site Internet à grande fréquentation. Voici, en quelques points pratiques, ce qui distingue OSCache des autres solutions opensource.

Le commencement de tout projet, nouvelles technologies ou autre, nécessite la mise en place d'un socle technique sur lequel va reposer l'ensemble de la logique métier de l'application future. L'expérience montre que bon nombre de développeurs, ont recours à une sorte de boite à outils qu'ils ont dû mettre en en place petit à petit au fil des projets et qui se compose de frameworks, classes utilitaires, bonnes pratiques etc.

Jaxio propsoe une solution élégante basée sur un générateur d'application reposant sur le modèle de la base de données pour générer le squelette de l'application. En quelques minutes, le temps du lancement du générateur, une application packagée est prête à être déployée sur, en théorie, n'importe quel serveur J2EE.

L'application résultatnte est plus qu'un socle technique: elle propose la majeur partie des widgets qu'on trouve dans une IHM classique: tri, pagination, changement de look and feel en quelques clicks

Un système de messaging entreprise permet de faire communiquer des applications à travers des messages. Les Système de messaging ou MOM (Middlewares orientés messages) les plus courants: Rendez vous (Tibco), MessageQ(Bea), MQ Series (IBM) ...

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.