Skip to content

Author Archives for Francois

Cassandra : le modèle de données

Préambule

Cet article reprend (et traduit) en grande partie la page concernant le data model sur lequel est basé Cassandra. J’y ai ajouté d’autres informations (toujours relative au data model) glanées deci-delà et ai tenté de les agréger de la façon la plus cohérente possible pour arriver à cerner ce système. Bien entendu, ce post expose également une réflexion personnelle, et ma perception de Cassandra. N’hésitez donc pas à commenter ou corriger.

Le modèle de donnée de Cassandra est plus ou moins dérivé de celui de BigTable de Google. Les développement de Cassandra ont commencés au sein de Facebook, puis ont été transmis à la communauté Open Source. Cette base de donnée non relationnelle est orientée vers le stockage de données de sites Web de grande ampleur (tels que les réseaux sociaux)

Introduction

Cassandra peut être pensé comme une structure a 4 ou 5 dimensions dont les noms sont les tables, les familles de colonnes, les clés, les super colonnes et les colonnes. Au croisement de ces dimensions on trouve le couple (valeur, timestamp).

Les SGBD classiques sont orientés lignes. Cela signifie que toutes les colonnes d’une ligne sont stockées à la suite les unes des autres, de manière regroupée. Une base de données orientée colonne, quant à elle, stocke les données en privilégiant le regroupement des données des colonnes entières. Une base de donnée orienté ligne stocke les données d’une manière favorisant principalement les lignes (c’est à dire que toutes les colonnes d’une même ligne sont stockées ensemble). Les stockage d’une base de données orientée colonne quant a lui favorisera les colonnes.



Les familles de colonnes permettent une approche hybride. Elles permettent de diviser les lignes (correspondant aux clés) en nombre statique de groupe (les familles de colonnes). Dans Cassandra, chaque famille de colonne dans une table est stockée dans un fichier séparé, et le fichier est trié par ligne (par clé). Cette clé est une chaîne de caractères de longueur quelconque identifiant uniquement chaque ligne.

Les colonnes ayant un lien entre elle et devant être accédées dans les mêmes occasions, doivent idéalement être incluses dans une même famille afin d’en optimiser l’accès.



Les structures de données

La table :

Il faut penser les tables comme des espaces de travail, des domaines. Il s’agit du plus haut niveau d’organisation de Cassandra. Généralement on leur donne le nom d’application. Quoique j’ai pu lire à droite et à gauche, il est possible de créer plusieurs table dans le cluster. Ces tables doivent être déclarées dans le fichier de configuration storage-conf.xml avant le démarrage du cluster.

La famille de colonne :

L’unité suivante d’organisation des données au sein de Cassandra est la Famille de colonne (Column Family). Une table est composée d’une ou plusieurs Familles de colonnes. Le nombre, le nom, le type (simple ou super) ainsi que les autres paramètres des Familles de colonnes sont fixés à l’avance, lors du démarrage du cluster. Il n’y pas de limitation quant au nombre de Familles de colonnes mais ce nombre doit rester relativement restreint.


Dans Cassandra les données dans une  table sont stockées dans un fichier séparé pour chaque colonne family. Au sein de cette famille, les données sont stockées en ligne (correspondant aux clés). Les colonnes ayant des liens entre elles, c’est-à-dire celle auxquelles on accède en même temps, doivent être regroupée au sein de column families. Par ailleurs il peut être intéressant de positionner les données fréquemment au sein d’une famille de colonne et les données les moins fréquemment accédée au sein d’une autre. Par exemple on peut nommer les colonne families : Posts, User ou UserAudit. On est assez proche dans ce cas de la notion de table, au sens SGBDR classique.

La clé

Il s’agit de l’identifiant unique de la ligne de donnée, de l’enregistrement. C’est son nom. On peut requêter sur des ranges de  clés.

Cassandra supporte une option de partitionnement avec un ajout de code minime. En standard, Cassandra fournit le hash-based RandomPartitioner et le  OrderPreservingPartitioner. Le premier permet une répartition de charge relativement efficace sans autre développement. Le second quant a lui permet d’exécuter des requêtes par range (range queries) sur les clés qui sont stockées. Les systèmes supportant uniquement des partitions hash-based ne permettent pas ce genre de requêtes de manière efficace.

Les colonnes :

Une famille de colonnes comportent des colonnes qui peuvent être de deux types : Simple ou Super. Dans ces deux cas, les colonnes au sein des familles peuvent être créées dynamiquement, et leur nombre n’est pas limité.

Les familles de colonnes simples : Les colonnes sont des structures qui sont identifiées par un nom, une valeur et un timestamp défini par l’utilisateur. Le nombre et le nom des colonnes peut être très important, et peut varier d’une clé (key)  à l’autre. Par exemple la clé k1 peut avoir 1024 colonnes/super-colonnes alors que la clé k2 n’en aura que 64.

Les colonnes peuvent être triées par leur nom, ou le timestamp..

Dans le cadre des colonnes simple il est possible d’utiliser des jokers (wildcards) “*” pour effectuer des recherches du type :

  • Table:CF:(key name, *)

