Architectures orient es services
This presentation is the property of its rightful owner.
Sponsored Links
1 / 61

Architectures orientées services PowerPoint PPT Presentation


  • 57 Views
  • Uploaded on
  • Presentation posted in: General

Architectures orientées services. Web services Serveurs d’application Intégration métier EAI, SOA, Cloud computing, B2B. Web services. Objectifs Architecture Web services Protocole SOAP Architecture REST Composition de Web services . 1. Objectifs des Web services.

Download Presentation

Architectures orientées services

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Architectures orient es services

Architectures orientées services

Web services

Serveurs d’application

Intégration métier

EAI, SOA, Cloud computing, B2B


Web services

Web services

Objectifs

Architecture Web services

Protocole SOAP

Architecture REST

Composition de Web services


1 objectifs des web services

1. Objectifs des Web services

  • Faciliter la construction et la maintenance d’applications distribuées sur le Web avec

    • échange de données indépendant du stockage : XML

    • appel de programmes indépendant du langage: SOAP

  • Service web = module applicatif exposé sur le Web

    • adresse URI

    • interface bien définie

    • implémentée avec des standards Web

      • HTTP, XML, SOAP, UDDI, WSDL, etc.


Exemple gestion de magasin en ligne

Exemple : gestion de magasin en ligne

Authentification

(MTS)

Fournisseur

(J2EE)

SOAP

SOAP

SOAP

Serveur

d’application

Banque

(MVS/CICS)

SOAP

SOAP

SOAP

Paiement CB

(.NET)

Livreur

(CORBA)


Standards techniques

Standards techniques

Publication

des fonctionnalités

WSDL

Publication

des fonctionnalités

WSDL

Accessibles par des

requêtes sécurisées

HTTPS, SSL

Web services

Décrits dans

des annuaires

UDDI

Gérés par des

serveurs de données

XML

Utilisables par toute

application

SOAP


2 architecture des web services

2. Architecture des Web services

Service

Registry

Publish

Find

Client

Service

Provider

Service

Requester

Publish

Request

Request

Service

Provider


Description des services wsdl

Description des services: WSDL

  • Formats des opérations en XML

    • Messages d’appel et de retour

    • Types des paramètres

  • Ports d’accès à des groupes d’opérations

    • Association opérations - messages

    • Liaisons (bindings) pour accéder aux ports avec un protocole spécifique (HTTP, SMTP, MIME, …)

  • Adresses URLs de ces ports pour recevoir les opérations

Service

Port

