1. Introduction
Aujourd'hui, chaque entreprise cherche des moyens d'améliorer son efficacité de production et explore également activement la réorganisation de ses actifs informatiques. Les organisations informatiques ont fait des progrès pour surmonter ces problèmes grâce aux technologies d'architecture orientée services (SOA). Cependant, dans la plupart des cas, seule une petite partie de l'ensemble du portefeuille de services informatiques est mise en œuvre. Actuellement, la plupart des efforts dans ce domaine visent simplement à atteindre un niveau « juste suffisant » d'adoption de la SOA, en améliorant la capacité de créer des applications et de les intégrer au marché plus rapidement, mieux et à moindre coût. Et comme nous l’avons appris, atteindre ces objectifs est plus facile à dire qu’à faire.
2. Applications composites traditionnelles basées sur un middleware
Le fait est que la SOA est une sorte de middleware - et dans les cas traditionnels, le middleware s'appuie souvent sur davantage de middleware pour traduire les données dans un état convivial. Lorsque vous comprenez enfin que la création d'une application composite intégrant la technologie SOA nécessite non seulement l'utilisation d'un portail (middleware) mais peut également nécessiter l'utilisation d'un moteur BPEL (ou même middleware) pour l'orchestrer, cela vous rend bien sûr très déçu. Pire encore, vous pourriez travailler au sein d'une organisation qui publie des registres UDDI et enregistre de nombreux services Web. Malheureusement, dans la plupart des cas, très peu d’applications consomment réellement ces services. Comment cela pourrait-il être le cas ?
L’incapacité à créer des applications qui consomment ces services SOA devrait-elle nous amener à conclure que quelque chose ne va pas ? Est-ce parce qu’il est trop difficile pour les développeurs de contenu métier de créer des applications qui consomment directement les services SOA ? de s'appuyer sur d'autres organisations informatiques pour créer de telles applications pour nous ? L'absence d'une structure de gouvernance SOA nous retient-elle ? Je pense que la réponse à toutes ces questions est « oui ». Et il y a une raison très importante : il est trop difficile pour les seuls développeurs commerciaux de consommer et d'utiliser de tels services SOA exposés par l'organisation informatique. En fait, le vrai problème est le manque d'un moyen simple d'ajouter une interface SOA - et ! c'est l'avantage de combiner la technologie AJAX avec SOA.
Généralement, un service SOA est implémenté sous la forme d'un service Web faiblement couplé qui encapsule et expose les fonctionnalités métier. Cela peut paraître très simple, mais c’est très complexe et difficile à mettre en œuvre. Les développeurs débattent souvent de la granularité du développement des services SOA ; cependant, la plupart des développeurs conviennent désormais que la granularité du développement « au niveau métier » est la plus appropriée. Cependant, cela nécessite encore qu'un grand nombre d'experts du domaine concerné se joignent et travaillent avec du contenu commercial pour finaliser la taille de ces services.
3. La renaissance de la SOA
Heureusement, les gens se sont récemment montrés profondément intéressés par la SOA. Peut-être que les entreprises réalisent enfin que la SOA peut les aider énormément. Cela est peut-être dû à de meilleurs outils de développement et services Web promus par Amazon, Yahoo et eBay. C'est peut-être AJAX ? Oui, c'est pourquoi j'écris cet article. Sérieusement, je pense qu'AJAX est devenu un moteur important dans le renouvellement de la compréhension de la SOA, en particulier dans les domaines d'application hybrides actuels de diverses nouvelles technologies. Cependant, comment ces deux technologies très différentes devraient-elles être combinées et connectées pour libérer plus de puissance ? Examinons d'abord la définition de la technologie AJAX actuelle donnée par Wikipédia. Les pages Web sont impliquées, mais SOA n'est pas du tout mentionné. La description est la suivante :
"AJAX, qui signifie 'Asynchronous JavaScript+XML', est une technologie de développement Web permettant de créer des applications Web interactives. Son objectif est de faciliter la page Web frontale en échangeant une petite quantité de données avec le serveur. en arrière-plan. Il semble plus réactif ; par conséquent, chaque fois qu'un utilisateur effectue une modification, la page Web entière n'a pas besoin d'être rechargée. Le but ultime est d'améliorer encore l'interactivité, la réactivité et la convivialité de la page Web.
SOA n'est pas mentionné dans cette définition, ce qui n'est pas surprenant puisque les premières applications AJAX se concentraient sur l'amélioration de la fonctionnalité et de la convivialité des pages. Cela a été prouvé dans de nombreuses applications telles que Google Maps, Flickr et Yahoo Mail. Cependant, ce ne sont pas ces applications destinées aux consommateurs qui m'enthousiasment quant au potentiel d'AJAX, ce sont les applications métier exécutées derrière le pare-feu d'une entreprise qui tirent vraiment parti des avantages d'AJAX, car elles nous montrent deux caractéristiques clés : L'une est un client. -le modèle de programmation côté et l'autre est une implémentation simple d'appels asynchrones au serveur. Ces deux fonctionnalités clés – la possibilité d'appliquer une logique sur le client (navigateur) et la possibilité d'accéder aux données du serveur sans interrompre la page Web – ouvrent la porte à la création de nouvelles applications d'entreprise Web 2.0 plus riches, au nombre de domaines d'application possibles du programme. .
Plus tôt, j'ai mentionné que SOA n'avait pas d'interface. C'est là qu'AJAX entre en jeu : il ajoute une apparence décente à SOA. Ici, permettez-moi de vous expliquer un peu plus. Autant réfléchir à ce qui se passerait si les services SOA apparaissaient en ligne ? De tels services doivent généralement être enregistrés dans un registre ou un entrepôt (si nous avons de la chance) et peuvent ensuite être utilisés pour la consommation. Par exemple, jetons un coup d'œil à ce qui est disponible sur le site Web StrikeIron ( www.StrikeIron.com ). StrikeIron a créé avec succès un « marché de services Web » destiné au grand public. À première vue, le mécanisme de répertoire de StrikeIron ressemble beaucoup à une liste fournie dans une application pour petite entreprise. Mais plus tard, vous vous rendrez compte qu’il ne s’agit pas uniquement d’applications : ce sont en réalité des services Web. Le concept d'une entreprise unique fournissant des services Web WSDL/REST à un large éventail de consommateurs a de nombreuses implications. Mais pour l’instant, jetons un coup d’œil à ce que vend cette entreprise. Selon les informations fournies par StrikeIron (qui donne accès à ces services), les services Web les plus populaires qu'il propose comprennent :
· Vérification d'adresse aux États-Unis
· Service SMS mondial
· Taxes de vente et d'utilisation
· Vérification des e-mails
· Recherche inversée de téléphone
Rien Sans aucun doute, tous ces services Web sont très utiles et peuvent être utilisés dans de nombreux domaines différents. Mais en même temps, ils sont trop « marchandises ». En d’autres termes, je ne me soucie peut-être pas de savoir qui fournit ces services, mais je souhaite simplement obtenir les informations que je souhaite. D'un autre côté, est-ce que j'utiliserais simplement n'importe quel service Web pour transférer de l'argent de mon compte courant vers mon compte d'épargne, je ne le ferais pas ? Je dois d’abord établir la confiance dans ce service, je dois donc établir une certaine relation avec le fournisseur qui le fournit. Ce « cercle de confiance » qui existe entre moi (le consommateur) et le prestataire représente également la relation au sein de l'entreprise et de ses partenaires.
4. Combiner la technologie AJAX + SOA
La même méthode ci-dessus peut également être adoptée par les entreprises pour fournir leurs services Web à une base d'utilisateurs plus large. Grâce à un marché de services Web, les entreprises peuvent enregistrer divers services Web, et ces services Web ne sont généralement disponibles qu'au sein de l'entreprise ou auprès de partenaires. Les fournisseurs du marché souhaitent évidemment que cela se produise, mais plus important encore, nous voyons une opportunité d'appliquer la technologie AJAX+SOA pour piloter une nouvelle classe d'applications métier Web 2.0.
Pour la première fois, les gens ont commencé à sentir que le développement d'applications et la SOA allaient enfin de pair. Nous avons des fonctionnalités métier décrites sous une forme réutilisable - un service SOA. Nous disposons d’une connectivité omniprésente : le Web. Nous avons des navigateurs qui s'avèrent être les nouveaux conteneurs d'applications. Nous avons un modèle de programmation dans ce type de conteneur/navigateur d'application - JavaScript. Et ils utilisent tous des standards ouverts ! Que demande-t-on d’autre ? En fait, il y a autre chose.
J'aimerais particulièrement voir un moyen plus rapide de développer des applications basées sur toutes les technologies ci-dessus - un moyen de créer des applications sans avoir recours à un middleware intégré aux services SOA. C'est exactement ce que je souhaite qu'une application Web soit capable de faire : "une connexion directe à SOA". Cette « connexion directe à la SOA » devrait être capable de contourner les barrières de portail traditionnelles et les moteurs de processus lourds pour accéder directement (au moins conceptuellement ; nous en apprendrons plus à ce sujet plus tard) aux services SOA. Par là, je n'entends pas seulement les services Web, il peut également s'agir de services d'orchestration BPEL, de services POJO à gros grain, de flux RSS ou de tout autre élément pouvant être exposé en tant que « service ». Bien entendu, les interfaces doivent être exposées à l’aide de normes ouvertes.
Ce nouveau modèle de développement et d'exécution crée une nouvelle façon de créer des applications composites basées sur les applications. Il a l’attrait d’un type client/serveur sans le lourd bagage des clients/serveurs lourds traditionnels. Il fonctionne côté navigateur et peut être implémenté selon des exigences spécifiques.
5. Applications composites basées sur l'utilisateur
Au cours des dernières années, nous avons tous entendu parler du concept d'« applications composites ». Cependant, la plupart des fournisseurs parlent de « services composites », comme moyen de restructurer leurs services hôtes en d'autres services ou applications de portail plus utiles. Permettez-moi de faire une analogie pour expliquer davantage.
AcmeGrid, notre fournisseur fictif de calcul en grille dans cet article, fournit un service (le calcul en grille) qui permet à vos applications de s'exécuter en tant que service. Les clients de l'entreprise lui ont dit qu'ils souhaitaient trouver un moyen de combiner de nombreux services en un seul service à grande granularité. Ainsi, naturellement, AcmeGrid a publié un générateur d'applications composites (CAB) AcmeGrid basé sur Eclipse. Il est intéressant de noter que CAB ressemble beaucoup à un concepteur BPEL, mais est plus étroitement intégré aux services publiés par AcmeGrid. Bien que très belle, ce n’est pas une véritable application, au mieux c’est juste un service. Essentiellement, CAB ressemble davantage à un constructeur de services. Mais qui a besoin d'un créateur de services lorsque nous essayons de créer des applications ? Bientôt, un autre fournisseur fictif, appelons-le AcmePortal, a annoncé son Portal Composite Application Builder (PCAB). Il est également livré avec un concepteur basé sur Eclipse ; bien qu'il ressemble également à un concepteur BPEL, ce programme « sait » comment créer des portails. Dans de nombreux cas, un portail fonctionne aussi bien qu’une application. Cependant, si vous insistez pour transformer un portail en application, ce sera en vain.
En fait, je souhaite vraiment implémenter une application composite basée sur l'utilisateur plutôt qu'une application composite basée sur un middleware. Pour ce faire, j'avais besoin d'une plate-forme de développement et d'exécution capable non seulement d'utiliser AJAX et SOA, mais également de gérer les deux. Certains fournisseurs ont poussé le concept des applications AJAX encore plus loin en appelant des services Web basés sur WSDL directement à partir du navigateur, ce qui est essentiellement un appel SOAP. Cette approche a même un nom : « Client/SOA ». Cela peut convenir à de simples applications non professionnelles ou grand public, mais pas à de véritables programmes d'entreprise. Pourquoi ? Parce que lorsque vous appelez un service Web directement depuis le navigateur, la fonction de supervision équivaut à être confiée au navigateur - ce qui signifie simplement qu'il n'y a aucun problème de supervision. La figure 1 montre le schéma fonctionnel de la consommation de services Web non supervisés. Je n'ai jamais rencontré d'entreprise qui ne surveillait pas ses services, et je ne crois pas qu'une entreprise permettrait que cela se produise simplement parce que nous sommes techniquement très efficaces dans ce domaine. Si vous ne me croyez pas, rappelez-vous simplement que les entreprises n'ouvrent jamais leurs pare-feu à des applications autres que HTTP et SSL. Peu importe à quel point nous persuadons les administrateurs système, ils n’ouvriront pas d’autres ports.
6. Nous avons besoin d'un nouveau type de plate-forme.
Comme le montre ce qui précède, ce dont nous discutons ne concerne pas uniquement les technologies AJAX et SOA. En fait, ce dont nous avons réellement besoin, c'est d'une plate-forme capable de fournir les capacités de supervision nécessaires pour qu'AJAX et SOA coexistent dans l'entreprise. Cette plate-forme offre également la possibilité de consommer les services SOA du point de vue du client et peut également surveiller la consommation des services. La figure 2 montre comment les services Web peuvent être gérés via une passerelle de services. Une passerelle de service est en fait une abstraction côté serveur qui surveille et régule l'accès au service pour le compte du client, qui dans le cas dont nous venons de parler est une application AJAX basée sur un navigateur. L’avantage d’utiliser une passerelle de services réside dans le fait que vous n’êtes pas limité à accéder uniquement aux services exécutés au sein de l’entreprise. Cette passerelle de services peut superviser n'importe quel service enregistré au sein de l'entreprise. Dans un service Web basé sur WSDL, l'entreprise enregistrera le WSDL et le WSDL fournira une liaison au service au moment de l'exécution. Il peut s'agir d'un service exécuté dans le centre de données d'une entreprise, mais il peut tout aussi bien s'agir d'un service exécuté dans le centre de données d'un partenariat. Si une entreprise autorise (par le biais de la réglementation) les applications à accéder aux services, l'endroit où ces services sont exécutés n'a pas d'importance.
7. Conclusion
Après avoir lu cet article, j'espère que vous avez commencé à apprécier le pouvoir de réunir AJAX et SOA, en particulier la manière dont les deux peuvent coexister et permettre de nouveaux types d'applications Web dotées des capacités réglementaires requises par les applications de service d'entreprise. . Je crois fermement que nous sommes à la veille d’une nouvelle ère pleine d’opportunités incroyables. À l’ère du Web 2.0, les réseaux sociaux, le partage d’images et diverses technologies d’annotation sont tous formidables, mais ce qui a véritablement d’influence, c’est la réponse du Web 2.0 aux entreprises.