Cela ramènera l’ensemble des tuples  (nom de colonne, valeur, timestamp) correspondant

Les familles de colonnes de type super sont des structures qui ont un nom et un nombre infini de colonnes associées. Le nombre de super columns associées à une Famille de Colonne peut être très important. Elles ont les mêmes caractéristiques que les colonnes. L’ordre de tri peut encore être explicitement donné dans un fichier de configuration, pour chacune des familles de colonnes. Les super colonnes peuvent être vues comme des Familles de colonnes au sein d’une famille de colonnes.

 

Famille Colonne CF1

Famille Colonne CF2

Famille Colonne CF3

CF1:C1 (simple)

CF1:C2 (super)

CF1:C3 (simple)

CF2:C1 (simple)

CF3:C1 (simple)

rowid

 

CF1:C2:C1

CF1:C2:C2

CF1:C2:C3

 

 

 

XXXXXXXXXXX1

[value, timestamp]

[value, timestamp]

[value, timestamp]

[value, timestamp]

[value, timestamp]

 

[value, timestamp]

XXXXXXXXXXX2

[value, timestamp]

[value, timestamp]

[value, timestamp]

[value, timestamp]

[value, timestamp]

[value, timestamp]

 

Notation : CFx : Famille de colonne, Cx : colonne, [,] liste, ( x,y ) tuple .

De meme concernant les super colonnes, on peut faire des recherches générique des types suivant :

  • Table:CF:(key name, super column name, *)
  • Table:CF:(key name, *, *)

“:” est un mot réservé et ne peut donc pas composer le nom d’une famille de colonne ou celui s’une supercolonne ou d’une colonne. (La version 0.4 devrait lever cette restriction)


Les points forts

Plusieurs raisons peuvent amener a préférer Cassandra pour alimenter une application web.

Flexibilité du schéma : Cassandra, comme un Document Store, permet de ne pas figer les strucutres qui seront utilisées. On peut en ajouter ou en retirer au fur et à mesure. Par ailleurs les champs peuvent varier d’un enregistrement à l’autre. Attention il faut néanmoins, au moment du démarrage du cluster fixer les nom des tables et des Familles de colonnes qui seront utilisées.  C’est au niveau des colonnes que cette souplesse arrive.

Scalabilité réelle : Cassandra permet de scaler réellement facilement. On peut ajouter une machine à la volée sans avoir a redémarrer aucun process, ni changer les requêtes ou avoir a redispatcher les données.

Connaissance de l’infrastructure : Il est possible de configurer le cluster pour que les données soient réparties dans des racks différents ou des datacenters différents, ce qui permet de gérer de manière fine les problématiques de répartition de charge sur différents sites ou de PRA

Range queries: Certes par rapport aux bases de données relationnelles classiques, ce n’est absolument pas un avantage, tant cette fonctionnalité est standard. Cependant face aux distributed key value store il es réellement intéressant d’utiliser Cassandra, dont le modèle d’implémentation permet de faire des range queries.

Distributed writes: Les écritures n’échouent jamais, il n’y a jamais de single point of failure.

Limitations

La principale limitation concernant les tailles des colonnes et des super-colonnes est que toutes les données pour une valeur de clé, doivent tenir sur le disque d’une seule machine. Parce que la valeur des clés seules détermine les noeuds responsable de la réplication des données, la quantité de données associées à une clé a cette limitation. Cette limitation est inhérente au modèle de distribution.

A ce jour Cassandra a également une autre limitation : au pire des cas, les données pour une valeur de la pair (clé, famille de colonne) seront entièrement dé sérialisées en mémoire  lors d’une requête de lecture  (mais jamais pour une  écriture). Cet inconvénient sera levé dans une version future.

Example:

Dans ce paragraphe nous ne verrons que l’exemple proposé sur le wiki de Cassandra. Néanmoins, je reviendrai sur un exemple plus détaillé dans un autre post.

On peut penser au nom de chaque super colonne comme un mot clé, et les colonnes associées comme contentant des docids, avec des informations de classement (rankinfo) et d’autre attributs. Si les clés représentent les userids, on obtient un index par utilisateur.
C’est ainsi qu’est fait l’index par utilisateur dans la recherche au sein de la BAL (inbox) sur facebook. De plus, puisqu’on a la possibilité de stocker les données sur le disque par timestamp, il est très simple pour ce type de système de répondre à des requêtes du type “donne moi les 10 messages les plus récents”.

Conclusion


Références :

http://wiki.apache.org/cassandra/DataModel
http://code.google.com/p/the-cassandra-project/wiki/DataModel
http://wiki.apache.org/cassandra/ClientExamples
http://blog.evanweaver.com/articles/2009/07/06/up-and-running-with-cassandra/
Pour obtenir des explications sous forme graphique, merci de vous reporter aux slides PowerPoint de présentation présentés lors du SIGMOD 2008.


Ces articles peuvent vous interesser

Written on 13 July 2009 under Base de données distribuée, cassandra with 1 Comment
Tagged with , , , , , , , , , , , , , ,

