www.annales-exam.

com

Le site n°1 des annales !

Examen_FOD_NSY107N_30janvier2010_solutions.docx

C.N.A.M. Le 30 janvier 2010

Centre d'Enseignement de Nantes 9h00
25 bd Guy Mollet durée 2h00, documents autorisés
44000 NANTES Salle d'examen
Tel. 02.40.16.10.20 Mr PICHEREAU
NSY 107 Examen 1ère session

De 0 à n réponses possibles avec droit à une erreur par question, une erreur étant considérée comme
un chiffre entouré mal à propos. Un point est attribué par question si la (les) réponse(s) est (sont)
ièmes
complète(s). Si le(s) choix de l'étudiant n'est (ne sont) pas complet(s), des n de point sont
attribués.

Entourer les bonnes réponses au stylobille et rendre le document

Question 1

Les RPCs :

1 - Peuvent sont toujours cryptées 0

2 - Sont de même couche OSI que les RMI (Remote Invocation Method) 1
3 - Sont deux couches plus haut dans le modèle OSI, que les sockets 1
4 - Font appel aux sockets les sockets 1
5 - Sont d'un niveau d'abstraction inférieur aux sockets 0
6 - Ont été développées à l'origine par NFS pour la mise en œuvre de SUN 0

Question 2

Les sockets :

1 - Correspondent à une bibliothèque d’API réseau développées à l'origine pour Unix 1

2 - Correspondent à des points d'entrée de programmation réseau de couche 5 1
3 - Existent sous TCP/IP ou IPX/SPX ou NetBEUI 0
4 - Permettent d'attaquer directement IP en couche 3 grâce au type SOCK_RAW 1
5 - Permettent aux développeurs de ne pas avoir à gérer les couches basses du réseau 1
6 - Permettent d'échanger des flux hexadécimaux entre processus souvent distants 1

Question 3

Les RPC :

1 - Peuvent indifféremment faire appel au format XDR ou BER pour l’échange des données 0
2 - Manipulent des données qui peuvent être des structures complexes 1
3 - Sont capables de passer plusieurs structures de sonnées utilisateur lors d'un appel 0
4 - Relèvent de la couche 7 du modèle OSI 1
5 - Ont été développées à l'origine par SUN pour l'application Network File System 1
6 - Se basent exclusivement sur les sockets 1

Question 4

Le portmapper :

1 - Sert à identifier une paire de sockets 0

2 - Sert à identifier le nom d’une procédure distante 0
3 - Sert à identifier le nom d'une bibliothèque de clients RPC 0
4 - Sert à obtenir le numéro de port sur lequel contacter une bibliothèque de procédures distantes 1
5 - Sert à connaître le protocole de transport UDP ou TCP d’une bibliothèque de RPC 0
6 - Tourne le plus souvent sur le port bien connu 111 (well known port) 1
Examen_FOD_NSY107N_30janvier2010_solutions.docx

Question 5

NFS (Network File System) :

1 - Est faiblement sécurisé en standard 1

2 - Fait appel au format de fichier XDR (eXchange Data Representation) 0
3 - Est un système de gestion de fichiers réparti sur plusieurs hôtes 1
4 - Offre la possibilité de verrouiller des fichiers partagés 1
5 - Fait appel à la commande mount() pour le montage des arborescences 1
6 - Fait appel aux RPCs, aux sockets et à UDP/IPX 0

Question 6

Le protocole SNMP (Simple Network Management Protocol) :

1 - Est bien sécurisé particulièrement dans sa version 3 1

2 - Fait référence aux MIB (Management Information Base) 1
3 - Fait appel à 5 commandes 1
4 - Fait appel au protocole de transport TCP et utilise les ports 162 et 161 0
5 - Décrit le fonctionnement des agents à l'écoute sur le port 162 0
6 - Est capable d'administrer aussi bien des systèmes Unix, que Windows, que MAC 1

Question 7

Parmi les protocoles ou applications suivants, lesquels ne correspondent pas à des annuaires:

1 - Active directory 0
2 - WINS 0
3 - DNS 0
4 - SMTP 1
5 - NNTP 1
6 - ISDN 1

Question 8

Les RPC sont :

1 - De même couche du modèle OSI que les sockets 0

