Conseils SOA - Résoudre les goulots d'étranglement d'évolutivité avec la mise en cache distribuée

Par Iqbal Khan

Après l'explosion des applications Web pour s'adapter à une utilisation à fort trafic, la prochaine grande vague est devenue l'architecture orientée services (SOA). La SOA est destinée à devenir un moyen standard pour développer des applications extrêmement évolutives, et les plates-formes de cloud computing telles que Windows Azure représentent un pas de géant dans l'évolution de la SOA vers la réalisation de cet objectif.

La SOA permet aux utilisateurs de distribuer des applications sur plusieurs sites, plusieurs services au sein d'une organisation et plusieurs entreprises sur Internet. De plus, il permet la réutilisation du code existant au sein d'une organisation et, plus important encore, la collaboration entre différentes unités commerciales.

Une application SOA est généralement déployée dans une batterie de serveurs dans un environnement à charge équilibrée. L'objectif est de permettre à l'application de gérer autant de charge que vous lui lancez. La question devient alors : quelles sont les considérations à prendre en compte pour améliorer à la fois les performances et l'évolutivité de votre application SOA ?

Bien que la SOA, de par sa conception, soit destinée à fournir une évolutivité, il existe de nombreux problèmes que vous devez résoudre avant de pouvoir réellement atteindre l'évolutivité. Certains de ces problèmes concernent la façon dont vous codez votre application SOA, mais les goulots d'étranglement les plus importants sont souvent liés à la façon dont vous stockez et accédez à vos données. Je vais explorer ces problèmes et proposer des solutions dans cet article.

Trouver les goulots d'étranglement en matière d'évolutivité

Une véritable application SOA doit évoluer facilement en ce qui concerne l'architecture de l'application. Une application SOA comporte deux composants : les composants de service et les applications client. L'application client peut être une application Web, un autre service ou toute autre application qui s'appuie sur les composants du service SOA pour faire son travail.

L'une des idées clés de la SOA est de diviser l'application en petits morceaux afin que ces composants puissent être exécutés sur plusieurs serveurs en tant que services distincts.

Idéalement, ces services devraient être apatrides autant que possible. Apatride signifie qu'ils ne conservent aucune donnée sur plusieurs appels, ce qui vous permet d'exécuter les services sur plusieurs ordinateurs. Il n'y a aucune dépendance quant à l'endroit où se trouvaient les données la dernière fois, donc aucune donnée n'est conservée sur un serveur particulier lors de plusieurs appels de service.