Extension pour Firefox 3.* et 4 : All in one mouse gestures

Tout comme ce que j’avais fait pour les onglets (tabgroups) voici une version modifiée de All-in-one Gestures 0.19.1.

C’est encore une fois fourni sans garantie, mais étant donné que cela me rend bien service, ca peut dépanner quelqu’un d’autre.
Pour le téléchargement c’est ici.

Ces articles peuvent vous interesser

Written on 23 June 2009 under Autres, Débutant with No Comments
Tagged with , , , ,

Le cloud computing…oui, mais pour quoi faire ?

Les articles concernant le cloud computing que je lis, sont de plus en plus orienté vers la technique. Il s’agit souvent de querelles de clocher pour savoir si telle ou telle solution commerciale ou technique est avantageuse par rapport à ses concurrentes. Mais du point de vue de l’utilisateur, a quoi peut donc servir le cloud computing ? Et lorsque je parle d’utilisateurs, je pense à l’utilisateur final, celui qui consomme réellement des services. Monsieur Lambda, non informaticien qui fait ses courses, retire de l’argent, appelle ses amis pour organiser une soirée… Voici donc mes premières réflexions dans ce sens.

Si on en revient aux définitions les plus communément admises, le cloud computing permettrait d’arriver à ces notions :

  1. Illusion  de ressources infinies, d’ou, pour l’utilisateur du cloud, l’élimination du provisionning
  2. Élimination des droits d’entrées, autorisant des démarrages réduits puis un accroissement des ressources selon les besoins
  3. Paiement à l’usage a court terme et élasticité

Bien, mais ces notions sont encore très proche de l’ITT…essayons donc de nous éloigner un peu : Quels services ces 3 avantages du cloud pourraient elles nous amener:

  • Des guichets matériels et logiciels permettant de disposer immédiatement (ou réellement très rapidement) de puissance de calcul et de logiciel dans des domaines relativement variés
  • Remplacer tous les outils de bureautique actuellement disponibles : que ce soit le partage de fichier, le stockage de document, la gestion des agendas… bref nous amener a un poste de travail 100% virtualisé. Ce poste de travail étant bien entendu toujours a jours en terme de version, patch de sécurité…
  • Permettre une meilleures collecte/interprétation  des diverses données que nous manipulons, et en faciliter l’accès. Tout savoir de partout !
  • Permettre une disponibilité des services 24×7
  • Faciliter l’apparition de nouveaux services, en rendant les cycles de développement, recette plus rapides
  • Accroître l’agilité des départements informatiques et améliorer le taux d’utilisation des machines
  • Permettre une réduction des latences, de la consommation de bande passante.

Mais là encore, avons nous pris assez de hauteur. C’est loin d’être sûr ! En effet si ces concepts parlent sûrement à des maîtrise d’œuvre informatique je ne suis pas sur qu’elle éveille beaucoup d’intérêt chez M. Lambda. Nous en sommes toujours aux avantages que le cloud peut avoir aux yeux des fournisseurs de services…. reculons encore.

Pour tenter de voir comment le cloud pourrait me rendre la vie plus simple, j’ai tenté de trouver les principales choses que je souhaiterais, en tant qu’utilisateur

Services en lien avec la vraie vie
1.  Faire mes courses, de chez moi (sans interruption due a des maintenances) voire lorsque je me déplace ne pas faire la queue à la caisse des supermarchés.
2.  Pouvoir suivre mes compte en banque et placements potentiels, consommation  (électrique, téléphonique, eau) de n’importe ou et n’importe quand.
3.  Disposer des informations qui me sont utiles au bon moment, au bon endroit (resto proches, mes RV, …).
4.  Pouvoir envoyer lettres numériques et suivre leur expédition (ainsi que celles de colis que je reçois)  facilement de n’importe ou.
5.  Trouver, visiter, réserver mes vacances rapidement en se basant également sur des avis d’experts et des recommandations.
6.  Pouvoir prévenir un service de baby-sitter que je vais être en retard et qu’il faut aller chercher mes enfants.
7.  Surveiller ma maison pendant son absence.
8.  Vérifier que les enfants sont bien rentrés et que leur devoir sont faits, lancer la décongélation, cuisson du repas avant de rentrer à la maison.

Homo Connectus
9. Rester joignable par mail, SMS ou téléphone tout le temps (euh….en fait, à ma guise).
10. Travailler de n’importe ou sans problématique d’accès à mon environnement

Service à valeurs légale, sécurisés
11.  Trouver l’état de mes inscriptions un organisme, un concours… Faire mes démarches administratives de manière centralisée (a temps et sans  peine) et payer mes quittances et factures
12.  Stocker mes documents de façon sure (avec éventuellement une valeur légale), possibilité de stocker mes médias (musique et vidéo) numérique de façon sure et de l’écouter par n’importe quel biais de façon récurrente.

Interopérabilité et Réversibilité
13.  Pouvoir interagir entre mes différents comptes (facebook, mail, supermarché en ligne…) à ma guise.
14.  Pouvoir transférer en quelques clic mes données d’un fournisseurs de service à l’autre ; puis les supprimer sur le premier.