2 - Des commandes de la couche OSI 9002 Application 0
3 - Dépendantes des sockets de couche 5 1
4 - Implémentées exclusivement par SUN, Microsoft et Novell 0
5 - Cryptées avec TCP mais pas avec UDP 0
6 - Plus Simples à mettre en œuvre que les sockets 1

Question 9

Les applications ou protocoles qui ne fonctionnent pas sur la base d’une requête de demande
d’établissement de connexion de la part du client, sont :

1 - DHCP (Dynamic Host Configuration Protocol) 1

2 - ARP (Address Resolution Protocol) et RARP (Reverse Address Resolution Protocol) 1
3 - HTTP (HyperText Transfer Protocol) 0
4 - Requêtes WINS dans un contexte de serveur WINS 0
5 - Ping sur la base d’un message ICMP de type 08 et de type 00 1
6 - L’échange RPC résultant de : clnt = clnt_create(host, CALCUL, VERSION_UN, "tcp"); 0
Examen_FOD_NSY107N_30janvier2010_solutions.docx

Question 10

Le protocole DHCP :

1 - Est un protocole de configuration automatique des clients TCP/IP 1

2 - Est un protocole capable d’effectuer de la résolution de noms Internet en adresse IP 0
3 - N’est pas capable de gérer des systèmes se trouvant au-delà des routeurs 0
4 - Fait appel à un serveur DHCP dont l’adresse IP est connue des clients DHCP, au préalable 0
5 - Fournit uniquement une adresse IP, un masque de sous-réseau et l’adresse IP de la passerelle 0
6 - Utilise au niveau de la couche Transport, le protocole UDP 1

Question 11

Selon l’Annexe 1, il est possible d’affirmer que :

1 - L'achat en ligne via .net est tripartite 1

2 - Les informations confidentielles client sont conservées sur l'hôte local 0
3 - Le client possède un identifiant unique quel que soit le site visité 1
4 - L'échange commercial est basé sur un système d'identification, authentification et de cryptage 1
5 - L'algorithme de cryptage utilisé lors des paiement est propriétaire 0
6 - Le garant tiers de confiance est Microsoft 1

Question 12

Selon l’Annexe 2, il est possible d’affirmer que :

1 - Le protocole SOAP peut remplacer les RMI 0

2 - Le protocole SOAP peut être assimilé à la couche Application du modèle OSI 0
3 - Le protocole HTTP peut encapsuler des messages SOAP 1
4 - Le protocole SOAP permet l'interopérabilité des applications réparties 1
5 - Le protocole SOAP peut utiliser plusieurs protocoles de transport différents dont des protocoles de
transport de messages 1
6 - Le protocole SOAP peut se substituer au protocole de transport STX 0

Question 13

Selon l’Annexe 3, il est possible d’affirmer que :

1 - Le protocole SOAP ne permet d'encapsuler que des requêtes SQL de tous types 0
2 - Le message SOAP comporte, outre des données, le nom des services sollicités 1
3 - Le protocole SOAP peut être assimilé à la couche Présentation du modèle OSI 1
4 - Le protocole SOAP peut être assimilé à la couche Session du modèle OSI 0
5 - Le service SOAP reçoit des messages et les redirige vers d'autres serveurs locaux ou distants 1
6 - Le protocole SOAP est utilisé largement dans la plate-forme RPC de SUN 0

Question 14

Selon l’Annexe 4, il est possible d’affirmer que :

1 - UDDI est un protocole de même nature que X.400 0

2 - UDDI est un protocole de résolution de ressources 1
3 - UDDI est similaire à X.509 avec des possibilités de découverte de services 0
4 - UDDI est un gestionnaire de base de données SQL 0
5 - UDDI utilise les protocoles de l'Internet 1
6 - UDDI est un protocole d'annuaire électronique universel 1
Examen_FOD_NSY107N_30janvier2010_solutions.docx

Question 15

L'expression suivante :

ldap://corbeau.int-evry.fr:389/dc=int-evry,dc=fr?host?sub?uid=test test host corne.int-evry.fr

1 - Correspond à une requête SQL 0

2 - Correspond à une requête X.500 0
3 - Correspond à une requête LDAP 1
4 - Fait référence au port destination 0x0185 1
5 - Est une requête d'annuaire à la machine nommée "corbeau" du domaine "int-evry.fr" 1
6 - Est au format des Uniform Resource Locator 1

