JoSQL interroge votre mémoire en SQL !
Par Laurent simon le mercredi, 7 septembre 2005, 17:03 - Développer - Lien permanent
Au détour d'une déambulation sur le web, je suis tombé par hasard sur JoSQL. Je ne lui ai pas encore trouvé de véritable utilité mais le concept m'a bien amusé en tout cas.
JoSQL permet d'interroger, de filtrer, de regrouper et de trier des collections d'objets Java résidants en mémoire. Le tout à partir d'une syntaxe proche de SQL. Ca donne des choses comme ça par exemple :
SELECT *
FROM java.io.File
WHERE name $LIKE "%.html"
AND lastModified BETWEEN toDate('01-12-2004')
AND toDate('31-12-2004')
La source de données est toujours une collection. Mais, il sait également naviguer sur l'ensemble du graphe en exploitant les attributs et méthodes des objets présents dans la collection. Ainsi il est possible d'exprimer des choses comme :
SELECT *
FROM java.io.File
WHERE
parentFile.lastModified
BETWEEN toDate('01-12-2004') AND toDate('31-12-2004')
AND parentFile.name = "local"
Amusant non ?
Commentaires
Pas amusant (bien que j'aime m'amuser) mais ESSENTIEL pour certains type de dev
Je pense en particulier aux SMA : systèmes multi agents C'est de l'intelligence artificielle distribuée
Et pouvoir évaluer les ressource est un des aspect primordiale de ce type de dev
Ca pourrait (a voir) raccourcir le temps et la complexité des dev orienté IA distribuée
Ce qui serait top serait de pouvoir affiner la requête en ajoutant des contraintes sur les valeur de retour d'une (ou +sieurs méthodes
En effet en IA on cherche les ressources dispo mais plus particulièrement des ressources répondant à un état spécifique
Ce que je trouve amusant, c'est d'utiliser du SQL. On s'attendrait plutôt à voir de l'OQL pour ce type de traitements.
L'approche est très intéressante pour pas mal de traitements mais une implémentation comme JoSQL manque de souffle pour être utilisée à grande échelle. Pour être réellement efficace, il faudrait quelque chose qui génère du bytecode à la volée.
Ca me fait d'ailleurs penser qu'en 98 j'avais écrit quelque chose dans le genre (OQL + génération de bytecode). Si ça intéresse quelqu'un je peux faire des recherche dans mon placard.
Microsoft s'intéresse d'ailleurs également à la chose au travers de COmega, une extension du langage C# dans laquelle il ont intégrê nativement le XML et le SQL pour travailler aussi bien en mémoire que sur des sources de persistance externes.
Si tu génère du bytecode à la volée tu ne riqsue pas d'avoir de gros problèmes d'implémentation pour gèrer les références dynamiques ??
En plus j'ai bien réfléchit. Ce truc est interessant en IA mais limite à des prog mono machine alors que la tendances est à l'utilsiation d'arcitecture réparties pour de multiples raisons:
Donc ce qu'il faudrait c'est un système distribué, gérant le "RAid objet" Du boulot !
PS : si une entreprise a une petite bourses de thèse ou de recherche appliquée je suis preneur pour développer le truc
Non la résolution des références ne pose aucun problème particulier. Avec l'intropection dynamique des classes, lors de sa création, la requête est compilée avec les mêmes règles que lors de la compilation de code Java.
Le truc que j'avais fait en 98 ne s'exécute pas sur différentes machines. Par contre fin 96, début 97, pour TOTAL, j'avais créé celui qui fut son prédécesseur. L'engin, bien que rudientaire, permettait de faire des requêtes portant sur des données provenant simultanément de différentes sources (tables Oracle et services des progiciels SAP et R5). La glue entre tout ça était un moteur s'exécutant en mémoire ( un peu comme JoSQL mais avec de l'OQL) dans un environnement distribué. La requête initiale s'éclatait en plusieurs requêtes sur diffêrentes machines. La seul différence avec ce que tu évoque en ce moment, sur les agents c'est que les services n'étaient pas redondants.
C'est d'ailleurs amusant que tu me parle d'agents, Agentis m'a récemment sollicité pour leur monter une solution de généation automatique d'applications basée sur leur système d'agents. Je risque d'être rapidement immergé dans les agents si nous faisons affaire.
Arg... tu me donne des complexes, je n'ai pas un aussi bon niveau de dev que toi dans ce domaine
Vivement que je me retrouve avec du temps et des moyens devant mon Eclipse pour redévelopper des trucs d'un bon niveau en Java
PS : pour la génération automatique d'appli tu est obligé de te baser sur des "primites d'objets" que tu "assemble" en fonction d'un scénario ?
Si oui ca t'impose un couplage très fort scénario/code source. Ou alors tu as trouvé une autre solution pour créer de la génération automatique d'appli ?
Car on en revient tojours au meme problèmes :
Non je n'utilise aucune primitive pré-définie. L'analyse du besoin exprimé, l'étude technique et le codage sont faits intégralement par le générateur (il est bien sur possible de lui donner des directives). La seule matière à fournir en entrée, ce sont les specs fonctionnelles. Elles sont effectivement exprimées avec une notation qui est universelle.
En gros, c'est du MDA++ ou au lieu de partir de modèles UML qui sont déjà le fruit d'une étude, on part directement des specs fonctionnelles qui décrivent des processus purement métier (au vrai sens du terme).
Pour ce qui est de l'intégration des briques dans un environnement agents, là pas de problème. Le générateur créant toutes les briques, l'ensemble est de fait toujours cohorent.
Pour une intégration plus large avec le monde extérieur, à terme des solutions purement sémantiques ont de bonnes chances de voir le jour ( RDF + OWL + SPARQL par exemple).
Se suis dégoûté, je n'arrive même pas à imaginer comment tu arrive à coder un truc pareil.
Vite du Java à haute dose ;=)
Même si c'est du MDA, le méta modèle qu'est MDA apporte il une sémantique suffisante pour ne pas avoir à définir certains concepts métier ???
Je ne connais pas (encore) MDA, mais pour UML par exemple la corrélation UML/Code source n'est pas toujours bijective.
C'est souvent au dev (selon des choix politiques) de faire des choix quant à l'implémentation
Par exemple si tu qualifie une propriété
Ordereden UML cela peut donner une collection ordonnée mais ne te précise aucunement quel type de collection ordonnée tu vas choisir dans ton frameworkOui tout à fait. Le développeur a plusieurs possibilités. Pour choisir une implémentation, il s'appuie par contre sur des données objectives qui n'ont rien à voir avec la programmation (ni même avec l'informatique), telles que la fréquence d'occurrence des événements métier, le type d'usage dominant de chaque information (lecture, écriture), le nombre maximal d'occurrences, le fait qu'elle soit accédée ou non de façon simultanée, les règles associées (éléments uniques ou pas), etc. Toutes les informations qui permettent de prendre la décision sont déjà disponibles au niveau du métier. Le développeur n'invente rien (heureusement). Il se contente de mettre en place le pattern qui lui semble le plus appropriée en fonction de la situation qu'il rencontre et des règles qu'il s'est lui même fixées (fruit de son expérience).
Avec le générateur c'est pareil, d'un côté on décrit des specs métier indépendantes de toute techno, de l'autre on décrit des procédés techniques (règles de codage, d'ergonomie, etc.) indépendant de tout besoin spécifique. Le croisement des deux produit instantanément un logiciel. C'est le principe du cycle en Y comme avec l'approche 2TUP mais entièrement automatisé.
As tu des référence (livres, articles,web) Ã me proposer sur :
?
Je suis toujours en avance de phase de quelques années. Quand j'aborde un sujet il n'existe aucun bouquin. Ensuite, ils ne me servent plus à rien. La conséquence, c'est que n'en ayant pas besoin, je n'en ai jamais lu aucun! Je ne connais donc pas les livres qui existent et suis donc dans l'incapacité de t'en recommander un plus que d'autres parmi ceux qui existent.
Ce que je peux faire par contre c'est te passer une démo par mail.