Un service est le plus petit élément du web 2.0. Son rôle, son périmètre fonctionnel, et les technologies utilisées pour le créer sont très variables. Ce peut être un système de fichiers distribué complet, comme S3 d'Amazon, accessible depuis une API minimaliste, un simple traitement de flux RSS, tel Yahoo Pipes, une liste de photos ou de favoris, comme celles de Flickr et de Del.icio.us, un fichier XML exposant des données métier, une carte comme Google Maps...

Malgré cette diversité, ces services ont en commun quelques caractéristiques techniques. Ils sont neutres sur le plan technologique, car ils reposent sur des protocoles de services ouverts. Ils sont exposés via une interface de programmation (API) sans état. Enfin, un service peut être appelé depuis une simple URL, et le résultat de l'appel est un message structuré au format texte, JSON, XML, RSS, Atom, etc.

Grâce à ces caractéristiques communes, le web 2.0 devient un gigantesque catalogue de composants techniques et métier, dont les API XML remplacent les DLL. « La disponibilité publique de ces API encourage les développeurs à les combiner pour créer de nouveaux services et des interfaces utilisateurs plus riches » , constate Jeff Whatcott, directeur entreprise et développeurs chez Adobe. Ainsi le site Seloger.com combine-t-il Google Maps et ses propres API pour afficher en temps réel les annonces disponibles à mesure que l'internaute se déplace et zoome sur une carte interactive de la France.

Pour créer ce type d'application composite (ou mash up en anglais), deux architectures sont possibles. « On peut assembler différents services directement côté client ou passer par un serveur intermédiaire afin de réaliser des enrichissements et des transformations » , détaille Sami Jaber, directeur technique de Valtech Toulouse. Dans les faits, les services sont souvent combinés en temps réel à la fois côté serveur et dans le navigateur. Grâce au mécanisme d'échange (notamment Ajax), chaque composant graphique interagit avec les services sous-jacents indépendamment des autres composants. Les échanges avec le serveur sont donc éclatés et de faible granularité. Une partie des traitements métier sont cependant déportés dans le navigateur afin de supporter le mode déconnecté.

De nombreux éditeurs proposent des kits de développement pour faciliter la création des applications composites. C'est notamment le cas des frameworks Rich Internet Application (RIA). Basés sur DHTML et Ajax, ils se déploient dans un navigateur standard. Grâce aux propositions de standards du groupe de travail WhatWG, le client (composants techniques et graphiques, traitements, etc.) peut résider dans le cache du navigateur. A l'instar du Google Web Toolkit, les éditeurs proposent déjà des environnements de développement intégrés RAD Wysiwyg, qui compilent un langage intermédiaire (Java dans le cas de Google) en DHTML. Il est donc aussi facile de développer un RIA qu'une application client-serveur en Visual Basic. Les entreprises peuvent ainsi « réduire la durée et le coût de leurs projets, mais aussi économiser en coût de déploiement » , note Jérémy Chatard, directeur de la SSII Breek.

Les technologies RIA doivent cependant compter avec la concurrence des Rich Desktop Application (RDA), tels Apollo d'Adobe, Eclipse RCP, de la fondation Eclipse, ou WPF, de Microsoft. Ces socles de développement et d'exécution propriétaires s'appuient sur la même architecture que les RIA, mais ils nécessitent le déploiement d'un moteur d'exécution propriétaire sur le poste de travail. En contrepartie, ils apportent d'autres avantages, comme l'optimisation des échanges entre les clients et les services sous-jacents, et l'intégration aux applications locales.