Question 16

Ce protocole d'abstraction de l'accès aux ressources électroniques et informatiques a connu

deux versions en 1988 et en 1993, il est considéré comme très lourd et a fait l'objet d'une
implémentation dans Exchange Server, a été à l'origine d'une adaptation pour l'Internet à
l'initiative de l'Université du Michigan ; il s'agit du protocole :

1 - LDAP 0
2 - DNS 0
3 - WINS 0
4 - X.400 0
5 - X.500 1
6 - X.509 0

Question 17

Ce protocole a été développé par Netscape pour offrir sécurité et confidentialité sur l'Internet. Il
permet d'identifier clients et serveurs dans une connexion de type socket et s'inscrit comme
une couche intermédiaire du protocole de communication (niveau Session). Il n'est pas lié à
une application en particulier et permet donc de sécuriser tout protocole existant d'application
Internet, que ce soit HTTP, FTP ou Telnet et ce, sans modifier les logiciels. Il a bien entendu été
implanté sur le navigateur de Netscape et a été présenté pour être adopté comme standard de
l'Internet. Il s'agit de :

1 - Secure Socket Layer 1

2 - Secure SHell 0
3 - S-HTTP 0
4 - IP-IP 0
5 - IPSec 0
6 - SSL 1

Question 18

Il a été le premier système a implanter une identification des participants à un réseau ouvert et
il est d'ailleurs le seul qui soit d'usage courant aujourd'hui. Il fut développé par l'équipe du
projet Athena au MIT, en se basant sur le protocole de Needham et Shroeder à clef secrète. Ce
protocole, un peu ancien (il date de 1978) proposait une méthode d'identification basée sur la
présence d'un service central de distribution de clefs, lequel distribue des clefs secrètes à ses
clients.
Examen_FOD_NSY107N_30janvier2010_solutions.docx

Ce service reconnaît l'identité des clients par des méthodes fiables (càd. pas des mots de
passe). Il maintient donc une base de données des identités. Il a été conçu pour permettre de
gérer l'accès à des ressources par des machines non sécurisées à travers un réseau non
sécurisé. C'est ainsi qu'il est implanté dans le UNIX du MIT, dans le DCE de OSF, dans le
Andrew File System, et certains dérivés de NFS. Avec lui, un client désirant accéder à un
serveur va demander au serveur de clefs la recommandation (appelée « ticket de session ») qui
lui permettra d'accéder à une ressource donnée pour un temps limité. Il s'agit de :

1 - X.400 0
2 - X.500 0
3 - X.509 0
4 - SSL 0
5 - IPSec 0
6 - Kerberos 1

Question 19

Selon l’Annexe 5, il est possible d’affirmer que :

1 - Les données fournies correspondent à une authentification Kerberos 0

2 - Les données fournies correspondent à un certificat 1
3 - Le protocole mis en jeu est X.400 0
4 - Le protocole mis en jeu est X.500 0
5 - Le protocole mis en jeu est X.509 1
6 - Les données véhiculées émanent d'un tiers de confiance 1

Question 20

Le produit commercial client/serveur vanté dans l’Annexe 6, est :

1 - Un serveur de messagerie 0
2 - Un serveur de gestion des files d'attentes MOM 1
3 - IBM MQ-Series 1
4 - Lotus Notes 0
5 - Réalise du Message Oriented Middleware 1
6 - Un moniteur transactionnel 0

Question 21

Les trois propositions de l'Annexe 7 correspondent :

1 - A des langages ou des définitions de langages utilisés pour traiter la couche Présentation du
modèle OSI 1
2 - A des langages ou des définitions de langages utilisés pour traiter la couche Application du modèle
OSI 0
3 - Respectivement à de l'IDL, de l'ASN.1 et du HTML 0
4 - Respectivement à de l'IDL, de l'ASN.1 et du XML 0
5 - Respectivement à de l'ASN.1, de l'IDL et du HTML 0
6 - Respectivement à de l'ASN.1, de l'IDL et du XML 1
Examen_FOD_NSY107N_30janvier2010_solutions.docx

Question 22

Les propriétés de DCE sont :

1 - La gestion globale des certificats 0

