serveurs dapplication 1.architecture 2.le standard j2ee 3.etude de cas: edf gdf 4..net de microsoft

27
Serveurs d’application 1. Architecture 2. Le standard J2EE 3. Etude de cas: EDF GDF 4. .NET de Microsoft

Upload: ariane-mayer

Post on 03-Apr-2015

107 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

Serveurs d’application

1. Architecture2. Le standard J2EE3. Etude de cas: EDF GDF4. .NET de Microsoft

Page 2: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

2

1. Architecture avec SA

SGBD

ApplicationERP

BrowserWeb

Appareilmobile

ClientJava

ClientVB/C++

ServeurWeb

ServeurWAP

Parefeu

…Applicationmainframe

Serveurd’application

Présentation Application Données

ServeurWeb

Page 3: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

3

Serveur d’application

• Serveur d’entreprise avec• support des composants

• standards CORBA, COM, EJB• middleware objet

• support des transactions• standards CORBA, Open Group (XA)

• environnement de développement intégré• composants, transactions

• équilibrage de charge entre serveurs• support de XML et des Web services• interface avec moniteurs transactionnels et MOM

• NB: serveur d’application serveur Web + servlet (ex. Apache+Tomcat)

Page 4: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

4

Equilibrage de charge et disponibilité

Serveur A

Cluster

primaire

Serveur B

Secondaire

Réplication de l’étatdes processus clients

Cookie A,B

En cas de panne de A,basculement automatiquesur B

Page 5: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

5

Le problème d’accès aux données

• Compromis entre performances et flexibilité difficile à obtenir• performances : s’appuyer au maximum sur le

serveur BD => procédures stockées• flexibilité : composants métiers encapsulant

l’accès aux données

Composants métiers Procédures stockées

Où mettre la logique applicative ?

Serveur d’application Serveur de données

Page 6: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

6

Accès BD en C/S 2 tiers

• Développement d’applications BD en 2 étapes1 conception de la BD

• création des tables et des contraintes d’intégrité

2 programmation des procédures stockéesTrès efficace

• procédures stockées et contraintes d’intégrité exécutées sur le serveur BD

Evolution difficile• la modification d’une définition de données

implique la recompilation des procédures stockées

Page 7: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

7

Composants avec accès BD

• Similaire au C/S+ efficace- composants non

autonomes

Gestionnaire decommandes

Commande Produit

Select C.a, P.b, …From C, PWhere …

Page 8: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

8

Composants encapsulant leurs données

• Principe d’îlot de données• ensemble de données

entièrement contenu dans un composant métier

• exige une forte localité des données/composant

+ composants autonomes

- performances

Gestionnaire decommandes

Commande Produit

Page 9: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

9

Comment améliorer les performances

• Faire des composants métiers à gros grain• encapsulation des données fortement corrélées

• par ex. 5 à 10 définitions de tables relationnelles

• Exploiter les vues relationnelles• pour les données partagées entre plusieurs

composants• Mettre en œuvre un cache de données au

niveau du serveur d’application• transformation objet/relationnel

Page 10: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

10

2. Le standard J2EE (Sun et al.)

• De nombreuses API• EJB: modèle de composants serveurs• JNDI: accès aux services d’annuaire DNS, LDAP• RMI: invocation de méthodes Java à distance• JIDL: Java IDL - interface Corba• JSP: Java Server Pages (Java ds pages HTML) • JMS: Java Messaging Service• JTS: Java Transaction Service (basé sur OTS)• JDBC: accès aux BD via SQL• JDO: Java Data Objects• JAX: Java XML• JCA: Java Connector Architecture• ...

Page 11: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

11

JAX

• Pour intégrer XML et les services web• JAX-RPC (Java API for XML RPC) pour effectuer

des appels de messages SOAP• JAXM (Java API for XML Messaging) pour

envoyer des documents XML via SOAP• JAXR (Java API for XML Registries) pour accéder

des annuaires de services de type UDDI

Page 12: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

12

Support Comm.

TCP/IP, HTTP, RMI,IIOP, SOAP, etc.

Architecture d’un serveur J2EE

EntityBean

Container EJB

SessionBean

Logique de présentation Logique métier

Java ServerPage

Container Web

HTML/XML

ServletJavaBean

Services de base

JDBC, JTS, JNDI,JMS, JDO, JAX, etc.

Page 13: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

13

Principaux serveurs J2EE

Editeur Produit Points forts Ordre de prix

BEA-Oracle WebLogic Transactionnel, outils 10K€

IBM Websphere Transactionnel, intégration avec DB2 UDB

10K€

Oracle AS Intégré dans l’offre Oracle 10K€

HP Total-e-server

Intégré avec les middlewares HP

10K€

Borland AppServer Basé sur Visibroker, outils 10K€

Sun GlassFish Logiciel libre (dernier né) Gratuit

Redhat Jboss Logiciel libre Gratuit

Apache Jeronimo Logiciel libre Gratuit

Objectweb Jonas Logiciel libre Gratuit

Page 14: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

14

WebSphere Application Server

• Support J2EE complet• Support des transactions

• Interopérabilité avec le moniteur TXSeries• Serveur HTTP basé sur Apache• Support des clusters

• partitionnement des applications et équilibrage de charge

• Intégration avec• Studio Application Developer• DB2 pour la gestion de données et le stockage de

XML• Tivoli pour la gestion de réseau• Versant enJin pour les objets persistants

