INSTITUT SUPERIEUR DES ETUDES TECHNOLOGIQUES DE SILIANA 1 ARCHITECTURES WEB ET RESEAUX · 2016. 9. 7. · VI. Les Architectures orientées services (SOA) ARCH WEB & RX RSI21 Mr Nizar

ARCHITECTURES WEB

ET RESEAUX

Iset Siliana

[email protected]

ARCH WEB & RX RSI21 Mr Nizar Chaabani

1

2éme RSI

http://www.academiepro.com/enseignants-104-Chaabani.Nizar.html

INSTITUT SUPERIEUR DES ETUDES TECHNOLOGIQUES DE SILIANA






Objectifs


2

Objectifs Généraux

Faire acquérir à l’apprenant les connaissances de base relatives à l’évolution de l’architecture web

- Fournir à l’auditeur les éléments théoriques de la construction et le déploiement des applications web sécurisées et évolutives.

Objectifs Spécifiques

Comprendre la notion d’architecture web.

Connaître les architectures N-tiers, SOA de développement web.

Connaître les concepts du modèle MVC

Se familiariser avec l’architecture des systèmes mobiles

Maitriser l’évolution des réseaux pour la mise en ouvre de ses architectures.

PRE-REQUIS UE : Développement Web et multimédia 1 & 2

Eléments de Contenu


3

Client/Serveur Web : Client léger et client riche.

Architectures n-tiers : 2, 3, n, SOA, etc.

Modèle MVC

Architecture Logicielle J2EE

Architecture des systèmes mobiles

Web sémantique : architecture et concepts

BIBLIOGRAPHIE CONSEILLÉE


4

1) Service-Oriented Architecture Compass - Business Value, Planning and Enterprise Roadmap IBM Press Books by Pearons plc. ISBN 0-13-187002-5

2) Berg (Martin van den), Bieberstein (Norbert),Ommeren (Erik van), SOA for Profit : guide du manager pour une SOA réussie, Sogeti et IBM, 2007

3) Manager avec les ERP, Architecture Orientée Services (SOA), de Jean-Louis Lequeux, Editions d'organisation, Paris, Avril 2008.ISBN 978-2-212-54094-9

4) Birol Berkem, Why SOA services need to be based on the Business Motivation Model (BMM) ?, June 2008

5) SOA, Le guide de l'architecte d'un SI agile, 3e édition, Xavier Fournier-Morel, Pascal Grojean, Guillaume Plouin, Cyril Rognon, Collection InfoPro, Dunod, 2011

Introduction :


5

L'objectif premier d'un système d'information, quel qu'il soit, est de permettre à plusieurs utilisateurs d'accéder aux mêmes informations :

Tout système d'information nécessite la réalisation de trois groupes de fonctions: le stockage des données,

la logique applicative et

la présentation.


6

Stockage et accès aux données :

Le système de stockage des données a pour but de conserver une quantité plus ou moins importantes de données de façon structurée.

On peut utiliser pour cette partie des systèmes (très variés) qui peuvent être :

des systèmes de fichiers,

des mainframes,

des systèmes de bases de données relationnelles,

etc...


7

Logique applicative :

La logique applicative est la réalisation informatique du mode de fonctionnement de l'entreprise.

Cette logique constitue les traitements nécessaires sur l'information afin de la rendre exploitable par chaque utilisateur.

Présentation :

La présentation est la partie la plus immédiatement visible pour l'utilisateur.


8

Le web c'est un ensemble de machines en réseau communiquant à l'aide d'un langage commun.

Le web fonctionne en mode client/serveur

CONS TITU ENT U NE ÉTAP E IMP OR TANTE D ANS L'ÉV OLU TION

D ES S YS TÈMES D 'INF OR MATIONS…

Architectures client/serveur

Serveur web ou httpd


10

Capable d'interpréter les requêtes http arrivant sur le port associé au protocole HTTP

Récupération des données d’un formulaire