2 - La gestion des transactions 0
3 - La gestion des MOM 0
4 - La gestion des fichiers répartis 1
5 - La localisation des ressources 1
6 - La gestion de la sécurité 1

Question 23

Dans le modèle OSI de l'ISO, les couches dites "intermédiaires" sont :

1 - Les couches dont les services seront orientés vers les applications ou les utilisateurs 0
2 - Les couches 5, 6 et 7 0
3 - Les couches 4 et 5 0
4 - Les couches qui offrent un degré d’abstraction élevé et qui tendent à faire "oublier" le réseau 0
5 Les couches Session et Transport 0
6 - Les couches dans lesquelles seront traitées les problèmes de représentation des données 0

Question 24

Dans le modèle OSI, la couche 3 Réseau permet :

1 - D'interconnecter des réseaux par le biais de passerelles nommées routeurs dans le cas d'IP 1
2 - D'interconnecter des réseaux de technologies différentes 1
3 - Un système d'adressage global et logique basé sur des adresses uniques 1
4 - D'établir des détections de bout en bout particulièrement pour X.25 0
5 - La fragmentation pour résoudre les problèmes de MTU 1
6 - L'échange de données dans les deux sens entre la couche Transport et la couche Liaison 1

Question 25

Dans le modèle OSI, la couche 4 Transport :

1 - Permet l'établissement de connexions de bout en bout 1

2 - Offre à la couche supérieure Session la possibilité d'établir des sessions 1
3 - Ne permet pas la détection et la correction des erreurs lors des transferts de données 0
4 - Permet les échanges de données bidirectionnels particulièrement avec TCP 1
5 - D'échanger des données en ASCII uniquement 0
6 - Ne permet pas l'utilisation de protocoles de type datagramme tels que UDP par exemple 0

Question 26

L'(es) intérêt(s) du modèle client/serveur est (sont) :

1 - La mise en commun de procédures réutilisables basées sur la notion de version 1

2 - La gestion transactionnelle de l'accès aux données 1
3 - L'indépendance totale vis-à-vis des débits théoriques des réseaux sous-jacents 0
4 - La sécurité centralisée (identification et authentification) de l'accès aux données 1
5 - La gestion décentralisée des ressources réparties 0
6 - La centralisation des données sur des serveurs de type SGBD 1
Examen_FOD_NSY107N_30janvier2010_solutions.docx

Question 27

Parmi les fonctions du middleware, on trouve :

1 - Les procédures de connexion 1

2 - La préparation et l'envoi des requêtes vers le serveur 1
3 - La récupération du service applicatif du serveur 0
4 - La mise en cache des résultats sur le client 1
5 - La mise en cache des requêtes sur le serveur 1
6 - Les procédures de déconnexion 1

Question 28

Le middleware :

1 - Correspond à une entité logicielle 1

2 - Assure le dialogue entre des clients et des serveurs homogènes 0
3 - Correspond aux couches hautes de 4 à 7 0
4 - Ne peut pas convertir les types de données 0
5 - Permet difficilement les communications gros systèmes vers petits systèmes à cause de l'absence
de mise en cache des réponses 0
6 - Voit son efficacité diminuer lorsque que les débits nominaux des réseaux physiques augmentent 0

Question 29

Le standard CLI :

1 - Correspond à la normalisation d'une API pour les bases de données relationnelles distantes 1
2 - Ne correspond pas à la normalisation d'une API pour les systèmes transactionnels 1
3 - A été normalisé par l'IETF 0
4 - Est une API pour serveurs SQL 1
5 - Est une API pour serveurs d'annuaires électroniques 0
6 - Est à l'origine d'ODBC (Open DataBase Connection) développé par SUN 0

Question 30

Microsoft a fait le choix de remplacer la pile de protocoles NetBEUI par la pile de protocoles
TCP/IP :

1 - Pour ne pas développer une nouvelle pile de protocoles routables 1

2 - Parce que la pile de protocole NetBEUI n'était pas routable 1
3 - Il aurait pu faire le choix de IPX/SPX pour résoudre le problème du routage (hors contraintes d'un
système d'adressage mondial tel que celui de l'Internet) 1
4 - Pour remplacer NetBIOS 0
5 Pour pouvoir réutiliser NetBIOS sur une pile de protocoles routables 1
6 - Car c'est une solution adoptée par tous et gratuite en terme de droit d'exploitation 1
Examen_FOD_NSY107N_30janvier2010_solutions.docx