(e.g. http://host/svc)

Port

Binding

(e.g. SOAP)

Binding

Abstract interface

portType

operation(s)

inMessage

outMessage


Description en wsdl

Description en WSDL

<definitions name = "..." xmlns: …>

<types>

<!--Définition des types de données; basés sur ceux des schémas -->… </types> 

<message>

<!--Déclaration des messages (entrées et sorties)-->…</message>

<portType>

<!--Déclaration des opérations (par association des messages)-->…</portType>

<binding>

<!--Définition de la liaison WSDL – SOAP (noms d'actions et codages)--></binding>

<service name= "… " >

<!--Déclaration des ports (groupes d'opérations et protocoles d'accès)-->… </service>

</definitions>


Exemple getlasttradeprice

Exemple: GetLastTradePrice

<?xml version="1.0"?> <definitions name="StockQuote">

<types> <schema> <element name="TradePriceRequest"> <complexType> <all> <element name="tickerSymbol" type="string"/> </all> </complexType> </element>

<element name="TradePrice"> <complexType> <all> <element name="price" type="float"/> </all> </complexType> </element> </schema> </types>

<message name="GetLastTradePriceInput"> <part name="body" element="xsd1:TradePriceRequest"/> </message>

<message name="GetLastTradePriceOutput"> <part name="body" element="xsd1:TradePrice"/> </message>

<portType name="StockQuotePortType"> <operation name="GetLastTradePrice">

<input message="tns:GetLastTradePriceInput"/>

<output message="tns:GetLastTradePriceOutput"/> </operation> </portType>

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="GetLastTradePrice">

<soap:operation soapAction="http://example.com/GetLastTradePrice"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding>

<service name="StockQuoteService"> <documentation>My first service</documentation> <port name="StockQuotePort" binding="tns:StockQuoteBinding"> <soap:address location="http://example.com/stockquote"/> </port> </service>

</definitions>


Annuaire des services uddi

Annuaire des services : UDDI

  • Universal Description, Discovery Integration

  • Annuaire UDDI

    • Décrit par un document WSDL ou autre

    • Accessible en SOAP

    • Contenu décrit par un schéma XML

  • Fonctions

    • Enregistrement (publish)

      • une société, des services, des opérations

    • Découverte (find)

    • Liaison à une service (bind)


Contenu de l annuaire

Pages blanches (BusinessEntity)

BusinessKey

Name

Description

CategoryBag

BusinessServices

Pages jaunes (BusinessService)

ServiceKey

BusinessKey

Name

Description

CategoryBag

BindingTemplates

Pages vertes (BindingTemplates)

BindinKey

ServiceKey

Description

AccessPoint

Contenu défini par un schéma XML

Spécifications pour réplication

Contenu de l’annuaire

Business

Entity

tModel

Spécifs de services

et taxonomies

Business

Service

PublisherAssertion

Relations entre

deux parties

Binding

Templates

Infos techniques


Principaux fournisseurs

Principaux fournisseurs

  • IBM UDDI Registry

    • Un registre UDDI avec des fonctionnalités de recherche

  • Microsoft UDDI Business Registry (UBR)

  • SAP UDDI Business Registry

    • Public pour l'instant

  • Systinet Registry

    • Support complet de UDDI

  • Oracle Application Server UDDI Registry


3 protocole soap

3. Protocole SOAP

  • Simple Object Access Protocol = RPC pour Web services

    • Standard du W3C par Microsoft et IBM

    • Pas simple, pas objet!

    • Basé sur XML RPC de David Winer (UserLandSoftware)

      • règles de codage des données en XML

      • envelope: définit le contenu du message

      • utilise la requête HTTP POST du client au serveur

  • Objectifs

    • Passer facilement au travers des firewalls (port 80)

    • Portable, faciliter l'accès aux Web services


Message soap

Message SOAP

Protocol Header

En-tête de protocole

(obligatoire): nom du message et

namespace pour sa version de schéma

SOAP Envelope

SOAP Header

(optionnel): extensions de protocole

Pour l’authentification, le contexte

Transactionnel, etc.

SOAP Body

XML content

(obligatoire): opération et paramètres

Attachments


Exemple

Exemple

  • www.stockquoteserver.com

  • float GetLastTradePrice (Symbol)

  • Le dialogue :

Application

Application

Request

Middleware

Middleware

Reply

SOAP

SOAP

HTTP

HTTP

Error

www.stockquoteserver.com


La requ te

La requête

POST /StockQuote HTTP/1.1

Host: www.stockquoteserver.com

Content-Type: text/xml; charset="utf-8" 

Content-Length: nnnn

SOAPAction: "Some-URI#GetLastTradePrice« 

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap">  <SOAP:Body>       <m:GetLastTradePrice xmlns:m="Some-URI">           <symbol>DIS</symbol>       </m:GetLastTradePrice>   </SOAP:Body>

</SOAP:Envelope>

Standard HTTP


La r ponse

La réponse

HTTP/1.1 200 OK

Content-Type: text/xml; charset="utf-8" 

Content-Length: nnnn

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap"/><SOAP:Body>    <m:GetLastTradePriceResponse xmlns:m="Some-URI">           <Price>34.5</Price>     </m:GetLastTradePriceResponse> </SOAP:Body>

</SOAP:Envelope>

Standard HTTP


Interop rabilit avec soap

Interopérabilité avec SOAP

Application

server

SOAP

Processor

SOAP

Processor

Application

server

API

API

Requête

Java

VB

C

Perl

etc.

Java

VB

C

Perl

etc.

XML

Parser

XML

Parser

HTTP

HTTP

TCP/IP

A component

(e.g. EJB)

A component

(e.g. COM)

Réponse

Construction du message

SOAP (par ex. en Java)

Conversion du message

SOAP et appel du

composant (par ex, en VB)


4 rest representational state transfer

4. REST: REpresentational State Transfer

Objectif: style d’architecture légère pour développer des applications Web, alternative à SOAP

  • Il faut éviter :

  • Et remplacer par :

WS 1

Dispatcheur

Centralisé et lourd: interprétation

des URL-L, traitement

SOAP

Appel

(URL-L, SOAP)

WS 2

WS 3

Appel

URL1

WS 1

Messages courts et directs

Appel

URL2

WS 2

Appel

URL3

WS 3


Rest les trois piliers

REST: les trois piliers

  • Ressource

    • Toute entité est une ressource : site Web, page XHTML, document XML, Web service, etc.

  • URL

    • Toute ressource est identifiée de manière unique par une URL logique

  • Opération simple

    • Méthode de recherche, mise à jour, consultation, … directement adressée à la ressource avec un nombre limité de paramètres

      • Ne pas faire: http://www.depot.com/parts:getpart?id=1

      • Faire: http://www.depot.com/parts/1


Rest concepts 1

REST: concepts (1)

  • Une syntaxe universelle pour adresser les ressources: URI logique comme API

    • noms sans paramètres

  • Un protocole sans état: HTTP

    • client et requêtes gardent l’état

  • Des échanges d’ hyperliens dans des documents XML

    • pour représenter les contenus et les transitions d’états

  • Des types MIME comme text/xml, text/html, image/jpeg, application/pdf, video/mpeg pour la représentation des données

  • Sécurité par filtres lors du mapping URL  ressource physique (ex. une page HTML statique)


Rest concepts 2

REST: concepts (2)

  • Une application est un réseau dont les nœuds sont des machines virtuelles (pages Web ou services Web)

  • Le client invoque des URL et reçoit en réponse des URL

  • Il change d’état ("transfers state") en choisissant un lien parmi ceux reçus en réponse

  • Le Web est REST


Rest principes de conception

REST: principes de conception

  • Identifier toutes les entités qui doivent être exposées comme des services: liste de produits, produits, etc.

  • Créer un URL par ressource, en utilisant des noms, pas des verbes (pas “getPart”)

  • Diviser les ressources selon le mode:

    • Lecture: accessible uniquement par GET

      • Sans effet de bord (pas de modif. de la resource)

    • Mise à jour: accessible par POST, PUT et/ou DELETE

  • Utiliser les hyperliens pour obtenir plus de détails à l’intérieur d’une ressource

    • Ex: naviguer dans la liste de produits

  • Spécifier le format des réponses avec un schéma (DTD, XML Schema) et les services (WSDL ou HTML)


Rest versus soap

REST versus SOAP

  • REST

    • Echanges centrés sur des URL courtes entre ressources

      • Échanges limités

    • Simplifie le code client et serveur

    • Pas de support pour transactions ou sécurité

    • Pour des applications simples

  • SOAP

    • Véritable RPC pour Web services

      • Échanges complexes

    • Génération de code client avec WSDL

    • Provision pour transactions et sécurité

    • Pour des applications plus sophistiquées


5 composition de services

Objectifs

Modéliser des processus métiers (business process)

Composer des services Web distribués

Piloter l'exécution

Orchestration d'activités

Echanges XML

Gestion de transactions

Business Process Management

Transaction

Workflow

5. Composition de services

Début

Réserver

Hotel

OK ?

non

Echec

oui

Réserver

Avion

non

Réserver

Train

OK ?

oui

Louer

Voiture

oui

non

OK ?

Echec

non

OK ?

Echec

oui

Succès


Exemple pilotage fabrication

Exemple : Pilotage Fabrication

Mainframe

Echange B2B

Partenaire

Serveur d'entreprise

Usine

XML

XML

XML

WEB

XML

Interface

XML

ERP

XML

Fournisseur

Client


Les briques standardiser

Les briques à standardiser

Choreography - CDL4WS

Orchestration - BPEL4WS

BusinessProcesses

Transactions

Quality ofService

Coordination

WS-Security

WS-Reliability

Context

Management

Discovery

UDDI

Description

Description

WSDL

SOAP

Message

XML

Transport

HTTP, IIOP, JMS, SMTP


Composition de services

Composition de services

  • Objectifs

    • Alliances entre companies pour offrir des services intégrés à valeur ajoutée en combinant des services existants

    • Réutilisation et extension de services existants

    • Support pour la planification, la définition et l'implémentation de services composés

    • Développement d'applications distribuées composées de services web


Quelques d finitions

Quelques définitions

  • Processus métier (business process)

    • Module fonctionnel réalisé par enchaînement d'activités business exécutées par des acteurs échangeant des messages et implémentant les objets et règles spécifiques à une entreprise.

  • Orchestration d'activité

    • Mécanisme d'invocation, de contrôle et de coordination des activités participant à la réalisation de processus d'affaire.

  • Composition de services

    • Techniques permettant d'assembler des services Web pour réaliser des processus métiers par des primitives de contrôles (boucles, tests, traitement d'exception, etc.) et d'échanges (envoi et réception de messages).


Mod lisation par workflow

Modélisation par Workflow

  • Graphe d'activités modélisant un processus métier

Les activités représentent les unités de traitement

Les liens de contrôle définissent le flux d'exécution

Les activités correspondent à des services Web

[ WS]

Les liens de données définissent le flux d'information

Les activités peuvent être d'autres processus métiers


Exemple1

Modélisation en XML

Langage d'orchestration

Chorégraphie d'activités

<activity name="demandePaiement">

<join condition=”(reserverVoiture OR reserverAvion) AND reserverHotel” when=”deferred”>

</activity>

<activity name="reserverAvion">

….

Exemple

commandeVacances

reserverVacances

Commande/classe=1

Commande/classe=2

reserverVoiture

reserverHotel

reserverAvion

demandePaiement


Bpel processus compos d activit s

BPEL: Processus composé d'activités

  • Compositions des web services

  • Langage de programmation parallèle codé en XML

  • Assignation de variables locales et globales


Exemple bpel

Exemple BPEL

<sequence>

<receive partnerLink=“customer” portType=“lns:purchaseOrderPT"

operation=“sendPurchaseOrder” variable=“PO”

createInstance="yes" />

<flow>

<invoke partnerLink=“inventoryChecker” portType=“lns:inventoryPT”

operation="checkINV" inputVariable="inventoryRequest"

outputVariable="inventoryResponse" />

<invoke partnerLink="creditChecker" portType=“lns:creditPT"

operation="checkCRED" inputVariable="creditRequest"

outputVariable="creditResponse" />

</flow>

...

<reply partnerLink=“customer” portType=“lns:purchaseOrderPT”

operation=“sendPurchaseOrder” variable=“invoice"/>

</sequence>


Qualit de services

Qualité de services

  • Nécessité de fiabiliser

    • Les messages (WS-Reliability)

    • Les activités (WS-Transactions)

      • Courtes (Atomic Transactions)

      • Longues (Business Activity)

  • Nécessité de sécuriser

    • Les échanges confidentiels (WS-Security)


Serveurs d application

Serveurs d’application

Architecture

Le standard J2EE

Etude de cas: EDF GDF

.NET de Microsoft


1 architecture avec sa

1. Architecture avec SA

Serveur

Web

Serveur

Web

Présentation Application Données

Appareil

mobile

Serveur

WAP

SGBD

Browser

Web

Serveur

d’application

Application

ERP

Client

Java

Parefeu

Application

mainframe

Client

VB/C++


Serveur d application

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)