REQUEST_METHOD :

POST ou GET

CONTENT_LENGTH :

Taille en octets du corps de la requête

QUERY_STRING :

Données transmises après le ? dans l'URL


11

Principaux serveurs Web


12

Apache (Unix / Linux)

MIIS (Windows)

Microsoft Internet Information Server Java Web Server (versions pour Unix/ Linux / Windows) et Jakarta-Tomcat (qui cohabite avec Apache)

Choix de la technologie

Le choix de la technologie serveur dépend : du système d’exploitation de la machine serveur

du type de bases de données à interroger

de la charge que doit supporter le serveur

Quelques notions de base


13

** Notion 1 : Serveur de données

Plate-forme gérant des bases de données à l’aide d’un SGBD

** Notion 2 : Serveur d’application

Plate-forme gérant des composants applicatifs (EJB, ActiveX, Web Services) et de publication Web (Servelet, JSP, ASP, …)

** Notion 3 : Client [lourd, léger, riche]

Poste de travail avec logiciel de présentation associé gérant l’IHM

Client lourd : code applicatif complet

Client léger : pas de code applicatif, présentation en browser

Client riche : le code applicatif qu’il faut et des outils de présentation sophistiqués (intelligent, smart client)

web 1.0 vs web 2.0 vs web 3.0


14

Rappels Web 1.0


15

Web 1.0 = Service Internet permettant de naviguer à travers des pages HTML statiques via HTTP

Transmission de la requête HTTP

Transmission de la réponse HTTP

par le serveur Web

Serveur Web

Poste client

Navigateur

Pages statiques

HTML et DHTML (côté client)


16

HTML 4.01 Dernière version de HTML, les nouveaux développements

portant sur XML (langage à tags ouverts)

** Notion 4 : DHTML (Dynamic HyperText Markup Language) Ensemble de spécifications complémentaires au HTML

permettant de rendre une page web dynamique côté client: Jscript

DOM

CSS

Web

Web 2.0 : Des techniques nouvelles


17

Ajax: XML sur HTTP en mode asynchrone via Javascript

REST: Style d’architecture de services avec appels HTTP

XForms: Saisie déclarative contrôlée en XML

XUL/XAML: Présentation déclarative en XML

RDF (Resource Description Framework): Langage d’annotation de ressource en XML

…

Web 2.0 : Quelques notions


18

** Notion : Web Service composant logiciel dont l’interface est décrite en XML (WSDL)

et invoquée en XML (SOAP)

** Notion : Ajax technique pour échanger et manipuler les données de manière

asynchrone avec le serveur Web

Une évolution : le Web dynamique


19

We

Requête http

Réponse HTTP

Serveur Web

Poste client

Navigateur

Base de

données

Dossier

contenant les pages

Application métier

Serveur

d'application

Traitement de la requête et sélection du

fichier contenant le programme

Logiciel serveur

Client lourd :


20

Le terme « client lourd », en anglais « fat client » ou « heavy client »par opposition au client léger, désigne une application cliente graphique exécutée sur le système d'exploitation de l'utilisateur.

http://www.commentcamarche.net/cs/client-leger.php3

http://www.commentcamarche.net/systemes/sysintro.php3

Client léger :


21

Le terme « client léger », parfois « client pauvre », en

anglais « thin client » par opposition au client lourd,

désigne une application accessible via une interface web

(en HTML) consultable à l'aide d'un navigateur web, où

la totalité de la logique métier est traitée du côté du

serveur. Pour ces raisons, le navigateur est parfois

appelé client universel.

http://www.commentcamarche.net/cs/client-lourd.php3

http://www.commentcamarche.net/html/htmlintro.php3

http://www.commentcamarche.net/www/navigateur-web.php3

mailto:[email protected]

Client riche :


22

Un « client riche » est un compromis entre le client léger et le client lourd.

L'objectif du client riche est donc de :

proposer une interface graphique, basée sur la syntaxe XML,