ANNEXE 1
Microsoft .Net Passport est fidèle aux principes de protection de votre confidentialité
®
Microsoft .Net Passport ("Passport") n'ignore pas que votre vie privée et la protection de vos
informations personnelles sont importantes à vos yeux. La présente Déclaration décrit comment nous
assurons la protection de vos informations personnelles chaque fois que vous vous connectez au site
Web de .Net Passport (www.Passport.com) et chaque fois que vous utilisez les services .Net Passport
sur des sites Web participants.
.Net Passport inclut les services suivants : Connexion .Net Passport, Portefeuille .Net Passport et .Net
Passport Achats exprès. En utilisant le site Web et les services de .Net Passport, vous acceptez les
pratiques décrites dans la présente Déclaration.

Sécurité et confidentialité

Quel est le niveau de sécurité de .NET Passport ?

.NET Passport assure un niveau de sécurité élevé sur le Web grâce à la mise en
oeuvre de technologies et de systèmes spécialement conçus pour interdire tout accès
non autorisé à vos informations personnelles. Voici, sommairement, comment .NET
Passport protège vos informations :

• Vous devez taper votre mot de passe .NET Passport pour vous connecter aux
sites participants ou pour accéder aux informations de votre profil .NET
Passport. .NET Passport ne révèle cependant jamais votre mot de passe aux
sites participants.

• .NET Passport fait appel à des technologies de sécurité standard de l'industrie

pour crypter votre mot de passe, votre adresse de messagerie ainsi que les
informations de votre portefeuille .NET Passport chaque fois que vous les
transmettez sur Internet.

• Dans le cas d'un achat exprès avec .NET Passport, vous ne pouvez accéder
à votre portefeuille .NET Passport que pendant quelques minutes seulement
avant de devoir retaper votre mot de passe.

• Après plusieurs tentatives de connexion infructueuses, .NET Passport bloque

momentanément toute autre tentative, pour empêcher quiconque de deviner
votre mot de passe à l'aide d'un programme de perçage de mot de passe.

• .NET Passport stocke des "cookies" (petits fichiers texte) sur votre ordinateur
pour vous permettre de vous connecter aux sites participants. Tous les
cookies .NET Passport sont cryptés et lorsque vous quittez .NET Passport, ils
sont supprimés de votre ordinateur.

Qu'en est-il de la confidentialité de mes informations ?

Microsoft s'engage à protéger la confidentialité des personnes qui utilisent .NET

Passport.

• Microsoft ne partage pas les informations personnelles de votre profil .NET

Passport avec d'autres sociétés sans votre consentement.

• Vous pouvez néanmoins autoriser Microsoft à partager les informations de

votre profil .NET Passport avec les sociétés qui détiennent les sites .NET
Passport participants auxquels vous vous connectez. Le partage de ces
informations permet d'accélérer votre inscription et de vous proposer des
Examen_FOD_NSY107N_30janvier2010_solutions.docx

services personnalisés. Vous pouvez indiquer les informations à partager

dans le formulaire d'inscription .NET Passport ou dans votre profil .NET
Passport, après l'inscription.

• Les sites qui proposent le service .NET Passport doivent publier leur propre
déclaration de confidentialité et des règles les obligent à spécifier de quelle
façon ils exploitent vos informations .NET Passport.

• Lorsque vous possédez un portefeuille .NET Passport, les informations qu'il

contient ne sont jamais partagées avec les sites participants au moment de la
connexion. Les données de votre portefeuille .NET Passport ne sont
partagées que lorsque vous sélectionnez les informations qui doivent être
transmises au fournisseur lors d'un achat exprès avec .NET Passport.

Pourquoi puis-je confier mes informations à Microsoft ?

Depuis plusieurs années, Microsoft est une des sociétés américaines les plus
estimées par le grand public.

En outre, depuis de nombreuses années, Microsoft défend les normes de

confidentialité sur Internet et les organismes qui oeuvrent dans ce domaine.

Récemment, Microsoft est devenu membre de la Conseil d'administration de

