Telosys

Un article de Wikipédia, l'encyclopédie libre.

Telosys
Dernière version 0.9.8 (le 13 mars 2008)
Environnement Multiplate-forme
Type Java, J2EE, framework,
Licence GNU Lesser General Public License (LGPL)
Site web telosys.objectweb.org

Telosys est un framework Open Source sous licence LGPL permettant de créer des applications Web 2.0. Telosys est un projet du consortium OW2 (ex ObjectWeb) depuis 2005. Ce framework est basé sur le principe "Client/Serveur".

En associant AJAX, Java et SQL, Telosys permet de renouer avec les concepts du client serveur. Son approche « orientée écrans » (par opposition à la navigation de type web avec rafraîchissement de page) cible donc particulièrement les applications métier à usage intensif.

Telosys utilise les technologies suivantes :

Sommaire

[modifier] Description

[modifier] Qu'est ce que Telosys ?

Telosys est un framework conçu pour réaliser des applications métier de type "Client/Serveur Web".

Principe :

  • Poste de travail de type "client http" (navigateur, application, ...) orienté écrans et non orienté pages web comme une application web classique
  • Serveur fournissant des actions et des services
  • Requêtes client/serveur AJAX : XML-RPC sur HTTP (seules les données utiles sont échangées)

Telosys offre différentes briques intégrées mais utilisables séparément :

  • Framework Javascript
  • Gestionnaire d'écrans screen maps
  • Couche de persistance (mapping Objets/Relationnel)
  • Gestionnaire d'actions
  • Gestionnaire de services
  • Générateur de code

[modifier] Pourquoi Telosys ?

Les directions informatiques sont actuellement confrontées à une problématique récurrente : porter des applications métier de type « client lourd » vers des architectures de type « client léger » tout en préservant l’ergonomie et en garantissant des délais et des coûts acceptables.

Que l’on soit dans le cadre d’une migration technologique ou d’un nouveau développement, l’objectif est généralement de travailler en « cycle court » afin de produire rapidement l’application attendue (« time to market » oblige). Mais les environnements utilisés pour développer dans une architecture Web sont souvent trop lourds et trop complexes pour apporter la productivité souhaitée. Les socles techniques sont généralement constitués d’un assemblage de solutions et de frameworks hétérogènes. Par ailleurs, la préservation d’une ergonomie de type « client serveur » passe nécessairement par l’utilisation d’AJAX, ce qui ne simplifie pas les choses. Ainsi, tous ceux qui ont eu l’occasion de travailler avec des outils de développement désormais « passés de mode » (L4G ou RAD) constatent que depuis quelques années la productivité régresse inexorablement !

C’est ce constat qui est à l’origine du framework Telosys.

Architecture Web classique
Architecture Web classique

Telosys a été conçu pour apporter une solution technique globale couvrant toutes les couches traditionnelles d’une application Web/Java (de la présentation jusqu’à la persistance). En effet, les retours d’expériences montrent que la déperdition, en terme de productivité et de qualité, est engendrée par un volume de code technique (sans intérêt fonctionnel) beaucoup trop important et nécessitant une multitude de compétences (HTML, CSS, appels AJAX, frameworks de navigation, de persistance, mapping d’objets entres couches, …). Cette multiplication des compétences, indispensables à la bonne marche du projet, devient vite le cauchemar du chef de projet qui doit gérer l’affectation des ressources humaines.

Telosys a donc pour objectif de simplifier l’environnement technique, afin de permettre à des développeurs non spécialistes d’être rapidement efficaces et de réduire la gestion des « dépendances inter-frameworks ». Pour ce faire, il propose des solutions simples, légères et pragmatiques qui visent l’efficacité avant tout.

Architecture Web Telosys
Architecture Web Telosys
  • Cohérence globale
  • Economie d'objets inutiles et redondants
  • Permet de "rapprocher l'IHM des données" (comme un AGL "client/serveur")

Telosys permet de répondre à la problématique des postes de travail des applications à usage intensif.

Il associe le meilleur des 2 mondes :

But : Industrialiser les développements (améliorer la qualité et la productivité) ⇒ réduction du code technique !

[modifier] Philospohie & principes généraux

  • Simplicité : 1 seul fichier "telosys.jar" à placer dans le projet....et l'utiliser
  • Ouverture : Utilisable avec n'importe quelle autre technologie (Web services, EJB, Hibernate, clients lourds, ...), intégration avec des "servlets/JSP classiques", Struts, JSF, ...
  • Couverture global et autonomie :
    • Toute les couches d'une application web standard sont couvertes
    • Aucun autre framework n'est nécessaire
  • Adaptabilité : Comportement standard - peut être adapté/spécialisé

⇒ Proposer des solutions, ne pas les imposer !

