Skip to content

Category Archives for Moyen

Penser aux données différemment

Voila une vidéo qui fait un tour d’horizon des solutions de gestion de données récentes. L’argument est clair : les SGBDR traditionnels tels qu’Oracle, Sybase, MS-SQL Server pour les licenses commerciales ou MySQL ou PosgreSQL ne sont pas forcément adaptés à l’usage que l’on souhaite en faire dans les business modernes. Dans cette conférence données à l’occasion de la  PyCon 2009 (en Mars 2009) Bob Ippolito fait le tour des principaux avantages et inconvénients de chacunes des solutions suivantes :

  • BigTable (Google)
  • Dynamo (Amazon)
  • Cassandra (Facebook)
  • Voldemort (tres rapidement)
  • memcached
  • Tokyo Cabinet
  • Redis
  • CouchDB
  • MongoDB
  • Vertica
  • Hadoop (Evoqué en 3 secondes dans les questions et réponses)

Ces articles peuvent vous interesser

Written on 12 April 2009 by admin under Architecture système, Moyen, 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.

Schéma Architecture J2EE 1.4

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 by Francois under Architecture Applicative, J2EE, Moyen with No Comments

Introduction à SOA

On peut définir les architecture orientées service (SOA) comme des architecture logicielles permettant de créer des applications implémentant des processus métier ou des services à l’aide de boites noires faiblement reliées entres elles.

Les Service Oriented Architecture (SOA) sont une évolution des architecture distribuées et de la programmation modulaire. Elles fondent les applications en se basant sur des services logiciels de base qui implémentent généralement des fonctionnalités (appelé service) tels que remplir un formulaire, commander en ligne un livre ou un ticket d’avion…

Ces articles peuvent vous interesser

  • Aucun
Written on 14 January 2009 by Francois under .Net, Architecture Applicative, Introduction, Moyen with No Comments

J2EE 1.4 : Les services standards

Voici une description rapide des services standard J2EE.

HTTP
L’API cliente HTTP est fournie par le package java.net.
L’API server HTTP est fournie par les interfaces JSP et les servlets.

HTTPS
L’utilisation du protocole HTTP sur le protocole SSL est supportée par les mêmes API que HTTP.

Java™ Transaction API (JTA)
L’API Java Transaction API se compose de deux parties :

Une interface de démarcation de niveau applicatif qui est utilisée par les conteneurs et les compensants applicatifs pour délimiter des frontières des transactions.

Une interface entre le gestionnaire de transaction et le gestionnaire de ressources utilisé au niveau de J2EE SPI level (dans une prochaine version)

RMI-IIOP
Le sous système RMI-IIOP est composé d’API qui permettent d’utiliser le style de programmation RMI qui est indépendant du protocole sous jacent, ainsi que d’une implémentation de ces API qui supporte le protocole RMI J2SE (JRMP) et le protocole CORBA IIOP. Les applications J2SE peuvent utiliser RMI-IIOP avec le support du protocole IIOP pour accéder a de services CORBA compatibles avec les normes RMI.

De tels services CORBA sont généralement définis par des composants qui résident en dehors d’un produit J2EE (généralement historique) Seuls les clients applicatifs J2EE doivent définir leur propre services CORBA à l’aide des API RMI-IIOP. Généralement ces objets CORBA sont utilisés pour les appels à d’autres objets CORBA

Les applications J2EE doivent utiliser les API RMI-IIOP (spécialement la méthode javax.rmi.PortableRemoteObject) pour accéder à des composants Enterprise JavaBeans (EJB). Cela permet aux EJB d’etre indépendants du protocole. Par ailleurs les produits J2EE doivent être capables d’exporter les Enterprise Beans en utilisant le protocole IIOP, et d’accéder aux Enterprise Beans en utilisant ce même protocole, comme spécifié dans les normes J2EE.

La possibilité d’utiliser le protocole IIOP est obligatoire pour permettre l’interopérabilité entre les produits J2EE, cependant ces dernières peuvent également utiliser d’autres protocoles.
Java IDL
Java IDL permet aux composants applicatifs J2EE d’invoquer des objets externes CORBA en utilisant le protocole IIOP. Ces objets CORBA peuvent etre écrits en utilisant n’importe que langage et ne pas faire partie de produits J2EE.

JDBC™
L’API JDBC peremt de gérer la connecticvité avec les bases de données. Cette API est composée de deux parties : une interface de niveau applicatif permettant aux composants applicatifs d’accéder aux bases de données et une interface ’service provide’ permettant d’attacher un driver JDBC à une plateforme J2EE.