Page 15: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

15

WebLogic (BEA-Oracle)

• Support J2EE complet• Serveur HTTP intégré

• Plugins pour Apache, IIS, Iplanet• Support des transactions

• interopérabilité avec le moniteur BEA Tuxedo• Support des clusters

• disponibilité et équilibrage de charge• Environnement de développement

• WebLogic Builder pour le développement Java• WebLogic Workshop pour les Web services

• Intégration avec• Nokia WAP server pour les mobiles• TopLink (WebGain) pour le mapping objet-relationnel• Versant enJin pour les objets persistants

Page 16: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

16

3. Etude de cas: EDF GDF

• Application de relation client (CRM) : Niveau1• Utilisée par 25000 agents de clientèle répartis

sur 1300 agences• Gestion commerciale, gestion des contacts, outils

marketing, utilitaires (mailings, etc.)• Architecture technique

• C/S (client lourd) avec 2 nouvelles versions par an• SI sur mainframes IBM (un centre par département)

• Plusieurs BD et une partition CICS par centre

• Besoins• Réactivité croissante aux demandes des

agents• Déploiement plus rapide des nouvelles

versions

Page 17: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

17

Solution

• Architecture n-tiers• Client léger• WebLogic: serveur J2EE sur plusieurs serveurs• Scort: Progiciel d’intégration avec les

applications mainframes avec des composants J2EE sur WebLogic

• Résultats obtenus• Satisfaction des besoins• Niveau1 offre 2 modes d’accès transparents

aux clients:• Accès aux mainframes en récupérant une connexion

pour exécuter des transactions• Smart publishing: navigation en mode publication à la

volée

Page 18: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

18

Le problème de la persistance des objets

• L’état des objets modifiés par les entity beans doit être sauvegardé durant l’exécution• Approche classique: BD relationnelle avec

mapping objet-relationnel• en général très inefficace avec des entity

beans CMP (cf étude de SQLi mars 2002)• Solutions

• propriétaire de type TopLink• mapping vers une BD objet, par ex. Versant

enJin• la plus productive et efficace selon SQLi

Page 19: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

19

Versant enJin

Serveur d’application Bean

CommandeBean

Produit

Serveur d’application Bean

CommandeBean

Produit

transactions transactions

Tiers backend Bases de données

Mapping O/R automatique

Cache partagé

SGBDO Versant

Page 20: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

20

Avantages de Versant enJin

• Persistance des objets Java transparente• simple pour le développeur

• pas besoin de programmer en JDBC ou autre• Cache d’objets partagés entre différents

serveurs• performances et cohérence via le SGBDO

Versant• Mapping objet-relationnel automatique

vers les BD existantes• définition de la fréquence de synchronisation

• online, batch, etc.

Page 21: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

21

4. Microsoft .NET

• Evolution majeure de la plateforme Windows• les APIs Windows sont remplacées par des

bibliothèques de classes objet• intégration de C#, Linq• portabilité des applications .NET

• Microsoft Intermediate Language (MSIL) exécuté par CLR

• sécurité renforcée avec vérification de code• intégration avec COM et Microsoft Transaction

Server (MTS)• support direct des services Web, de XML et de

SOAP avec Visual Studio .NET

Page 22: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

22

Architecture de MTS

MTS

Active ServerPage (ASP)

Internet InformationServer (IIS)

HTMLXML

Executive• threads• wrapper• context

• factory• trans.• cache

SQLServer

Oracle

Windows

Autres

ADO

HTTP

DCOM

Page 23: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

23

Modèle de composants MTS

• Composant• pas d’état (équivalent à EJB session bean)

• Container• executive : entre client et composant serveur• context wrapper

• définition du comportement trans. du composant par le développeur (par positionnement d’attributs avec Explorer)

• context object• appelé automatiquement par MTS pour

coordonner les transactions en 2 phases• Serveur Windows

Page 24: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

24

Exemple de code applicatif MTS

Set ctxObject = GetObjectContext ()

// accès à l’objet contexte de MTS

{ code applicatif }

Set objExemple = ctxObject.CreateInstance ()

// création d’un objet MTS

{ code applicatif }

If (OK)

ctxObject.SetComplete () // validation de la transaction

Else

ctxObject.SetAbort () // annulation de la transaction

Page 25: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

25

Le framework .NET

ASP.NETDocs HTML XML

BCL.NETBase class library

ADO.NETActive Data Objects

Common Language Runtime (CLR)

Windows et COM/MTS

VisualStudio.NET

OutilsSOAP

etXML

VB, C++, C#, Jscript, Java,etc.

Page 26: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

26

Serveur J2EE versus .NET

• Serveur J2EE• limité à Java• transactions explicites

• généralité• objets avec état: entity beans

• problème de performances des beans CMP• portabilité

• .NET• multi-langage• transactions implicites

• simplicité• objets sans état

• utiliser ADO pour l’accès aux données• propriétaire, intégré dans le monde Windows

Page 27: Serveurs dapplication 1.Architecture 2.Le standard J2EE 3.Etude de cas: EDF GDF 4..NET de Microsoft

27

Conclusion sur les serveurs d’application

• Un modèle d’architecture réellement distribué• cache la complexité du middleware

• Critères de choix d ’un serveur d’application• support des standards

• J2EE, Web services• plate-formes supportées• performances et débit transactionnel• environnement de développement