[modifier] Licence et technologies

  • Licence : GNU Lesser General Public License (LGPL)
  • Technologies standards :

    → Côté Serveur :
          JAVA(Servlets,JSP,JDBC)
    → Côté Client :
          DHTML(HTML,Javascript,CSS) ou XUL
          Navigateurs : Internet Explorer & Mozilla Firefox
    → Dialogue :
          XML/HTTP (AJAX)
    → IDE :
          Eclipse + Plugins

[modifier] Telosys vs frameworks AJAX

Comparaison Telosys avec frameworks AJAX
Comparaison Telosys avec frameworks AJAX

[modifier] Architecture

L’architecture de Telosys est « orientée écrans » et reprend les principes du « client serveur ». Le serveur a deux vocations : générer les « screen maps » (fonds d’écran utilisés dans le navigateur) et fournir les « actions » et les « services » nécessaires aux écrans (cf. schéma d’architecture).

Le dialogue entre le client et le serveur est basé sur un échange de flux XML sur http (technologie AJAX).

A l’instar des Web Services, ce principe permet au serveur de répondre à des appels de tout type de client http (pas uniquement un navigateur). Il préserve donc une ouverture à des « postes de travail hybrides » mixant des « écrans légers » (HTML, XUL, …), RIA (Flex, OpenLaszlo, ...) et des « écrans lourds » (Swing, Eclipse RCP, C++, .Net, …)

Les « objets applicatifs » gérés par Telosys sont de simples POJO (objets Java standards) sans aucune adhérence avec aucun package et ne subissant aucune transformation au niveau du « bytecode ». Ils sont donc totalement indépendants et transportables à travers les couches et les frameworks.

Le découpage des packages permet d’utiliser l’ensemble des possibilités offertes par le framework, ou uniquement les briques souhaitées. Par exemple, la couche « Telosys-DAL » (Data Access Layer) peut être remplacée par des services dédiés, Hibernate, ou tout autre système de persistance.


Architecture générale de Telosys :

Architecture générale
Architecture générale

Architecture des couches côté serveur :

Couches côté serveur
Couches côté serveur

