Dans une approche idéale du projet, les technologies utilisées, ici les web services et les API J2ME, auraient été en principe pleinement maîtrisées au commencement du projet, et le développement de ce dernier aurait constitué une mise en œuvre de ces technologies.
La réalité de ce projet fut différente. Pour des raisons personnelles, la priorité fut donnée au commencement effectif du projet, même si les connaissances nécessaires à sa réalisation n’étaient pas pleinement acquises et assimilées. Un part non négligeable du temps consacré, le fut donc à compenser ces lacunes. Ce choix est pleinement assumé et explique l’approche purement pragmatique des sections suivantes chargées de décrire les technologies utilisées et qui n’auront donc pas la prétention d’être théoriquement exhaustives mais qui présenteront les notions que nous avons dû éclaircir pour mener à bien le projet.
Le choix du langage Java est en fait une évidence. Bien sûr parce que ce fut le langage de base de la formation que parachève le présent projet de diplôme. Mais aussi comme conséquence naturelle d’une affinité qui s’est peu à peu instaurée avec l’univers Sun.
La définition que donne le W3C des web services serait presque suffisante en rapport niveau de compréhension dont nous aurons besoin dans le cadre de ce projet :
A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.
Soit dans une paraphrase en français:
Un Web service est une application logicielle permettant l’interaction de deux machines distantes via un réseau. Elle possède une interface décrite par un document au format spécifique, le WSDL, pouvant être traitée numériquement. D’autres systèmes pourront interagir avec le service web conformément à cette description par l’échange de messages SOAP, habituellement via http, les informations contenues dans le message étant sérialisée au format XML.
Au cours de ce projet nous prendrons successivement la casquette du développeur souhaitant mettre en œuvre un web service et le rendre disponible au plus grand nombre – c’est le coté fournisseur de WS - puis par la suite le « sombrero» du développeur qui souhaite dans le cadre de son application personnelle utiliser des informations fournies par un WS – c’est le coté consommateur.
Les deux extrémités de la chaîne des web services sont à priori totalement indépendantes, tant au niveau des objectifs recherchés, que des plateformes de développement, des langages de programmation utilisés et des autres options technologiques choisies. De plus, le fournisseur ne souhaite bien évidemment pas restreindre son offre à un certain type de client, technologiquement parlant.
En d’autres termes :
Le fournisseur de service développe dans l’environnement de son choix et dans le langage de programmation de son choix, selon ses options technologiques propres, une application qui fournira les informations qu’il souhaite rendre accessible au reste du monde.
Le consommateur, quant à lui, cherche à développer une application informatique qui, à un niveau ou à un autre, nécessite les informations mises à disposition par le fournisseur. De nouveau, cette application est développée selon les contraintes propres à ce client (plateforme, langage, options technologiques particulières), qui sont à priori totalement indépendantes de celles qui prévalent coté fournisseur.
Comment rendre l’échange entre ces deux systèmes hétéroclites possible, et autant que faire se peut, relativement transparent ?
La réponse en deux mots : Web Service (WS).
En quelques mots supplémentaires (mais pas trop), essayons de préciser de quoi il retourne.