obtenir des fonctionnalités similaires à celles d'un client lourd (glisser déposer, onglets, multi fenêtrage, menus déroulants, …).

Il existe des standards permettant de définir une application riche :

XAML (eXtensible Application Markup Language), prononcez « zammel », un standard XML proposé par Microsoft ;

XUL, prononcez « zoul », un standard XML proposé par la fondation Mozilla ;

Flex, un standard XML proposé par la société Macromedia


23

Architectures n-tiers : 2, 3, n, SOA,


24

I. Niveau d’abstraction d’une application

II. Architecture 1-tiers

III. Architecture 2-tiers

IV. Architecture 3-tiers

V. Architecture n-tiers

VI. Architecture SOA

I. Niveau d’abstraction d’une application


25

La couche de présentation

La logique applicative

Les données

Application

II. Architecture 1-tiers


26

Les trois couches applicatives sont intimement liées et s'exécutent sur le même ordinateur

- Les utilisateurs se connectent aux applications exécutées par le serveur central (le mainframe) à l'aide de terminaux passifs

présentation applicative données Tout est sur la même machine



27

- Le poste client se contente de déléguer la gestion des données à un service

spécialisé

- L’ensemble des traitements applicatifs par le poste client : client lourd

- La gestion des données est prise en charge par un SGBD centralisé, s'exécutant le plus souvent sur un serveur dédié

- Ce dernier est interrogé en utilisant un langage de requête qui, le plus souvent, est SQL



28

GET

OUT

Ressources



29

L'architecture à deux niveaux (aussi appelée architecture 2-tier),

« tier » signifiant rangée en anglais,

caractérise les systèmes clients/serveurs pour lesquels :

le client demande une ressource (GET), et

le serveur la lui fournit directement (OUT), en utilisant ses propres ressources.


30

Client : présentation + applicatif

Serveur : applicatif + gestion données

présentation applicative données

Client Serveur

données applicative présentation

Serveur Client



31

- Les données sont toujours gérées de façon centralisée

- La présentation est toujours prise en charge par le poste client

- La logique applicative est prise en charge par un serveur intermédiaire

Client Serveur

applicatif BDD

Tier 1 Tier 2 Tier 3

Présentation Logique métier Données



32

GET

OUT

GET

OUT

Ressources



33

Dans l'architecture à 3 niveaux, appelée architecture 3-tiers,

il existe un niveau intermédiaire, c'est une architecture partagée entre :

1. Un client, c'est-à-dire l'ordinateur demandeur de ressources, équipée d'une interface utilisateur (généralement un navigateur web);

2. Le serveur d'application (ou middleware), chargé de fournir les ressources mais faisant appel à un autre serveur;

3. Le serveur de données (ou database server) qui va fournir au serveur d'application les données dont il a besoin.

http://www.commentcamarche.net/pc/pc.php3

http://www.commentcamarche.net/www/navigateur.php3



34

SGBD

Application

ERP

Browser

Web

Appareil

mobile

Client

Java

Client

VB/C++

Serveur

Web

Serveur

WAP

Parefeu

… Application

mainframe

Serveur

d’application

Tiers Client Tiers Milieu Tiers Backend

…



35

Les 3 principaux tiers s'exécutent chacun sur une machine différente

présentation applicative données

Couche présentation Navigateur web sur machine cliente Client léger

Couche applicative / métier Serveur d'applications , Serveur HTTP exécutant des composants / éléments logiciels qui génèrent dynamiquement du contenu HTML Via des requêtes à des BDD distantes

Couche persistance Serveur(s) de BDD de données



36

ARCH WEB & RX RSI21 Mr Nizar Chaabani 37


dans l'architecture à 3 niveaux, chaque serveur (niveaux 2 et 3) effectue une tâche (un service) spécialisée :

Un serveur peut donc utiliser les services d'un ou plusieurs autres

serveurs afin de fournir son propre service.