BBBOnLine et contribue activement au développement de l'Online Privacy Alliance,
une coalition qui regroupe plus de 80 entreprises et sociétés internationales qui a
pour objectif de promouvoir la confidentialité en ligne du consommateur. Microsoft
continue aussi à collaborer étroitement avec des associations privées et publiques de
défense du consommateur aux quatre coins du monde.
Examen_FOD_NSY107N_30janvier2010_solutions.docx

ANNEXE 2
SOA P ( Si m p l e Ob j e ct A cce ss Pr o t o co l )
Soap est le protocole de communications des XML Web Services. Lorsque l'on parle de SOAP
comme d'un protocole de communications, la plupart des gens pensent à DCOM ou à CORBA et se
mettent à se poser des questions du type « Comment SOAP réalise-t-il l'activation d'un objet ? » ou
encore « Quel est le service de nom utilisé par SOAP ? ». Si une implémentation de SOAP doit
vraisemblablement s'intéresser à ce genre de choses, la norme SOAP ne les spécifie pas. SOAP est
une spécification qui définit le format XML des messages (et c'est tout, pour ce qui est des parties
obligatoires de la spécification). Si un fragment XML bien formaté se trouve intégré à des éléments
SOAP, vous avez un message SOAP. C'est simple, n'est-ce pas ?
Il existe d'autres parties de la spécification SOAP qui décrivent comment représenter les données d'un
programme en XML et comment utiliser SOAP pour effectuer des appels de procédure distante
(RPC). Ces aspects facultatifs de la spécification servent à implémenter les applications de style RPC
dans lesquelles un message SOAP contenant une fonction pouvant être appelée (ainsi que les
paramètres à transmettre à cette fonction) sont envoyés par le client, et que le serveur renvoit un
message contenant les résultats de la fonction exécutée. La plupart des implémentations courantes
de SOAP prennent en charge les applications RPC car les programmeurs qui ont l'habitude des
applications COM ou CORBA comprennent le style RPC. SOAP prend également en charge les
applications de style document dans lesquelles le message SOAP n'est qu'un wrapper autour d'un
document XML. Les applications SOAP de style de document sont très souples et nombreux sont les
nouveaux XML Web Services qui tirent profit de cette souplesse pour créer des services qu'il serait
difficile de mettre en œuvre avec RPC.
La dernière partie facultative de la spécification SOAP définit l'aspect d'un message HTTP contenant
un message SOAP. Cette liaison HTTP est importante car HTTP est pris en charge par presque tous
les systèmes d'exploitation courants (ainsi que par de nombreux systèmes d'exploitation moins
courants). La liaison HTTP est facultative, mais presque toutes les implémentations SOAP la prennent
en charge car c'est le seul protocole standardisé pour SOAP. C'est la raison pour laquelle il existe une
idée fausse selon laquelle SOAP nécessite HTTP. Certaines implémentations prennent en charge les
transports MSMQ, MQ Series, SMTP ou TCP/IP, mais la plupart des XML Web Services actuels
utilisent HTTP parce qu'il est très répandu. HTTP étant l'un des principaux protocoles du Web, la
plupart des entreprises sont dotées d'une infrastructure réseau qui prend en charge HTTP et ont le
personnel qui en comprend la gestion. Les infrastructures de sécurité, de surveillance et d'équilibrage
de la charge pour HTTP sont déjà disponibles aujourd'hui.
L'une des sources majeures de confusion lors du démarrage avec SOAP est la différence qui existe
entre la spécification SOAP et ses nombreuses implémentations. La plupart des gens qui utilisent
SOAP n'écrivent pas les messages SOAP directement mais utilisent une boîte à outils SOAP pour
créer et analyser les messages SOAP. Ces boîtes à outils traduisent généralement les appels de
fonction depuis un langage donné en un message SOAP. Par exemple, Microsoft SOAP Toolkit 2.0
traduit les appels de fonction COM vers SOAP et Apache Toolkit traduit les appels de fonction JAVA
vers SOAP. Les types d'appels de fonction et les types de données des paramètres pris en charge
varient en fonction de chaque implémentation SOAP, de sorte qu'une fonction qui fonctionne avec une
boîte à outils peut ne pas fonctionner avec une autre. Il ne s'agit pas d'une limitation de SOAP mais
plutôt de l'implémentation particulière que vous utilisez.
SOAP possède une fonction qui est de loin la plus extraordinaire : il est pris en charge par des plates-
formes matérielles et logicielles différentes. Cela signifie que SOAP peut être utilisé pour relier des
systèmes séparés au sein et en dehors de votre entreprise. De nombreuses tentatives ont été faites
par le passé pour trouver un protocole de communications commun qui pourrait servir à l'intégration
des systèmes, mais aucun d'eux n'a été aussi répandu que SOAP. Pourquoi cela ? Parce que SOAP
est beaucoup plus petit et beaucoup plus simple à implémenter que beaucoup des protocoles
précédents. DCE et CORBA, par exemple, demandaient des années à implémenter, c'est pourquoi
seules quelques implémentations ont été réalisées. En revanche, SOAP peut utiliser des
bibliothèques HTTP et des parseurs XML existants pour exécuter les tâches les plus lourdes, de sorte
qu'une implémentation SOAP peut être terminée en quelques mois. C'est pourquoi il existe aujourd'hui
plus de 70 implémentations SOAP. Il est évident que SOAP ne fait pas tout ce que font DCE ou
CORBA, mais c'est la simplicité des échanges de fonctions qui rend SOAP si facilement utilisable.
Examen_FOD_NSY107N_30janvier2010_solutions.docx