Java™ Message Service (JMS)
Le service Java Message est une API standard de messaging qui supporte le point a point ainsi que le modele de publication. Cette spécification demande que ces deux type de messages soient implémentés.
Java Naming and Directory Interface™ (JNDI)
The JNDI API is the standard API for naming and directory access. The JNDI API
has two parts: an application-level interface used by the application components to
access naming and directory services and a service provider interface to attach a
provider of a naming and directory service.
J2EE.2.6.9 JavaMail™
Many Internet applications require the ability to send email notifications, so the
J2EE platform includes the JavaMail API along with a JavaMail service provider
that allows an application component to send Internet mail. The JavaMail API has
two parts: an application-level interface used by the application components to send
mail, and a service provider interface used at the J2EE SPI level.
J2EE.2.6.10 JavaBeans™ Activation Framework (JAF)
The JAF API provides a framework for handling data in different MIME types,
originating in different formats and locations. The JavaMail API makes use of the
JAF API, so it must be included as well.
J2EE.2.6.11 Java™ API for XML Parsing (JAXP)
JAXP provides support for the industry standard SAX and DOM APIs for parsing
XML documents, as well as support for XSLT transform engines.
PLATFORM OVERVIEW 12
J2EE.2.6.12 J2EE™ Connector Architecture
The Connector architecture is a J2EE SPI that allows resource adapters that support
access to Enterprise Information Systems to be plugged in to any J2EE product. The
Connector architecture defines a standard set of system-level contracts between a
J2EE server and a resource adapter. The standard contracts include:
• A connection management contract that lets a J2EE server pool connections to
an underlying EIS, and lets application components connect to an EIS. This
leads to a scalable application environment that can support a large number of
clients requiring access to EIS systems.
• A transaction management contract between the transaction manager and an
EIS that supports transactional access to EIS resource managers. This contract
lets a J2EE server use a transaction manager to manage transactions across
multiple resource managers. This contract also supports transactions that are
managed internal to an EIS resource manager without the necessity of involving
an external transaction manager.
• A security contract that enables secure access to an EIS. This contract provides
support for a secure application environment, which reduces security
threats to the EIS and protects valuable information resources managed by the
EIS.
• A thread management contract that allows a resource adapter to delegate work
to other threads and allows the application server to manage a pool of threads.
The resource adapter can control the security context and transaction context
used by the worker thread.
• A contract that allows a resource adapter to deliver messages to message driven
beans independent of the specific messaging style, messaging semantics,
and messaging infrastructure used to deliver messages. This contract also
serves as the standard message provider pluggability contract that allows a
message provider to be plugged into any J2EE server via a resource adapter.
• A contract that allows a resource adapter to propagate an imported transaction
context to the J2EE server such that its interactions with the server and any
application components are part of the imported transaction. This contract
preserves the ACID (atomicity, consistency, isolation, durability) properties of
the imported transaction.
• An optional contract providing a generic command interface between an application
program and a resource adapter.
J2EE Standard Services 13
J2EE.2.6.13 Security Services
The Java™ Authentication and Authorization Service (JAAS) enables services to
authenticate and enforce access controls upon users. It implements a Java
technology version of the standard Plugable Authentication Module (PAM)
framework, and extends the access control architecture of the Java 2 Platform in a
compatible fashion to support user-based authorization. The Java™ Authorization
Service Provider Contract for Containers (JACC) defines a contract between a J2EE
application server and an authroization service provider, allowing custom
authorization service providers to be plugged into any J2EE product.
J2EE.2.6.14 Web Services
J2EE provides full support for both clients of web services as well as web service
endpoints. Several Java technologies work together to provide support for web
services. The Java API for XML-based RPC (JAX-RPC) provides support for web
service calls using the SOAP/HTTP protocol. JAX-RPC defines the mapping
between Java classes and XML as used in SOAP RPC calls. The SOAP with
Attachments API for Java (SAAJ) provides support for manipulating low level
SOAP messages. The Web Services for J2EE specification fully defines the
deployment of web service clients and web service endpoints in J2EE, as well as the
implementation of web service endpoints using enterprise beans. The Java API for
XML Registries (JAXR) provides client access to XML registry servers.
J2EE.2.6.15 Management
The Java 2 Platform, Enterprise Edition Management Specification defines APIs for
managing J2EE servers using a special management enterprise bean. The Java™
Management Extensions (JMX) API is also used to provide some management
support.
J2EE.2.6.16 Deployment
The Java 2 Platform, Enterprise Edition Deployment Specification defines a contract
between deployment tools and J2EE products. The J2EE products provide plug-in
components that run in the deployment tool and allow the deployment tool to deploy
PLATFORM OVERVIEW 14
applications into the J2EE product. The deployment tool provides services used by
these plug-in components.

Ces articles peuvent vous interesser

  • Aucun
Written on 12 January 2009 by Francois under Architecture Applicative, J2EE, Moyen, Web services with No Comments

AXIS c’est quoi ??

Tous les développeurs comprennent désormais l’importance des frameworks de développement, ces boites à outils qui permettent de décupler leur productivité. Développer avec SOAP ne déroge pas à la règle, quoique vous puissiez tout coder à la main avec un bon notepad, il est vraissemblable que ces frameworks vous permettront plus de vitesse, de réutilisabilité et d’évolutivité.

Il exites chez apache un tel outil. Sa première version SOAP4J, était un don de IBM. Désormais cet outil s’appelle AXIS et est bien plus qu’une simple réécriture des bibliothèques SOAP d’Apache, il s’agit en fait d’une refonte architecturale. Il a été prévu plusieurs phases dans le développement d’AXIS : 2 mouture en alpha, pour arriver au final à une version 3.0. Les première moutures d’AIX ont été publiées en août et Spetembre 2001.

Lorsqu’elle sera finalisée, cette bibliothèque permettra
1. Le support de SOAP 1.1, au même titre que Apache SOAP 2.2. Par exmple AXIS supportera complément le concept SOAP “mustUnderstand headers” [règles régissant la compréhension des message, pouvant mettre fin aux communication le cas échéants ].

2. d’être moins consommateur et plus rapide que Apache SOAP (grace à son usage de SAX) ( SAX permet un parsing rapide du XML)

3. de s’appuyer sur une couche d’abstraction simple pour les transports de donénes. (i.e., senders et listeners pour SOAP pour plusieurs protocoles tels que SMTP (Simple Mail Transfer Protocol), FTP, message-oriented middleware, …).

4. Générer automaitque les WSDL (Web Services Description Language) de services déja déployés.

5. Le support du déploiement d’EJB (Enterprise JavaBeans) comme services, comme le fait actuellement BEA WebLogic Server.

6. Une meilleure interopérabilité avec l’implémentation Microsoft de SOAP et les services .Net

Ces articles peuvent vous interesser

  • Aucun
Written on 06 January 2009 by Francois under Architecture Applicative, J2EE, Moyen, Web services with No Comments