Skip to content

Monthly Archives for January 2009

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 by Francois 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 by Francois 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 by Francois 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 by Francois 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.

This subsystem is a part of .NET Framework 3.0

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 by Francois under .Net, Architecture Applicative, Débutant with No Comments

Architecture multicouche

On peut diviser les architecture applicatives en trois parties principales :

  • Les couches logiques— C’est la première étape de la définition d’une architecture informatique
  • La vue modèle — La vue modèle représente tous les modèles utilisé dans l’architecture de l’application
  • Les couches physiques — Cette dernière étape de la définition est étroitement liée à la phase de déploiement (UML)

Les couches Logiques

Les couches logiques sont généralement définies par leur domaine d’action . La définition de telle couches permet de garantir une meilleure réutilsabilité des composant et de faciliter leur maintenance. Il est primordial, lors de la définition des couches de l’application de porter une attention particulière sur les communication inter-couche. Un représentation généralement admise des SI repose sur les couches logiques suivantes :

  1. Couche de Présentation : Cette couche représente l’interface graphique utilisateur. Elle est basée sur des technologies client est est fréquemment générée coté serveur par un environnement J2EE. C’est dans cette couche qu’interviennent les validation des saisies ainsi que le formatage des affichages.
  2. Couche d’application : Cette couche, reliée à la couche de présentation prend en charge la gestion des événement induits par la couche de présentation (navigation entre écrans, clics, gestion des éléments graphiques…). Ces deux couches sont étroitement liées et sont souvent regroupées, ou peuvent interagir en se reposant sur des frameworks (1) dédiés.
  3. La couche de Service métier : C’est dans cette couche que résident les services à proprement parlé, qui sont fournis aux différentes applications. Ils implémentent les différents besoins du domaine d’activité de l’entreprise, ainsi que des services plus transverses tels que l’authentification, la gestion des autorisation, la gestion des transactions… Ces services sont utilisés dans les couches supérieures pour répondre aux besoins des utilisateurs. Ils sont implémentés sous forme de classes simples qui sont indépendantes du type des données sources. Dans ce sens il correspondent à une vison objet du domaine métier. Ils sont identifié lors de la phase de conception et sont référencé dans les spécifications techiques détaillées du projet.
  4. La couche d’accès aux données : Dans cette couche on encapsule des acces à des systèmes externes et aux ressources. Cette couche contient étaglement les mécénismes de persistence (implémenté par des moteurs de mapping relationnel/objet).
  5. La couche de données : Cette couche contient les systemes de gestion des données (SGBD) uniquement, c’est à dire qu’il ne doit pas y voir de code dans cette couche.

La vue modèle

elle recense les modèles suivants :

  1. Le Modèle de Présentation : il est composé d’objets non persistents fortement dépendant de l’interface graphique de l’application. Ces objets peuvent en référencer d’autre, faisant partie du modèle public de la couche service métier.
  2. Le modèle Public : est une représentation du modèle fonctionnel. Il est indépendant du modèle technique (private model). Ce modèle est régi par les règles suivantes :
    • Les objets métiers sont utilisés pour communiquer les informations à la couche de présentation ou a des applications externes.. Les objets métiers du modèle public sont indépendant des objets du modèle privé
    • Les objets métiers ne possède aucune méthid, si ce n’est des méthode totalement dédiées à l’acces au données (getters). Il ne doit y avoir aucune méthode de traitement ou validation
    • Les attributs des objets métiers stockent uniquement des informations publiques, on ne doit y trouver aucune information privée ou technique.
    • Un objet métier peut référencer d’autres objets métiers
    • L’héritage n’est pas autoriser entre objets métiers
    • Les objets métiers ne doivent utiliser que des type de données collections simples tels que les tableaux.
    • Aucun cycle n’est permis dans le graphe d’association des objets métiers.
    • Leur usage étant transverse à plusieurs couches, ces objets doivent etre sérialisable
    • Les objets métiers sont volatiles (non persistent).
  3. Le modèle privé est constitué d’objets persistent plus ou moins dépendant du modèle physique (ex schéma de base de données). C’est la vue orienté objet du schéma de base de données. Ce modèle est régi par les règles suivantes :
    • Il faut utiliser un system de mapping relationnel/objet.
    • Le modèle privé doit etre indépendant du systeme de mapping relationnel/objet.
    • Il faut incoporer des mécanismes de liaison de données non objets (jointures de tables…).
    • Il faut optimiser ce modèle afin de rendre les requêtes plus performantes.
  4. Le modèle physique est relatif à la couche physique dans laquelle les données sont stockées. Généralement il s’agit du schéma de la base de données.

La couche physique

La couche physique est la troisième étape de la définition de l’architecture. Elle correspond à la phase de déploiement UML.

On s’accorde fréquemment à découper la couche physique en trois zone de sécurité différentes :

  1. DMZ Présentation : Elle inclut la couche de présentation et la couche d’application
  2. DMZ Application : Elle inclut la couche service métier et la couche d’accès aux données
  3. DMZ Données : Elle inclut la couche de données

Ces zones de sécurité, on le constate sont distinctes de la notion de couche applicative, telles qu’elles sont définies ci-dessus.
(1) cf. sur articles concernant les frameworks.

