Quand vous développez une application en Java (ou autre) en entreprise, il est rare que vous commenciez dans un système vierge à partir d'une page blanche et encore plus que vous soyez le seul à travailler dessus.
Vous arrivez donc en général dans un système composé de dizaines voire de centaines d'applications, qui s'envoient des messages, communiquent et qui peuvent se trouver dans des serveurs locaux, dans des serveurs distant ou dans le cloud. Elles sont aussi écrites dans divers langages : Java, C#, C++, Python ou pire encore COBOL et autres hiéroglyphes. :p
Se posent alors plusieurs problèmes :
Dans le SI (système d'information) d'une entreprise, chaque application peut avoir son propre protocole de communication, ses propres formats de messages, etc. Se pose alors la question de comment créer votre application de façon à ce qu'elle communique parfaitement avec les autres ? Ou encore mieux, comment concevoir toutes les applications du SI dès le départ pour qu'elles communiquent toutes via un protocole et un format standard et compris de tous ?
Comment éviter de réinventer le roue : savoir si certaines fonctionnalités existent déjà dans d'autres applications ou chercher la possibilité de réutiliser certains composant afin d'éviter la redondance.
Comment savoir à quelle URL ou IP se situe telle ou telle application avec laquelle vous voulez communiquer ? Pire encore, que se passe-t-il si cette application change d'URL ?
Ce sont des exemples parmi d'autres de problèmes auxquels les développeurs étaient confrontés avant le développement de l'architecture orientée services (SOA).
Vous allez voir dans ce cours comment les entreprises organisent leurs SI afin que toutes les applications communiquent très facilement via un protocole unique appelé SOAP, se mettent à jour sans interruption de service et redeviennent à taille humaine grâce à un découpage de l'ensemble en petites applications appelées services.
Vous allez ensuite apprendre à découper une application en services, puis vous apprendrez à créer et tester ces services dans le respect des principes de la SOA.
Le but ici n'est pas que vous soyez capables de créer une architecture SOA à vous seuls (seul Chuck Norris peut le faire), mais plutôt que vous sachiez créer des services qui s'intègrent dans une SOA existante. C'est ce qui vous sera la plupart du temps demandé quand vous intégrerez une entreprise dont le SI est basé sur cette architecture. C'est parti !