38

VI. Les Architectures orientées services (SOA)


39

Les applications au sein d’une entreprise : plusieurs technologies

Application .NET

Application Java Portail WEB

Application Java 2

Application .NET 2

Portail WEB 2



40

Client 1 Client 2 Client 3

Service Métier 1

Service Métier 2

Service Métier 3

Sans couche de médiation



41

Client 1 Client 2 Client 3

Service Métier 1

Service Métier 2

Service Métier 3

Couche de Médiation

Avec couche de médiation



42

L’architecture orientée service constitue un style d’architecture basée sur le principe de séparation de l’activité métier en une série de services. »

Processus métier

Fonctionnel Use cases

Applicatif Applications & logiciels

Physique Infrastructure

Métier

Technique

Vue logique

Permet à des systèmes hétérogènes d’interopérer A travers les langages, les plateformes, les applications

D’ordinateur à ordinateur

A l’intérieur ou à l’extérieur d’un firewall

Fondé sur des standards internet XML, SOAP, WSDL, UDDI

Technologie universellement adoptée Consensus des acteurs clés

Web Services, l’interopérabilité sans adhérence ! VI. Les Architectures orientées services (SOA)

43


VI. Les Architectures orientées services (SOA) 44 SOA et Web Service ->fonctionnement

Le fonctionnement des services web repose sur un modèle en couches, dont les

trois couches fondamentales sont les suivantes :

•Échange , visant à décrire la structure des messages échangés par les

applications.

•Découverte, pour permettre de rechercher et de localiser un service web

particulier

•Description, dont l'objectif est la description des interfaces des services web ARCH WEB & RX RSI21 Mr Nizar Chaabani


45

Les 4 grands principes du SOA

La définition des services

Les services sont autonomes

Les clients et les services ne partagent que des contrats

La compatibilité est basée sur les règles


Qu’est ce que SOA-> Principes

Service

Contrat

Implémentation

Service 2

Service 1

Application 2

Application 1

Message traité

Message à traiter

46

Besoin de standardisation et la mise en commun des protocoles ( SOAP, XML,….)

La pensé orientée services SOAP (Simple Object Access Protocol) est un protocole d'échange




47

Cycle de vie des services

Identifier les services à mettre en place ;

Pour cela il doit répondre à quelque critère suivant :

la réutilisation

l’interopérabilité, offerte via Internet à d’autre SI

autorise son emploi dans une composition.

VI. Les Architectures orientées services (SOA) Processus


48

Modèle orienté objets

(POO)

Modèle orienté services (SOA)

VI. Les Architectures orientées services (SOA) Processus


49

Il s’agit de centraliser la logique d’un processus dans un composant dédié, qui prend en charge l’enchaînement et les règles de gestion

Identity

Authentication

Encryption

Billing

Royalties

Access control

State

Recovery

Queuing

Timestamp

Statistics

Performance

Transform service,

request

Monitoring

SLA Access

Control Logging

XML

Firewall Transform

Intrusion

Attack

Accounting

Security Aggregate

Composite

Aggregate or

Composite

services

Service

Implementations

Other

Web

Services

Switch Service

Switch Implementation

Physical

Connection

Connector

Route State

Mngmt

Prioritization

Administration des services

•Disponibilité, Versioning, Monitoring, Déploiement

•Routage dynamique des requêtes et des réponses

•Audit, log

•Usage, facturation…

•Sécurité: authentification, autorisation, cryptage, signature

Architectures Orientées Services

50


Architectures Orientées Services

Les architectures SOA permettent aux applications de communiquer avec les différentes ressources (données, infrastructure, processus) par l’échange de messages entre interfaces réseaux SOA est permet de définir d’ interfaces

stables et cohérentes offertes sur des implémentations volatiles

Synthèse 51


Design Pattern MVC 52



53

Architecture web

standard

Architecture web MVC

Models, Views, and Controllers

Browser

Controller

View Model

Database