[modifier] Clients Telosys

  • Telosys fournit un "Screen Map Server" pour construire des IHM Web ( HTML / XUL )
  • Tout type de client "HTTP" peut dialoguer avec le "Request Processor" (XML-RPC) :
    • Applications "client lourd", quel que soit le langage (Java, C++, C#, ...) ou le langage de 4ème génération : 4GL (Delphi, ...)
    • Applications RIA (JavaFX, Flex, OpenLaszlo, ...)
    • Serveurs (J2EE, .Net, PHP, ...)
    • etc...

[modifier] Productivité et démarche de développement

Contrairement aux frameworks AJAX classiques qui ne couvrent qu’une partie de l’architecture, Telosys a pour vocation d’offrir une homogénéité globale permettant une association entre un champ d’un écran et un attribut d’un « Value Object » (POJO), puis entre cet attribut et une colonne d’une table.

Cette interconnexion naturelle entre les différentes couches permet de réduire les tâches d’intégration et de construire l’application par enrichissement progressif.

Le développement peut ainsi être envisagé sous différents axes :

  • à partir des écrans (démarche de type « développement agile », avec des itérations sur l’IHM, puis récupération des maquettes et implémentation des actions et services)
  • à partir de la base de données, en utilisant le générateur de DAO (démarche de type « Model Driven Development » basée sur le modèle physique d’une base de données existante)
  • à partir d’un modèle UML (démarche de type « MDA » utilisant un outil de génération de code, par exemple « Acceleo » un autre projet ObjectWeb)

Par ailleurs, l’utilisation d’un typage fort, les conventions et les outils permettent de renforcer la qualité du code et la productivité des développeurs. Quant à l’utilisation d’échanges de flux XML sur http, elle favorise l’automatisation des tests de non régression et de montée en charge.

Démarche de développement
Démarche de développement

[modifier] Environnement et outils

Les technologies requises pour utiliser Telosys sont :

Telosys ne nécessite que des technologies légères, mais en cas de besoin, il permet bien sur d’adresser toutes les autres technologies traditionnellement associées à la plate-forme Java (EJB, Web Services, RMI, JMS, JCA, …).

Au-delà du framework proprement dit, la roadmap Telosys prévoit un ensemble d’outils visant à faciliter son utilisation. Le premier outil fourni concerne la génération des classes nécessaires pour la couche d’accès aux données. Il existe également un générateur de « Wrappers XML » (classes qui assurent la transformation de tags XML en objets Java et réciproquement). Un constructeur d’écrans WYSIWYG est en préparation.

[modifier] «Screen Context» & actions

[modifier] Screen Context

Chaque écran est associé à un contexte ( « screen context » ) contenant l’ensemble des instances des objets ou listes d’objets gérées par cet écran. La définition d’un « screen context » est réalisée en quelques lignes de code Java. Exemple :

  defineElement("emp", EmployeVO.class ); 
  defineElement("soc", SocieteVO.class );

Ces lignes sont suffisantes pour déclarer que ce contexte maintient une instance de la classe EmployeVO dont le nom symbolique est « emp » et une instance de SocieteVO nommée « soc ».

Chaque utilisateur (session HTTP) travaille sur 1 à N écrans simultanément donc sur 1 à N «Screen Context»

Screen Context
Screen Context

[modifier] Actions

Les écrans exécutent des actions sur le contexte qui leur est associé. Il existe un certains nombre d’actions prédéfinies :

  • actions sans persistance (get, set, clear, open, close, ping, echo)
  • actions avec persistance (load, save, delete, insert, update, …)
  • actions de gestion de liste (add, remove, clear, get, set, select, sort, …)
  • et une action particulière « exec » permettant d’implémenter les cas spécifiques sous forme de « procédures ».

L’appel des actions est réalisé de façon transparente par le framework Javascript qui assure l’envoi des requêtes AJAX et le traitement des réponses. Côté serveur, seules les actions de persistance et les procédures nécessitent un codage spécifique. L’implémentation de « triggers » permet d’exécuter des traitements avant et/ou après une action (par exemple « beforeSave » et « afterSave » pour encadrer une action « Save »). Les triggers ont la capacité d’annuler l’action en cours et de renvoyer des messages à l’utilisateur, ils sont donc particulièrement adaptés pour injecter des règles, des contrôles, des traces, …

Actions Telosys
Actions Telosys

[modifier] Les écrans

La définition des écrans repose sur un ensemble de widgets fournis sous la forme d’une taglib. Un écran Telosys est défini par un « screen body » (un fichier JSP) contenant ces widgets et incrusté dans un template. Chaque widget peut être positionné en absolu (avec des coordonnées x et y) ou en relatif (dans un layout HTML). Les widgets de type zone de saisie (field, combobox, radiogroup, …) peuvent être « mappés » sur un attribut de l’un des objets Java composant le « screen context » ( attribut « data » ). Chaque widget comporte également des attributs permettant de réaliser des contrôles de surface lors de la saisie (« type », « min », « max », …)

Exemple :

  <t:field id="salaire" x="200" y="320" maxlength="12" data="emp.salaire" value="0.00" type="Num" format="0.00" />

L’attribut « data » présent dans le tag « field » indique que ce champ de saisie est associé à l’attribut « salaire » de l’instance « emp » du contexte écran (des conventions de nommage permettent de simplifier le mapping en utilisant l’attribut « id »).

[modifier] Les services

En plus des actions de gestion d’écrans, Telosys propose un système d’implémentation et d’appel de « services » dont les principes sont très proches des « web services ». Un service « voit » la session de l’utilisateur qui le sollicite et peut donc l’utiliser. Côté serveur, un service est une classe Java qui implémente la méthode « execute » d’une interface et qui peut renvoyer soit un objet « response » (transmis au client en XML), soit une « vue » générée par un « renderer » et directement affichable dans le navigateur. Côté client, le framework Javascript offre un système de « stub générique » permettant d’appeler un service par son nom symbolique. Les services peuvent être utilisés dans de nombreux cas : recherche multi-critères avec affichage d’une liste de résultat, navigation traditionnelle entre pages (type MVC), contrôle de saisie champ par champ, …

[modifier] Persistance

Pour gérer l’accès aux données, Telosys fournit un ensemble de classes permettant de gérer simplement des DAO de type CRUD étendus (gestion des listes, contrôles d’existence, …). Le mapping objet/relationnel est défini dans le plugin Eclipse et sera ensuite porté par le code généré du DAO. Une application peut adresser simultanément plusieurs bases de données différentes, chacune utilisant soit un pool de connexion géré par Telosys, soit une datasource standard. Le développeur est déchargé de la gestion des connexions et travaille par opérations génériques au niveau des tables, il peut choisir de gérer lui-même les opérations SQL à un niveau plus fin (commit, rollback, load « for update », ...). Il existe également des objets complémentaires facilitant tous les autres types d’accès aux données ( DataSet, Query, etc… ).

Telosys fournit son propre système de persistance des données mais peut être remplacé aisément par tout autre système de persistance (Hibernate, iBatis, ...)

[modifier] Architecture de la couche DAL

Architecture de la couche d'accès aux données (DAL)
Architecture de la couche d'accès aux données (DAL)

Un VO (Value Object) est un bean JAVA classique (ou POJO).
Un VOList est une liste de Value Object.
Un DAO (Data Access Object) est, comme son nom l'indique, un objet permettant d'accéder aux données.

[modifier] Exemple

Voici un exemple avec une table "Employee" existante en base :

Exemple couche d'accès aux données (DAL)
Exemple couche d'accès aux données (DAL)


[modifier] Liens externes