Qu’en ressort il ? Que le consommateur, en l’occurrence moi, souhaite accéder de façon pervasive (omniprésente)  (9 et 10) à une large gamme de services (1 à 8 ) de façon plus intégrée (13) et en complète adéquation avec les évolutions de la société (1 à 8, 11 et 12).  Cela implique les services doivent être mis avec un bien meilleur time to market, et donc une réduction du temps dédié aux étapes de prototypage, développement etc … Bien entendu la qualité de service doit être au rendez vous sous peine de faire partir les usagers du service. La volonté d’interopérabilité (13) et de réversibilité (14) nous mène rapidement à l’ouverture et la standardisation des composants utilisés. On voit de même que certains services de personnalisation (3)  nécessitent des capacités de traitements importantes pour savoir analyser (data mining) les déplacements et comportements afin de me fournir les informations les plus adaptées.  Les problématiques de stockage et d’archivage nous amènent quant à elles assez rapidement à la sécurisation des données, ainsi qu’à leur accessibilité.

On constate, sans grande surprise, que les qualités du cloud vont dans le sens des attentes des utilisateurs. Il paraît donc sage pour un fournisseur de service de regarder dans cette direction faute de voir ses concurrents plus innovant  prendre un sérieux avantage.

Diapositive 17

nIllusion de ressources infinies, d’ou l’élimination, pour l’utilisateur du cloud, du provisionning
n
nElimination des droits d’entrées, autorisant des démarrages réduits puis un accroissement des ressources selon les besoins
n
nPaiement à l’usage a court terme et elasticité

Ces articles peuvent vous interesser

  • Aucun
Written on 16 June 2009 under cloud computing with No Comments

Cloud Computing : Confusion et polémique

L’intérêt croissant que le terme de Cloud computing suscite sur Google semble révélateur de l’importance de ce phénomène. Que l’on pense qu’il s’agisse d’une mode, ou d’un changement profond des modèles informatique l’intérêt que le Cloud suscite depuis près de deux ans (représenté ci-dessous) indique clairement qu’il est indispensable de s’y ‘intéresser, ne serait-ce que pour en réfuter l’intérêt.

4242 84561834381 779534381 1680912 2952077 n Cloud Computing : Confusion et polémique

On y voit que les recherches sont corrélées avec la décroissance de celle concernant le grid computing et qu’elles suivent l’augmentation des requêtes concernant la virtualisation. Continue Reading »

Ces articles peuvent vous interesser

Written on 18 May 2009 under Architecture Applicative, Architecture système, Uncategorized, cloud computing with No Comments
Tagged with

J2EE 1.4 : Composants applicatifs et conteneurs

Les relations nécéssaire entre les éléments d’une plateforme J2EE sont illustrés dans le schéma ci-dessous.

j2ee architecture J2EE 1.4 : Composants applicatifs et conteneurs

Ce vue n’est qu’une représentation des relations entre les différents élements mais ne signifie pas que ces derniers doivent etre répartis sur plusieurs machines , process , espace d’adressage ou machines virtuelle.

Les conteneurs illustrés par des rectangles sont des environnements d’exécution (runtime environment) J2EE qui fournissent les services nécessaires aux composants applicatifs, représentés dans la partie haute de chaque rectangle. Ces services mis a disposition sont représenté dans la partie inférieur des conteneurs. Tous ces services seront définis ultérieurement (dans l’article les services standard J2EE).

Les flèches représentent les acces requis par chacun des autres composants de la plateforme J2EE.

Les composants applicatifs
L’environnement d’exécution J2EE défini 4 types de composants applicatifs qui doivent être supporté par tous les produits J2EE :

Les clients applicatifs : ce sont les programmes java (typiquement des interface graphique utilisateurs – GUI) qui s’exécute sur un ordinateur client. Les clients applicatifs permettent à l’utilisateur de se servir de l’application et d’avoir ainsi accès à tous les services résidant sur des couches intermédiaires.

  • Les applets sont des composant GUI qui s’exécute généralement dans un browser, mais qui peuvent également s’exécuter dans d’autres appareils (supportant le modèle de programmation des applets). Les applets fournissent des GUI puissantes pour les applications J2EE (repoussant les limites imposées par les pages en HTML classique)
  • Les servlets, les pages JSP, les filtres et les listeners d’événement web s’exécutent dans des conteneurs web et peuvent répondre à des requetes HTTP provenant de cleints web. Les servlets, JSP et filtres peuvent être utilisés pour générer le code HTML d’une interface utilisateur. Il s peuvent également etre utilisés pour générer du XML ou tout autre format de donnée qui sera consommé par les composants d’une autre application. Une sorte spécifique de servlet permet le support des web services qui utilisent le protocole SOAP/HTTP. Les servlets, les pages créées avec la technologie Java Server Page (JSP) les filtres web et les listener d’évènement web sont communément regroupé sous l’appellation ‘composants web’. Les applications webs sont constituées de ces composants, ainsi que d’autres tels que des pages HTML. Ces composants s’exécutent dans des conteneurs web. Un serveur web inclu un conteneur web ainsi que le suport d’autres protocoles, de mécanismes de sécurité tel que défini dans les spécifications J2EE.
  • Les composants Enterprise JavaBeans™ (EJB) s’exécutent dans une environementsupportant les transactions. Les EJB contiennent généralement la logique applicative des applications J2EE. Les EJB peuvent fournir des web services directement en utilisant le protocole SOAP/HTTP.