ANNEXE 3

SOAP est un protocole de transmission de messages. Il définit un ensemble de règles pour structurer
des messages qui peuvent être utilisés dans de simples transmissions unidirectionnelles, mais il est
particulièrement utile pour exécuter des dialogues requête-réponse RPC (Remote Procedure Call). Il
n'est pas lié à un protocole particulier mais HTTP est populaire. Il n'est pas non plus lié à un système
d'exploitation ni à un langage de programmation, donc, théoriquement, les clients et serveurs de ces
dialogues peuvent tourner sur n'importe quelle plate-forme et être écrits dans n'importe quel langage
du moment qu'ils puissent formuler et comprendre des messages SOAP. En tant que tel, il s'agit d'un
important composant de base pour développer des applications distribuées qui exploitent des
fonctionnalités publiées comme services par des intranets ou internet.

Prenons un exemple. Imaginez que vous ayez la base de données très simple d'une entreprise,
comprenant une table spécifiant le numéro de référence, le nom et le numéro de téléphone des
employés. Vous voulez offrir un service qui permet à d'autres systèmes de votre compagnie de
consulter ces données. Le service retourne un nom et un numéro de téléphone (un tableau de
chaînes de caractères à deux éléments) pour un numéro de référence d'employé donné (un entier).
Voici un prototype Java de ce service:

String[] getEmployeeDetails ( int employeeNumber );

Face à ce genre de problème, l'approche du développeur SOAP est d'encapsuler la logique de

requête de la base de données, destinée à ce service, dans une méthode (ou fonction) en C ou VB ou
Java etc. et ensuite, de démarrer un process qui écoute les requêtes adressées à ce service (un
process listener), ces requêtes étant formulées dans un format SOAP et contenant le nom du service
et les paramètres requis. Comme mentionné, la couche transport peut être HTTP mais pourrait tout
aussi bien être SMTP ou autre chose. Puis, le listener, typiquement écrit dans le même langage que la
méthode du service pour plus de simplicité, décode la requête SOAP entrante et la transforme en un
appel de la méthode. Il récupère le résultat de l'appel de la méthode, l'encode dans un message
SOAP (la réponse) et le renvoie au demandeur. Conceptuellement, cela donne:

ANNEXE 4

Distributed Directories as Collaborative Enablers: Distributed directory infrastructures, such as UDDI

(Universal Description, Discovery and Integration), will provide services through which companies and
communities can assert their existence, describe the products and services they offer, and document
the XML-based object interfaces they provide - so that others can interact with their internal business
processes. Operating in a fashion similar to that of the Domain Name System, public and private
"metadata directories" will be hosted at every level within the Web, from servers at the core of the
network, through directory service providers, to corporate servers, and ultimately, on individually
connected devices. These distributed directories will become a primary resource for identifying and
connecting with potential collaborative partners.
Examen_FOD_NSY107N_30janvier2010_solutions.docx

ANNEXE 5

This Certificate belongs to:

Olivier GROSJEANNE
job@phenix-informatique.fr
Digital ID Class 1 - Netscape
Persona Not Validated
www.verisign.com/repository/RPA Incorp.
by Ref.,LIAB.LTD(c)98
VeriSign Trust Network
VeriSign, Inc.
This Certificate was issued by:
VeriSign Class 1 CA Individual
Subscriber-Persona Not Validated
www.verisign.com/repository/RPA Incorp.
By Ref.,LIAB.LTD(c)98
VeriSign Trust Network
VeriSign, Inc.

ANNEXE 6

La solution XXXX
En e-business, il est essentiel de disposer d'un logiciel serveur d'applications capable non seulement
de gérer les échanges interapplicatifs entre différentes plates-formes, mais aussi de contribuer
activement à leur intégration. XXXX permet de relier des applications qu'il serait sinon difficile de faire
interagir. Son système de messagerie prend en charge la diversité de vos réseaux et de vos services,
même pour les programmes que vous avez développés en interne.
XXXX vous assure ainsi une migration harmonieuse. Mais ce n'est pas tout : il peut également
optimiser la réactivité et les coûts d'une chaîne logistique ; faciliter et accélérer la mise en œuvre de
progiciels ; et intégrer vos systèmes de gestion avec Internet. XXXX est déjà compatible avec
Windows 2000 - et avec 35 autres plates-formes.
La Prudential Insurance Company of America est l'une des nombreuses entreprises qui ont choisi
XXXX. Cette compagnie d'assurance devait intégrer les informations et les services fournis par ses
systèmes commerciaux avec l'environnement d'informatique distribué qu'elle était en train d'installer,
et avec les systèmes en place, sur grand système. Elle voulait également avoir la possibilité de
compléter son infrastructure par l'adjonction rapide d'autres systèmes, de manière à offrir en
permanence un service clients ultra-performant.
Carl Thune, Directeur des technologies de l'information de l'entreprise, présente en ces termes les
résultats obtenus : "L'évolutivité, les performances, la haute disponibilité et une certaine simplification
du développement sont des avantages décisifs. XXXX est un produit très facile à utiliser pour les
développeurs. Et nous prévoyons de généraliser prochainement son exploitation : nous pourrons
bientôt employer sa messagerie interapplicative pour un certain nombre d'applications disparates.
Nous n'avons plus besoin de refaire les interfaces de communication au cas par cas, ce qui
représente une économie majeure dans nos activités de développement."
"XXXX, poursuit-il, simplifie considérablement l'élaboration d'applications capables d'intégrer des
informations issues de différentes sources - ce qui est probablement l'une des principales difficultés
auxquelles nous soyons confrontés aujourd'hui. Grâce à XXXX, nous pouvons consolider des
informations qui étaient jusque-là stockées et gérées par différents services de l'entreprise, sous des
formats différents et à des fins différentes. Aujourd'hui, nous travaillons d'une manière qui répond aux
attentes des clients, grâce à une unification et une intégration complètes de l'information."
Examen_FOD_NSY107N_30janvier2010_solutions.docx

ANNEXE 7
Proposition 1 :

PersonnelRecord ::= [APPLICATION 0] SET

{ name Name,
title VisibleString,
number EmployeeNumber,
dateOfHire Date,
nameOfSpouse Name,
children SEQUENCE OF ChildInformation DEFAULT {} }
ChildInformation ::= SET
{ name Name,
dateOfBirth Date }
Name ::= [APPLICATION 1] SEQUENCE
{ givenName VisibleString,
initial VisibleString,
familyName VisibleString }
EmployeeNumber ::= [APPLICATION 2] INTEGER
Date ::= [APPLICATION 3] VisibleString -- YYYY MMDD

Proposition 2 :

struct data {
unsigned int arg1;
unsigned int arg2;
};
typedef struct data data;
struct reponse {
unsigned int somme;
int errno;
};
typedef struct reponse reponse;
program CALCUL{
version VERSION_001{
void CALCUL_NULL(void) = 0;
reponse CALCUL_ADDITION(data) = 1;
} = 1;
} = 0x20000001;

Proposition 3 :

<xml id="xmlid">
<xmldata>
<data>text</data>
</xmldata>
</xml>
<script id="xmlid" TYPE="text/xml">
<xmldata>
<data>text</data>
</xmldata>
</script>