Equilibrage de charge et disponibilit

Equilibrage de charge et disponibilité

Cookie A,B

En cas de panne de A,

basculement automatique

sur B

Serveur A

primaire

Réplication de l’état

des processus clients

Serveur B

Secondaire

Cluster


Le probl me d acc s aux donn es

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

Où mettre la logique applicative ?

Composants métiers

Procédures stockées

Serveur d’application

Serveur de données


Acc s bd en c s 2 tiers

Accès BD en C/S 2 tiers

  • Développement d’applications BD en 2 étapes

    • conception de la BD

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

    • programmation des procédures stockées

      Trè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


Composants avec acc s bd

Composants avec accès BD

  • Similaire au C/S

    + efficace

    - composants non autonomes

Gestionnaire de

commandes

Produit

Commande

Select C.a, P.b, …

From C, P

Where …


Composants encapsulant leurs donn es

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 de

commandes

Produit

Commande


Comment am liorer les performances

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


2 le standard j2ee sun et al

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

    • ...


Architectures orient es services

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


Architecture d un serveur j2ee

Architecture d’un serveur J2EE

Logique métier

Logique de présentation

Container Web

Container EJB

Java Server

Page

HTML/XML

Entity

Bean

Session

Bean

Java

Bean

Servlet

Support Comm.