Ces articles peuvent vous interesser

  • Aucun
Written on 19 January 2009 by Francois under Architecture Applicative with No Comments

Introduction à l’architecture informatique

L’architecture informatique décrit la structuration d’un système informatique en terme de composants et d’organisation de ses fonctions. Il existe plusieurs vision d’un systeme d’information :

  1. La vision logique/physique
  2. La vision par groupe de composants informatiques (logicielle, matérielle, middleware, réseau…)
  3. La vision par technologie informatique (multicouche, web, EAI, CRM, ERP…)
  4. La vision par contraintes (Architecture haute disponibilité : faible taux de pannes,
  5. Architecture massivement parallèle : forte capacité de calcul, Architecture sécurisée : contrainte de sécurité)

Face à cette pluralité de point de vue des cadres d’architecture sont communément employés dans la gouvernance ((Le critère essentiel d’une bonne gouvernance est que les mécanismes de fonctionnement de l’institution soient organisés de façon à éviter que les intérêts des mandatés prennent le pas sur ceux de leurs mandants .)) des technologies de l’information et des systèmes d’information. Une organisation peut souhaiter que certains modèles soient obligatoires pour la validation d’une conception de systèmes. De même, elle peut souhaiter spécifier que certaines vues soient employées dans la documentation des systèmes achetés.

Ces articles peuvent vous interesser

  • Aucun
Written on 16 January 2009 by Francois under Architecture Applicative, Architecture système, Autres, Débutant 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

SRDF (Symetrix Remote Data Facility)

Introduction

C’est un produits EMC² permettant de répliquer les données entre plusieurs sites, et ne fonctionne donc a priori que sur des baies EMC². C’est mécanisme hardware, qui ne se préoccupe pas de la nature des informations qui sont stockées sur les disques.

Il est possible de faire du SRDF synchrone sur des cluster geospan (surcouche applicative windows) entre des sites distants de 10-15 km. Pour des sites plus distants on utilise le SRDF asynchrone, ce qui permet de faire de la sauvegarde a J-1. On pourrait faire des fréquences plsu rapprochées mais généralement cete solution n’est utilisée que pour des sauvegardes de la veille.

Les BCV

Phase 1 : Un serveur voit un disque (le STD, standard). Pour lancer le procesus de réplication, à ce jour on gèle les IO, soit par surcouche applicative, soit généralement on fait un arrêt applicatif. Une fois cela fait, on génère un ordre de ‘establish BCV’. Cet establish compare le STD et le BCV (jeu de disque dédié pour etre miroir du STD) pour connaître les différences (en terme de piste physique). Il recopie ces différences du STD vers le BCV.

Le BCV (sur le site primaire) peut être appelé R1 (premier réplicat).

Il faut noter que le gel des IO n’est pas obligatoire, cependant il permet à la synchronisation du BCV de se faire beaucoup plus rapidement.

Phase 2 : le split : On doit figer l’image BCV lorsqu’elle est complètement conforme a la source. A ce moment du process, le gel IO est obligatoire (souvent obtenu par un arrêt applicatif).

Phase 3 : Entrée en jeu de SRDF : Une fois que le BCV est cohérent avec le STD, on utilise le même mécanisme distant. Le R1 est recopié sur le R2 (image disque sur le site distant), par un establish (réplication des pistes modifiée) puis un split quand les deux volumes sont équivalents.

Il est toujours possible de rajouter un BCV au R2, afin d’être plus secure dans le cas de PRA. En effet lorsque ,sur le site 1, la baie pète lors de l’establish R1-R2, il est toujours possible d’avoir un R2 incohérent.

Le process le plus sur pour etre couvert dans tous les cas est donc le suivant :

1 - establish R2-BCV du R2
2 - gel des IO prod
3 - establish prod
4 - split BCV R1
5 - relance des IO prod
6 - lancement establish SRDF R1-R2
7 - split image SRDF R1-R2

Ce cycle permet de s’assurer dans tous les cas qu’on aura soit R2 ok soit BCV R2 ok : on a toujours une image qui permettra de répartir.

Généralement du fait des problématiques de budget le BCV de R2 est rarement fait.

Si on fait du fil de l’eau sur le SRDF R1 R2, on augmente le risque d’avoir un R2 incohérent.

En cas de problème sur le site principal

On peut utiliser l’image BCV pour autant qu’on ne se trouve pasdans la phase 3. On peut alors réattacher les BCV sur le serveur primaire, afin de pouvoir les accéder en lecture. On peut également utiliser un autre serveur pour y atacher les BCV (ce qui permet soit de relancer l’appli soit de faire les sauvegardes), ou (au pire) ecraser les STD avec le R1.

Il faut prévoir des le départ le R1 le STD et le R2 , car ce paramétrage prend beaucoup de temps et implique nécessairement une intervention de la part d’EMC².

Il existe d’autre mécanismes qui font que ce sont les baies qui gèrent ces réplication et plus les serveurs comme c’est le cas aujoud’hui

Ces articles peuvent vous interesser

  • Aucun
Written on 08 January 2009 by Francois under Architecture système with No Comments