Web Server HTTP

SQL

MVC

• Le Modèle-Vue-Contrôleur organise l'interface Homme-machine d'une application logicielle en

– un modèle (objet métier, modèle de données)

– une vue (présentation, interface utilisateur)

– un contrôleur (logique de contrôle, gestion des événements, traitement)

55


MVC - objectifs

• séparation entre

– les données

– la présentation

– les traitements

• Meilleur réutilisabilité du code

– Facilite la maintenance

56


MVC Frameworks

J2EE: Struts

Spring MVC

PHP CakePHP

Strusts4php

C#.NET Girders

Ruby on Rails

57


MVC - web

• La logique applicative est constituée des scripts réalisant les demandes de l'utilisateur (contrôleur), des classes métiers et des classes d'accès aux données (modèle).

• L'interface utilisateur sera gérée la plupart du temps par un navigateur web, elle peut éventuellement être un autre site web communiquant via des webservices.

58


MVC en image

•couche ihm: c'est l'interface utilisateur encore appelé interface homme machine •couche métier : c'est le coeur de l'application où réside les objets traités par l'application •couche dao : couche d'accès aux données (data access object). Cette couche permet une indépendance de la logique métier et du stockage des données associées

59


MVC en action

1. le client fait une demande au contrôleur. Ce contrôleur voit passer toutes les demandes des clients

2. le contrôleur doit traiter la demande. Pour ce faire, il peut avoir besoin de la couche métier, cette dernière peut éventuellement accéder aux données (via la couche dao)

3. le contrôleur effectue les traitements nécessaires sur / avec les objets renvoyés par la couche métier

4. le contrôleur sélectionne et nourrit la (les) vue(s) pour présenter les résultats du traitement qui vient d'être effectuée

5. la vue est enfin envoyée au client par le contrôleur

60


Le modèle

• décrit et contient les données manipulées par l'application, ainsi que des traitements propres à ces données

• les résultats renvoyés par le modèle sont dénués de toute présentation

• le modèle contient toute la logique métier de l'application

61


Le modèle - DAO

• Data Access Object – Le Dao a pour but de transformer chaque enregistrement

contenu dans une bases de données en objets et inversement

• Correspondance bijective (SGBD / paradigme objet) – une table (appelée aussi relation) une liste d’objets – une ligne d’une table (appelée aussi tuple ou

enregistrement) un objet – un champs de base de données un attribut d’objet – une valeur d’un champs une valeur d’attribut d’un

objet

• L’objet est capable de se sauver / détruire en base

62


Le modèle - la couche métier

• Idéalement la couche métier utilise une ORM et un DAO, qui utilisent eux-mêmes la DAL – Dans ce cas là les méthodes CRUD (Create Read Update

Delete) ainsi que les dépendances entre objets sont gérées par les couches supérieures

• La couche métier ne contient alors que les traitements métiers (propre à l’objet)

63


Le modèle 64


vue

• interface avec laquelle l'utilisateur interagit

• présentation des résultats renvoyés par la couche modèle, après le traitement du contrôleur

• recevoir toutes les actions de l'utilisateur (clic de souris, sélection d'une entrée, boutons, soumission de formulaire …) – événements envoyés au contrôleur

• La vue n'effectue aucun traitement

65


contrôleur

• Détermine l'action à réaliser (analyse de la requête HTTP)

• gestion des événements de synchronisation entre modèle et vue

• Si une action nécessite un changement des données

– demande la modification des données au modèle

– avertit ensuite la vue que les données ont changé pour qu'elle se mette à jour

66


Contrôleur et actions

• Le contrôleur analyse la requête HTTP (et notamment les variables) – pour déterminer l’action à exécuter

• Le contrôleur doit déterminer les vues associées (les templates HTML, mais aussi les css et js à embarquer)

• Multitude d’action = contrôleur lourd – Modèle MVC2 • Un contrôleur principal redirige vers des contrôleurs