Les seveurs J2EE fournissent le support du déploiement, de l’administration et de l’exécution des applications qui se conforment au standards. Les composant applicatifs peuvent être divisés en trois catégories selon leur dépendance au serveur J2EE :

  • Les composants qui sont déployés, administré et exécuté au sein d’un serveur J2EE. Ces composant inclus les composants web ainsi que les EJB.
  • Les composants qui sont déployés et administrés sur un serveur J2EE mais qui se chargent et s’exécutent sur la machine client. Ces composants incluent les pages HTML ainsi que les applets qu’elles peuvent contenir.
  • Les composant dont le déploiement ne respecte pas complètement ces spécifications. Les applications clientes peuvent rentrer dans cette catégorie. Les futures versions des spécifications J2EE pourront définir plus précisément le déploiement et l’administration de ces applications clients.

Les conteneurs

Les conteneurs fournissent les support d’exécution pour les composants d’applications J2EE. Ces conteneurs fournissent aux composants applicatifs une vue agrégée des toutes les APIs J2EE sous jacentes . Les composants applicatifs J2EE n’interagissent jamais directement avec d’autres composants applicatifs. Ils utilisent les protocoles et méthodes des conteneurs pour interagir les uns avec les autres et avec les services des plateformes. Cette introduction d’un médiateur entre les composants et les services J2EE permet au conteneur d’injecter de manière transparente les services définis par les descripteurs de déploiement, tels que le management déclaratif de transaction, les vérification de sécurité, le pooling de ressource, et le management d’état. Un produit J2EE classique fournira un conteneur pour chacun des type d’application (conteneur d’application clientes, un conteneur d’applet un conteneur de composant web et un conteneur d’EJB).

Les spécifications J2EEimposent aux conteneurs de fournri un environnement d’exécution java compatibles aux standards Java 2 Standard Edition (J2SE). Le conteneur d’applet peut utiliser le plugin java pour fournir cet environnement ou en proposer un nativement. Ces conteneurs doivent pouvoir interpreter les formats de fichiers utilisés pour les packaging de composant d’application utilisés pour le déploiement. Les conteneurs sont implémentés par un “Product Provider”.

Les spécifications J2EE définissent un ensemble de services standards que les produits compatibles J2EE se doivent de respecter (décrits plus tard) . Les conteneurs J2EE fournissent les API que les composants applicatifs utilisent pour accéder à ces services. Ces spécification définissent également les moyens d’étendres les services J2EE à l’aide de connecteurs vers des systemes applicatifs ne respectant pas les standards J2EE tels que les mainframes ou les ERP.

Ces articles peuvent vous interesser

  • Aucun
Written on 02 February 2009 under Architecture Applicative, J2EE, Moyen with No Comments

J2EE 1.4 : Introduction à J2EE

Je me plonge en ce moment dans les spécification de J2EE. Eh oui, c’est bien plus large que ce que j’avais tendance a penser. Seulement voila, ce pavé de 250 pages d’anglais peut rebuter un peu. Comme de toute facon moi, j’ai décidé de m’y plonger, je posterai ici régulièrement de fruit de mes lectures. Commençons par le début :

Introduction à J2EE

Aujourd’hui les entreprise ont besoin de réduire leurs cours, et de diminuer les temps de réponses des services qu’elles proposent à leurs clients, employés et fournisseurs. Elles doivent intégrer de nouvelles briques logicielles au sein de leur systeme d’information (SI). Ces services doivent être

  • hautement disponibles du fait de la globalisation des échanges
  • Sécurisés pour protéger la vie privée d’utilisateurs et l’intégrité de l’entreprise.
  • Fiables et évolutifs, pour s’assurer que des transactions métiers sont traitées correctement et rapidement.

De plus en plus souvent les applications sont réparties sur plusieurs couches. Généralement ce sont les couches intermédiaires qui permettent d’intégrer les nouveaux servuces au sein des SI existants. Des technologies arrivant à maturité permettent dorénavant à simplifier l’accès des utilisateurs à des services métiers complexes en éliminant ou au moins en réduisant énormément les besoins d’administration et de formation.

Java™ 2 Platform, Enterprise Edition (J2EE™) réduit le cout et la complexité des développement de services métiers sous forme multi couches (multitier). Les applications J2EE peuvent etre rapidement déployées et facilement mises a jour au fur et à mesure de l’évolution des besoins métiers. Pour arriver à cela, J2EE définit une architecture standard composée des éléments suivants :

  • J2EE Platform – Une plateforme standard pour l’hébergement des applicationsJ2EE.
  • J2EE Compatibility Test Suite – Une série de tests de compatibilité permettant de s’assurer qu’une plateforme respecte effectivement les standard J2EE
  • J2EE Reference Implementation – Une référence sur l’implémentation du prototypage d’application J2EE et fournissant une définition opérationnelle d’une plateforme J2EE
  • J2EE BluePrints Une série de bonnes pratiques recommandée pour le développement multicouche, les services pour clients légers

