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 de transport 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. Il s'agit donc 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 une 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 processus 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:

Alors que de nombreuses architectures spécifiques différentes sont possibles pour implémenter cet arrangement, afin d'illustrer le propos, nous n'allons résumer qu'une seule possibilité spécifique.

Admettons que la base de données soit Oracle. Le développeur écrit la méthode du service en Java et se connecte à la base de données via une implémentation Oracle de JDBC. Le process listener est un Servlet Java tournant dans un moteur de servlet comme Tomcat. Le servlet a accès à des classes Java capables d'encoder et de décoder des messages SOAP (tel que Apache SOAP for Java) et écoute ces messages en tant que HTTP POST. Le protocole de transport est HTTP par TCP/IP. Le client est un tableau excel. Il utilise une macro VB qui, à son tour, exploite le Toolkit Microsoft SOAP pour encoder une requête SOAP et décoder la réponse reçue. Voici ce à quoi ressemble cette implémentation spécifique:

Notez que du côté client, la macro VB repose sur le Toolkit Microsoft SOAP (les DLL's SOAP) et une interface HTTP Connector. De tels DLLs HTTP Connector sont typiquement déjà installés en tant que composant d'Internet Explorer. Du côté serveur, vous noterez que le package SOAP repose sur un Parser XML qui analyse les messages SOAP. Dans le cas d'Apache SOAP pour Java, ce sera Xerces.

Il existe bien sûr d'autres façons de construire un même service sans utiliser SOAP. Une façon évidente est d'autoriser votre client à avoir un accès direct à une procédure stockée dans la base de données via ODBC ou JDBC. Voici quelques raisons pour lesquelles vous voudriez choisir plutôt une solution basée sur SOAP:

1. Avec une solution de type procédure stockée, vous ne pourrez pas envoyer ou recevoir des structures de données complexes comme paramètre ou valeur de retour. Ceci est dû à la nature des appels de procédures des bases de données relationnelles. Les paramètres de tels appels sont limités à une liste de valeurs de type primitif (entiers, flottants, chaînes de caractères etc...). De même pour les données retournées. Dans notre exemple simplifié de numéros de téléphone d'entreprise, ce n'est pas un problème. Nous envoyons un numéro d'employé (un entier) et recevons un nom et un numéro de téléphone (une paire de chaînes de caractères). Mais que se passe t-il si votre service doit fournir le numéro de téléphone usuel de l' employé, plus une liste d'autres numéros de téléphone valides pendant certaines périodes? Ce serait le cas si votre base de données suivait les modifications de numéros de téléphone des employés lorsqu'ils partent en voyages d'affaires. Maintenant, votre service doit retourner un type complexe de la forme:

   EmployeeContactDetail {
        String employeeName;
        String phoneNumber;
        TemporaryPhoneNumber[] tempPhoneNumber;
   }
   

   Où le type TemporaryPhoneNumber défini par l'utilisateur est défini comme suit:

   TemporaryPhoneNumber {
        int startDate; //julian date
        int endDate;   //julian date
        String phoneNumber;
   }
   

   Notez que le nombre d'enregistrements de numéros de téléphone temporaires de l'employé en question n'est pas limité. Le prototype de votre service ressemble maintenant à:

   EmployeeContactDetail getEmployeeDetails ( int employeeNumber );
   

   Une approche ODBC ou JDBC vous oblige à mettre à plat les structures complexes de données. Mais dans notre cas, c'est impossible car le nombre d'enregistrements TemporaryPhoneNumber est inconnu. Le protocole SOAP est, lui, suffisamment puissant pour vous permettre d'encoder des structures de données de tous niveaux de complexité.
   
   
2. Il se peut que vous ayez une architecture n-tiers dans laquelle votre logique métier est codée hors de la base de données et les services que vous voulez écrire ont besoin d'un accès à cette logique métier. Avec une solution de type procédure stockée, vos choix sont limités à réécrire cette logique en SQL (Toujours une proposition peu attrayante et, pas toujours possible, en fonction de l'exigence de précision dans les calculs de la logique métier) ou à créer une solution de type openserver dans laquelle la procédure stockée sous-traite les calculs à un moteur de calcul qui incorpore votre code métier. C'est un gros travail mais peut-être un bon choix si votre logique métier n'est pas écrite en Java. Si elle est écrite en Java, alors, tout ce que vous avez besoin de faire (en terme de concept) avec la solution SOAP est d'inclure la logique métier comme un Jar entre le Jar Service Method et le Jar JDBC dans le diagramme ci-dessus. Il est important de noter que ce n'est pas SOAP qui vous permet de faire ceci mais le fait que nous utilisons un moteur de servlet. Il n' y a rien qui nous empêche d'écrire un servlet pour encapsuler notre logique métier, qui, à son tour s'occupera de l'accès à la base de donnée et des calculs. Alors, pourquoi impliquer SOAP dans ce cas? Le fait que sans SOAP, vous avez le choix de 1) construire un servlet par service ou 2) créer un servlet générique mais il faut inventer vos propres méthodes d'identification et de schéma d'encodage des paramètres. SOAP a, d'autre part, non seulement toutes les méthodes d'identification et d'encodage des paramètres déjà élaborées pour vous mais en plus, le protocole est standard W3C, donc vos clients n'auront pas besoin d'apprendre votre protocole personnel. C'est important lorsqu'on pense à offrir des services sur internet.
   
   
3. JDBC n'est valide que pour des clients java. Si vous avez un mélange de client Java et non Java, vous aurez une méthode d'accès à vos services inconsistante. Vous pouvez même avoir plus d'une base de données en back end (et ces bases de données peuvent être de types différents). Or, vous voulez isoler le client de cette structure. Une fois de plus, une solution uniquement servlet (sans utiliser SOAP) vous permet de contourner ces obstacles mais sera moins attrayante qu'une solution basée sur SOAP pour les raisons énoncées ci-dessus.
   
   

OK, et CORBA alors? Il est vrai que CORBA va adresser tous ces sujets. Vous pouvez avoir des types complexes de données, clients et serveurs peuvent employer n'importe quel mélange de langages et de plates-formes, vous pouvez réutiliser la couche métier de votre architecture n-tiers et vous pouvez isoler le client des détails architecturaux du back-end. Alors pourquoi devrions nous introduire SOAP? Voici quelques raisons:

1. CORBA exige de compiler et distribuer des stubs client pour chaque type de clients que vous avez. Ce n'est pas toujours pratique, particulièrement quand vous avez un grand nombre de combinaisons de plates-formes et de langages ou quand vous voulez offrir des services à des clients anonymes au travers d'internet.
   
   
2. Si vous développez des Web Services (voir plus bas) alors IIOP (le protocole de transfert de CORBA) n'est pas particulièrement convivial avec les pare-feux. Donc si vous voulez offrir des services à des clients au travers d'internet et bien que ce ne soit pas impossible avec CORBA, vous allez devoir surmonter des obstacles liés aux pare-feux.