spécialisés (méthode dispatch) • Les contrôleurs spécialisés exécutent effectivement l’action

67


Séquence typique de traitement MVC2

1. la requête est analysée par le front contrôler

2. Le contrôleur spécialisé adéquat est appelé avec la requête en paramètre

3. Le contrôleur spécialisé demande, via l’action adéquat, au(x) modèle(s) approprié(s) d'effectuer les traitements

4. le contrôleur spécialisé sélectionne la (les) vue(s) adaptée(s)

5. le contrôleur spécialisé remplit la vue adaptée avec le résultats des traitements

6. le contrôleur spécialisé renvoie la vue adaptée.

68


BONNES PRATIQUES POUR L’ADMINISTRATION DES SITES

WEB


69


70

Application utilisant le protocole HTTP (80) ou HTTPS (443) pour être pilotée par un utilisateur

L’utilisateur a besoin d’un simple navigateur Web ou d’une application propriétaire utilisant le protocole HTTP/HTTPS pour travailler sur l’applicatif

Architecture d’une application Web


71

HTTP / HTTPS Port 80 / 443

Client Web Firewall Classique

Serveur Web

Apache IIS

Iplanet Zeus Etc.

App. Web

App. Web

XML, Soap, HTML, etc.

XML

DB

DB

Application Server

CGI, PHP Etc.

RMI IIOP XML Soap etc.

SQL XML JDBC etc.

Les attaques web


72

SQL Injection


73

technique qui permet aux attaquants d’injecter des requêtes SQL directement sur la base de données qui se trouve derrière un serveur Web, en manipulant l’entrée « INPUT » à une application.

Exemple : sur une page d’authentification « login.asp », l’utilisateur est amené à saisir un Nom d’utilisateur « User1 » et un mot de passe « pass2012 », cette opération se traduit sous forme d’un requête SQL :

SELECT * FROM Utilisateur WHERE nom= ‘User1' and mot_passe=‘pass2012’


74

Dans le cas de SQL Server, « -- » est utilisé pour mettre un commentaire jusqu’à la fin de la ligne, la requête serait alors

SELECT * FROM Utilisateur WHERE username= or 1=1

Cette requête recherche dans la base de données les champs dont le nom d’utilisateur est vide en réponse à la condition. La requête va retourner tous les champs de la table utilisateur et l’attaquant serait authentifié.

L’attaquant a réussi ainsi à s’authentifier sans avoir pour autant utilisé de nom d’utilisateur ni de mot de passe.


75

SQL INJECTION – Comment se protéger


76

Les fondamentaux défenses:

Règle 1:Utilisation Prepared Statements(requêtes paramétrées)

Règle 2:Utilisation de procédures stockées.

Règle 3: Valider toutes les entrées utilisateur Fourni de coté serveur

Les défenses additionnel:

Exécuter avec le moindre des privilèges.

White List Input Validation.

Protection contre les injections


77



78



79



80

Protection contre le vol de session


81



82



83

Bonnes pratiques pour l’administration des sites web


84

1)Sécurisation de la plateforme d’hébergement:

Mise à jour et hardening du serveur.

Détection d’intrusion réseau.

Détection d’intrusion au niveau de l’hôte (HIDS).

Détection antivirale

Filtrage applicatif



85

2)Suivi et audit des logs enregistrés au niveau de la plateforme de connexion :

log d’administration,

log d’accès public,

3.Sauvegarde des données sensible :

Applicatif

base de données



86

SECURISATION DU BD

Mettre à jour le SGBD avec les derniers correctifs stables

Utiliser des algorithmes de hachage/cryptage pour stocker les données critiques

Sécuriser le serveur de base de données derrière un firewall et utiliser un IDS pour détecter toute tentative d’intrusion

Le serveur de base de données ne devrait pas avoir une adresse IP accessible au public

L'accès à la base de données ne devrait être autorisé qu'à partir du serveur web sur un port bien particulier