Ces articles peuvent vous interesser

  • Aucun
Written on 30 January 2009 under Architecture Applicative, Débutant, Introduction, J2EE with No Comments

Rappels sur SOA (Service Oriented Architectures)

Avez-vous essayé de demander a une quinzaine de personnes autour de vous ce que sont les SOA (Service Oriented Architectures). Essayez, vous obtiendrez vraisemblablement une quinzaine de réponse différentes. Fatalement cela mène à quelques incompréhensions relatives aux architectures SOA. Ces dernières sont également soit issues des présentations commerciales, soit d’une mauvaise explication de ces concepts. Voici donc en quelques mot le moyen, j’espère, de venir à bout de quelques unes de ces idées erronées.

Tout d’abord, les SOA ne sont pas un nouveau concept. Pour preuve sur MVS on exposait déjà des modules généralisés il y a 15 ans. Plus généralement cette notion de partage fonctionnel est née dès lors qu’il y a plus d’un ordinateur dans les entreprises.Les appels se sont fait via RPC puis via IPC. Elles ont été ensuite enrichies par des technologies permettant la distribution d’objets métiers tels que COM et CORBA. Les services web ne sont qu’une déclinaison plus récente de ce concept.

Ces web services ne sont par ailleurs pas du tout indispensables à la mise en place d’architectures SOA, même s’ils ont été créés pour en faciliter l’implémentation. Toutes les technologies précitées peuvent y parvenir (COM, CORBA, J2EE…). On peut également y parvenir grâce à l’utilisation de technologies propriétaires.

Par ailleurs, les communication entre les applications d’un réseau d’entreprises n’étant pas une nouveauté, il existe déja des logiciels capables de faire communiquer les différents composants informatique d’une entreprises (les ESB) . Ces derniers, s’ils peuvent bien entendu faire partie d’une SOA ne forment pas une SOA-en-kit. Les ESB ne sont qu’une des solutions techniques qui s’offrent pour construire une SOA. Une telle architecture (nous le verrons dans d’autres article) n’est pas qu’un amas de solutions techniques. Il s’agit plus dune approche permettant la réutilisabilité et l’adéquation de l’outil informatique aux besoins métiers de l’entreprise.

De ce fait les SOA sont et doivent rester éminemment “scalable”, c’est a dire qu’elles doivent permettre aider à mener a bien les augmentations de taille de système d’information des entreprises. Une attention particulière doit donc être portée lors de la phase de découverte/définition des services métiers pour que les briques constitutives du nouveau SI (services métiers) soient adaptées (ni trop grossières, ni trop détaillées). En effet, il faut garder en tête que les architectures informatiques sont au service de la société, et que ces dernières ne doivent pas devenir un poids pour elle ; ce qui serait le cas si ces briques n’étaient pas correctement définies.

De même, tout changement d’architecture doit servir l’entreprise. Bien souvent on se penche sur les SOA pour la réutilisabilité et la flexibilités qu’elles offrent. Ces qualités intrinsèques des SOA serviront généralement votre entreprise, mais il reste important de vérifier auparavant que les coûts de restructuration que leur mise en place va demander en vaudront bien la chandelle (en gros que le ROI sera conséquent).

Ces articles peuvent vous interesser

  • Aucun
Written on 28 January 2009 under Architecture Applicative, Débutant, Introduction with No Comments

SOAP

Introduction :

SOAP est un protocole basé sur XML permettant l’échange de messages sur les réseaux informatique. On utilise s’appuie généralement le protocole de transport HTTP ou HTTPS. SOAP est une des briques de la pile des web service ((web service stack :

  • (Service) Protocol de transport : se charge du transport de l’information entre les applications. Généralement, il s’agit de l’un des protocoles suivants : HTTP, SMTP, FTP.
  • (XML) Messaging Protocol : se charge de l’encodage des message dans un format XML permettant d’etre compris par tous les intervenants. Les protocoles généralement utilisés sont XML-RPC, WS-Addressing, et SOAP.
  • (Service) Description Protocol : sert à faire la description de l’interface publique d’un service web. On utilise généralement le format WSDL
  • (Service) Discovery Protocol : centralise les services au sein d’un annuair, afin que tous les services puissent y pousser leur description, ce qui en rend la découverte et l”utilisation plus aisée. C’est généralement l’API UDDI qui est utilisée pour la découverte des services.

)) sur lesquelles les couches plus élevées peuvent s’appuyer.Il existe plusieurs modèles d’envoyer les message dans SOAP, mais le plus fr”quent est le RPC (Remote Procédure Call), dans lequel un des noeuds envoie une requete à l’autre qui lui répond immédiatement. SOAP est le successeur du protocol XML-RPC quoiqu’il emprunte sa méthode de transport et sa structuration à d’autre (probablement WDDX)