TCP/IP, HTTP, RMI,

IIOP, SOAP, etc.

Services de base

JDBC, JTS, JNDI,

JMS, JDO, JAX, etc.


Principaux serveurs j2ee

Principaux serveurs J2EE


Websphere application server

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


Weblogic bea oracle

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


3 etude de cas edf gdf

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


Solution

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


Le probl me de la persistance des objets

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


Versant enjin

Versant enJin

Serveur d’application

Serveur d’application

Bean

Commande

Bean

Produit

Bean

Commande

Bean

Produit

Cache partagé

transactions

transactions

SGBDO Versant

Mapping O/R automatique

Tiers backend

Bases de données


Avantages de versant enjin

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.


4 microsoft net

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


Architecture de mts

Architecture de MTS

HTML

XML

Active Server

Page (ASP)

Internet Information

Server (IIS)

MTS

SQLServer

ADO

  • Executive

  • threads

  • wrapper

  • context

HTTP

Oracle

  • factory

  • trans.

  • cache

DCOM

Autres

Windows


Mod le de composants mts

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


Exemple de code applicatif mts

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


Le framework net

Le framework.NET

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

Outils

SOAP

et

XML

Visual

Studio

.NET

ASP.NET

Docs HTML XML

BCL.NET

Base class library

ADO.NET

Active Data Objects

Common Language Runtime (CLR)

Windows et COM/MTS


Serveur j2ee versus net

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


Conclusion sur les serveurs d application

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


  • Login