87

Protéger contre les attaques de brute force Utiliser l'authentification forte, si possible (one time password,

certificat numérique, etc.) Verrouiller un compte après un nombre déterminé de tentatives de

connexion a échoué

Identifier l'emplacement dans le réseau: Serveur web est situé dans une DMZ

Évaluer la configuration du firewall: Serveur web est protégé par un pare-feu de couche d'application Firewall contrôle tout le trafic entre l'Internet et le serveur web Pare-feu bloque tout le trafic entrant vers le serveur web, sauf les

ports TCP 80 (HTTP) et / ou 443 (HTTPS)



88

Évaluer les commutateurs réseau Les commutateurs sont utilisés pour protéger contre

les écoutes réseau Évaluer les répartiteurs de charge (Load

balancers) Les répartiteurs de charge sont utilisés pour

augmenter la disponibilité du serveur web Les équilibreurs de charge sont complétés par les

caches web Evaluer le reverse proxy Le reverse proxy est utilisé comme une passerelle de

sécurité pour accroître la disponibilité du serveur web


89

Architecture Logicielle J2EE

Qu’est ce que le Java EE (ou J2EE)


90

La Plateforme JEE désigne les technologies Java utilisées pour le développement d'applications «d’entreprise » distribuées (Répartie, multi-couches, n-tiers)

JEE est une plate-forme fortement orientée serveur.

Répartition des fonctions


91

1. sur la couche présentation, une application cliente est chargée de l’affichage et de la saisie des données

Client web léger, Application java client ou applets (RMI),

2. sur la couche application, un serveur d’application maintient des composants métiers utilisés pour modéliser sous forme d’objet les processus de l’application Serveurs de:

présentation, outils métiers, servlets,JSP , EJB

3. sur la couche données, les serveurs du système d’information d’entreprise stockent les composants métiers

bases de données relationnelles ou objets, intégrés (ERP), annuaires d’entreprise LDAP,…

Serveurs d'applications JEE


92

Architecture Web

Architecture: schéma de principe


93

Principes de JEE

L’architecture JEE est une architecture d’application distribuée à base de composants. Ces composants sont mis en œuvre par l’intermédiaire des conteneurs

94

Conteneur EJB

Composant Métier

Bean

Serveur de bases de données

Conteneur

Applet

Composant Client

Applet/ Html/wml

Conteneur Web

Composant Web Servlet/JSP

Internet

Tiers Interface Tiers

Services Web Tiers

Données Tiers Métier

Serveur d’application Serveur Web

Navigateur


Composants J2EE

Un composant est une unité logicielle de niveau applicatif.

JEE supporte les types de composants suivants :

applets,

application clientes,

JavaBeans

composants Enterprise JavaBeans (EJB),

composants Web,

composants adaptateurs de ressource

etc

95



96

Android


97

Première plateforme ouverte pour appareils mobiles.Les applications natives et tierces utilisent les mêmes API.

Un système d’exploitation open source libre pour appareils mobiles;

Un environnement de développement ouvert construit sur un noyau Linux open source;

Concurrents


98

iOS(iphone OS): Un système mobile développé par Apple;

Windows mobile: C’est le nom générique donné à différentes versions de Microsoft Windows

Pourquoi développer une application mobile?


99

Pour les professionnels

✔ L’application augmente l’accessibilité au site

✔ L’application permet de générer du trafic

✔ Le marché est en pleine croissance

✔ Une application contribue à l’image de marque

Versions disponibles


100

Plateforme de téléchargement


101

Google Play : anciennement dénommée Android Market Boutique en ligne

Client mail (Gmail)

Gestion des SMS

PIM (Google Calendar, gestion des contacts, etc.)

Google Maps

Navigateur Web basé sur WebKit

Messagerie instantanée (Google Chat, MSN, etc.)

Android Market Place

etc.

Architecture générale


102

Architecture - Kernel Linux


103