Histoire :

A l’origine, SOAP signifiait Simple Object Acces Protocol, ce qui a été changé plus tard en Service Oriented Architecture Protocol. Ce changement s’est fait lorsque ce standard est devenu une recommandation du W3C. Ce protocole a été initialement créé par Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghosein en 1998.

Transport methods

SOAP se sert d’un protocole de couche application Internet comme un protocole de transport (ce qui lui vaut bien des critiques). Tant HTTP que SMTP sont utilisés come méthodes de transport pour SOAP, sachant que c’est HTTP qui est le plus utilisé, du fait de sa plus grandefacilité d’emploi au sein des infrastructures internet. En particulier SOAP fonctionne très bien au travers des firewall, il peut également être utilisé sur HTTPS en mode d’authentification simple ou mutuelle. Cette facilité est un de ses gros avantages par rapport à GIOP/IIOP qui est généralement filtré par les firewalls. XML a été choisi en raison sa large adoption dans les grandes entreprises, ainsi que pour les développements open source qu’il suscite.

Avantages et désavantages :

Avantages

  • L’utilisationde SOAP est bien adaptée aux filtrages actuels (proxy et firewalls)
  • SOAP permet l’utilisation de différents protocoles. Généralement on utilise néanmoins HTTP.

Faiblesses

  • Du fait de l’utilisation de XML, qui est très verbeux, SOAP peut nuire aux performances, face aux autres middleware de type binaire (type CORBA) dont les communications sont plus concises. Ce problème ne se sent généralement que lorsque les messages sont suffisament importants. Il existe par ailleurs des manières d’optimiser les messages SOAP ((http://en.wikipedia.org/wiki/MTOM))
  • Plusieurs implémentation de SOAP limitent la quantité de données envoyées.
  • Quand on ne s’appuie que sur HTTP (et qu’on utilise pas WS-Addressing ou ESB) les roles des interlocuteurs sont fixes : seule une des deux parties (client) peut utiliser les services de l’autres (serveur)

Ces articles peuvent vous interesser

  • Aucun
Written on 26 January 2009 under Architecture Applicative, Débutant, Web services with No Comments

WS-Security (WSS)

WS-Security (Web Services Security) est un protocole de communication permettant d’appliquer des règles de sécurité aux web services. Ce standard, maintenant sous la responsabilité de Oasis-Open et publié en Avril 2004, est issu des travaux joints de IBM, Microsoft, VeriSign et Forum Systems.

WSS contient des spécifications permettant d’implémenter l’intégrité ((l’intégrité de message est assurée en utilisant la Signature XML et des jetons de sécurité, ce qui assure que les messages sont bien provenus de l’expéditeur adéquat et n’ont pas été modifiés en transit.)), la confidentialité (( la confidentialité a pour but de garder les parts d’un message de SOAP confidentiel. On utilise le Cryptage XML et des jetons de sécurité pour cela)) et l’authentification des messages SOAP échangés par les différents webservices. Ces mécanismes peuvent être utilisés (voire combinés) pour une grande variété de technologies d”encryption, WSS détaille l’utilisation de SAML , Kerberos et de différents formats de certificats tel que X.509.

Les spécification WSS apportent donc aux développeurs de services web de sécuriser les echoanges SOAP de bout en bout ((L’intégrité et la confidentialité des services web peut également etre assurée par l’utilisation de Transport Layer Sécurity (TLS), en envoyant par exemple les messages sur HTTPS. Cela permet de réduire significativement les overheads en supprimant le besoin d’encodage des clés et de signature des messages en ASCII avant leur envoi. Le problème majeur de TLS est dans le cas d’utilisation de serveur proxy lors du routage du serveur. Par exemple : un serveur verra la requête arriver du proxy et non du client lui même. Cela peut être évité en posant une copie du certificat client sur le proxy ou en ayant un certificat connu par le serveur permettant de générer une pari clé/ certificat en phase avec le client. Cependant comme le proxy agit sur le message, cette solution n’assure pas une sécurité de bout en bout.)).

WS-Security décrit comment encoder et attacher une signature et des entêtes encryptées aux messages SOAP. De plus cela décrit comment attacher des jetons de sécurité (Usernamen, jetons X509., SAML, REL ou Kerberos ou tout autre clés encryptée) aux messages. Avec WSS, le champ d’action de ces mécanismes peut etre étendu en déplacant des information d’authentification au niveau des requetes aux services web.

Ces articles peuvent vous interesser

  • Aucun
Written on 23 January 2009 under Architecture Applicative, Débutant, Web services with No Comments

Windows Communication Foundation

IntroductionWindows Communication Foundation (WCF) est le nom actuel du projet Indigo lancé par Microsoft. C’est un sous système permettant à des applications sur une ou plusieurs machines reliées par réseau de communiquer entre elles.Les application WCF peuvent etre développées dans tous les langages compatibles avec .Net.C’est une des quatre interfaces (WCF, WPF, WCS et WWF) qui composent le Framework .Net 3.0 distribué avec Windows Vista et Windows Server 2008 et compatible également par XP et windows 2003 server.

Le modèle WCF regroupe Web Services , .NET Remoting, Distributed Transactions, et Message Queues en un modèle de programmation orienté service pour les architectures distribuées. Cela est prévu de permettre un développement de web services plus rapide s’appuyant sur une API unique, que les communication soient au sein de la meme machine, sur un réseau local ou sur internet.

300px DotNet3.0.svg Windows Communication Foundation

WCF est exécuté dans une zone sécurisée (sandbox) et fournit le modèle de sécurité fourni par toutes les applications .Net.

WCF utilise des messages SOAP pour les communications entre processus.. Quand un processus WCF discute avec un processus non WCF, le langage XML est utilisé pour les messages SOAP. Pour les messages entre processus WCF, les messages SOAP sont encodés au format binaire.

Service WCF

Un service WCF est composé de trois parties

  • Une classe “service” : qui implémente le service qui doit etre rendu
  • un environnement hôte : pour hébérger ce service
  • un ou plusieurs points finaux : auxquels les clients se connectent.

Toutes les communications se font au travers des point finaux. Chacun définit un contrat spécifiant quelles méthodes de la classe “service” sont accesibles par son biais. Chacun définit également le binding (l’attachement) comment un client communiquera avec le service le le host. L’hébergement des service peut se faire au travers de Windows Activation Services, de IIS.

Définir un Service WCF

Une classe de service WCF implémente plusieurs services par le biais de méthides. Par ailleurs, elle implémente au moins un contrat de service (service contract) dans lequel est défini les opérations qui peuvent etre exécutée par le service. Elle peut également (optionnellement) définir des contrats de données (data contracts) précisant quels jeux de données peuvent être accédés par les service.

Ces contrats sont défini en utilisant des attributs .Net. Toutes les classes exposée en tant que service WCF doivent être marquées avec l’attribut ServiceContract ou implémenter une interface marquée par cet attribut. Toutes les méthides qui peuvent être invoquées en utilisant des messages SOAP doivent etre marquées par l’attribut OperationContract. Ces attributs génèrent automatiquement des description WSDL pour les méthodes exposées qui peuvent alors être accédées par les clients.

Un service peut utiliser plusieurs contrats de services en utilisant plusieurs interface .Net (chacune marquée par son contrat de service). Une service de classe peut implémenter toutes les interfaces.

Ces deux attributs de contrats permettent également à un interface de faire référence à un ancien contrat, ce qui permet de supporter le versionning des interfaces.

Tous les contrats de services ont (explicitement ou non) un contrat de données qui définit sur que jeu de données les services peuvent travailler.Pour les types simples (in, double…) le contrat de données est géré automatiquement par WCF. Pour les types plus complexes (tableaux, struct…) ce contrat doit être défini explicitement. Ces contrats spécifient comment les données sont sérialisées et désérialisées (et donc la personnalisation de ces opérations). Ces contrats sont définis en utilisant l’attribut DataContract d’une classe ou d’une structure. Les membres des structures de données ainsi partagées devont etre marquées par l’attribut DataMember pour leur permettre d’être transférer entre le service et son client.

Le comportement (gestion de la concurrence d’accès, création de nouvelles instances du service…) du service et des opérations peut etre controlé en utiliasnt les attributs ServiceBehavior et OperationBehavior respectivement.

Définir les point finaux (endpoints)

Les clients se connectent au services WCF au niveau des points finaux. Tous les services exposent leurs contrats via un ou plusieurs poinnts finaux. Un point final est composé d’une adresse (une URL spécifiant ou le point peut etre accédé), et des propriétés de binding (attachement) qui spécifient comment les données peuvent être transmises, le protocole ainsi que les mécanismes de sécurité. WCF propose les protocoles standards (SOAP/HTTP, SOAP/TCP, SOAP/MQ…)

Communication with the service

Un client peut invoquer un service WCF en utilisant n’importe quel mécanisme RPC permettant de l’invoquer via un appel à une méthode. Tous les appels de services sont bloquant, c’est à dire que le client est figé en attandant que le service exécute sa requete. La requete doit être faite au travers d’un obhjet proxy, connecté au point final du service souhaité. Tous les appels adressés au proxy seront re-routé au service concerné et c’est également via le proxy que les réponses seront apportées au client. WCF gère la création du proxy, il extrait du point final la définition WSDL et créé le proxy de communication en utilisant le protocole spécifié dans le binding du point final. Il se charge également de la traduction du résultat dans le format attendu par le client.

WCF supporte les appels non bloquant en passant par des messages. Les proxy ne sont pas requis dans ce cas, et les réponses seront également sous forme de message. Le blocage dans ce cas ne durera que le temps nécéssaire à l’appel. Il faut pour cela implémeter des Message Queues gérant les files d’attentes. Cette gestion permet également de faire des appels à un service momentanément inactif (pour autant que la possibilité de gérer les réponses en différé soit implémenté au niveau du client)

(libre traduction et adaptation de wikipedia US)

Ces articles peuvent vous interesser

  • Aucun
Written on 21 January 2009 under .Net, Architecture Applicative, Débutant with No Comments