Basé sur Linux (version du noyau : 2.6) mais ce n'est pas Linux ! (pas de support de la glibc, X non présent)

Le kernel Linux offre : Une couche d'abstraction matérielle

Gestion de la mémoire

Gestion des processus

Gestion de la couche réseau

Il est possible d'accéder à la console (le shell) depuis la commande adb

Architecture - Application Framework Core Plateform Services


104

Activity Manager

Gère le cycle de vie des applications

Maintient une « pile de navigation » permettant de switcher d'une application à une autre et de restaurer son état précédent

Package Manager

Utilisé par l'Activity Manager pour charger les informations des fichiers .apk (Android package file)

Window Manager

Gestionnaire de fenêtres des applications

Resource Manager

Gère tout ce qui ne relève pas du code (ressources statiques, images, audio, etc.)

Content Provider

Gère le partage des données entre applications

View System

Fournit l'ensemble des composants graphiques

Architecture - Application Framework Hardware Services


105

Permettent d'accéder aux APIs matérielles de bas niveau

Telephony Service

Permet l'accès aux interfaces "téléphonique" (GSM, 3G, etc.)

Location Service

Permet d'accéder au GPS

Bluetooth Service

Permet d'accéder à l'interface bluetooth

Wifi Service

Permet d'accéder à l'interface Wifi

USB Service

Permet d'accéder aux interfaces USB du terminal

Sensor Service

Permet d'accéder aux détecteurs (détecteurs de luminosité, etc.)

Le moteur d'exécution d'Android


106

Un moteur d'exécution (« runtime system » en anglais) est un programme qui permet l’exécution d'autres programmes.

pour utiliser des applications développées en Java sur votre ordinateur vous avez besoin du JRE (« Java Runtime Environment »).

Pour Android Elle contient certaines bibliothèques de base du Java accompagnées de bibliothèques spécifiques à Android et la machine virtuelle « Dalvik ».

la compilation et à l'exécution d'un programme Java standard.


107

la compilation et à l’exécution d'un programme Android standard


108

Arborescence d’un projet Android


109

Arborescence d’un projet Dossiers crées

automatiquement lors de la création d’un projet :

bin : binaires generés

libs : bibliothèques

res : fichiers de ressources (icones, layout, . . . )

src : fichiers sources (code Java)

Installation d’une application


110

Liste des périphériques avec ADB

ADB (Android Debug Bridge) outls d'une communication entre le smartphone et pc.

adb devices

Installation Une application est installée sur un AVD ou sur un matériel a l’aide de la commande :

adb install NomApk.apk


111

Boîte à outils

SDK Android


112

Le kit de développement Android(SDK) fournit l’environnement de travail pour développer, tester et déboguer des applications Android.

Dans le SDK on trouve:

1. Les API Android qui sont le coeur du SDK. Composés de bibliothéques d’API Android, ils donnent au développeur accès à la pile Android.

2.Des outils de développement qui permettent de compiler et déboguer vos applications.

3.Le virtual Device Manager et l’Emulateur qui fournit un meilleur environnement de test

Virtual Device Manager


113

Le SDK Android et le Virtual Device Manager sont utilisés pour créer et gérer les AVD(Android Virtual Devices) et les packages du SDK.

Emulateur


114

L’emulateur d’Android est un outil de test et de débogage d’application Android.

Il fournit une connexion réseau complète, une simulation d’envoi et de réception d’appels et de SMS.

Composants d’une application Android


115

Les applications Android sont constitués de composants à couplage.

Les composants sont liés par un manifeste d’application qui décrit chacun d’eux et comment ils interagissent.

Activity : le cycle de vie


116

Documents

INSTITUT SUPERIEUR DES ETUDES TECHNOLOGIQUES DE SILIANA 1 ARCHITECTURES WEB ET RESEAUX · 2016. 9. 7. · VI. Les Architectures orientées services (SOA) ARCH WEB & RX RSI21 Mr Nizar