Accueil
 > Rapports de TEC > Blogue de TEC > Architecture Evolution: De basé sur le Web à l'architectu...

Architecture Evolution: De basé sur le Web à l'architecture orientée services

Écrit par : Predrag Jakovljevic
Date de publication : juillet 18 2013

étendre les applications vers le Web

class="articleText"> technologie

(LAN) et réseaux étendus (WAN) est devenu une dépense et un casse-tête de gestion pour la plupart des entreprises. En outre, la mise à jour des versions de logiciels, en particulier sur les nombreux ordinateurs personnels répartis (PC), est devenu un problème presque insoluble. Plusieurs technologies de l'information (IT) ministères ont donc déplacé vers Internet ou intranet technologie comme une solution. Dans cette approche, les services de communication offrent la vaste zone épine dorsale des communications et des PC simplement communiquer les localisateurs de ressources uniformes (URL) pour atteindre les serveurs ont besoin d'aide à partir. Pépites logiciel codé en Java (ou tout autre web-friendly) langue qui fonctionne sur les PC clients est téléchargé en cas de besoin, en s'assurant qu'il est toujours la dernière version. Avec un Internet-seulement un système d'entreprise en place, les mises à niveau de logiciels côté client deviennent inutiles, tandis que les applications basées sur un navigateur web simplifient considérablement la formation. Attachant ensemble endroits éloignés d'une entreprise devient plus simple aussi.

la deuxième partie de la série architecture Evolution:. des grands systèmes vers une architecture orientée services

En fait, en raison du phénomène d'Internet, des termes tels que Web et web-enabled ont récemment remplacé le client / serveur mot à la mode des années 1990 , avec client / serveur insinuant maintenant une référence à l'ancienne façon de pré-Web de faire les choses. Cependant, la plupart des systèmes client / serveur ont entre-temps été modifiées pour inclure l'accès Web et l'application ou de l'architecture basée sur le Web est naturellement une véritable architecture client / serveur. Notamment, sur le côté serveur, le Web utilise une architecture multi-niveaux avec des serveurs interconnectés web, serveurs d'applications, serveurs de bases de données et des serveurs cache, tandis que du côté de la clientèle, les machines des utilisateurs communément exécuter des scripts intégrés sur des pages web innombrables. Ils ont également exécuter des applets Java, des programmes de Java plus, les applications clientes riches, et ainsi de suite, tous ce qui signifie que le client et le serveur coopèrent en tandem.

L'avantage d'une architecture basée sur Internet, c'est que n'importe quel ordinateur avec un accès sécurisé à Internet peut accéder au produit, étant donné que en tapant simplement une adresse URL, on a accès au système. Il ya des économies potentielles en termes de déploiement, la maintenance, le support et les mises à niveau, depuis les changements sur le côté serveur sont immédiatement disponibles pour tous les utilisateurs.

Pourtant, bien que cette approche pourrait avoir valeur d'un point de vue informatique, d'abord il n'a pas nécessairement d'améliorer l'expérience utilisateur de l'application. En fait, de nombreux utilisateurs se sont plaints de la même facilité d'utilisation a diminué et les performances des premières applications en mode Internet pure. Les utilisateurs ont signalé une baisse importante des performances des applications grâce aux nombreux hypertext markup language (HTML) allers-retours, la navigation de lien hypertexte lourd, et des réseaux plus lents. Même après la mise à niveau du réseau, le renforcement des fermes de serveurs (comme plus matériel du serveur et le logiciel de serveur Web est nécessaire), et la refonte de l'interface pour simplifier la navigation (via les combinaisons de touches courtes, par exemple), de nombreux utilisateurs ont toujours la nostalgie du client «riche» / serveur métaphore d'interface.

premières architectures Internet de clients légers ont également fait peu de miser sur les appareils portatifs sans fil, téléphones mobiles et autres technologies intelligentes à venir. Ainsi, de nombreux fournisseurs ont depuis-au sein de leurs suites-rendu plus riche, plus dynamique, et des interfaces utilisateur plus performants (ISU), avec une intégration étroite à Microsoft produits de bureau de bureau pour presque toujours connecté les utilisateurs de puissance et pur HTML / dynamique HTML (DHTML) interfaces pour les utilisateurs externes et occasionnels du système. Les dernières technologies dites Web 2.0 comme JavaScrip asynchrone t (AJAX) et extensible markup language (XML) certainement combler le fossé avec le meilleur des deux mondes (voir Software as a Service gagne du terrain ).

Pour plus d'informations générales, voir architecture Evolution:. De Mainframe vers SOA

défis de l'extension de Enterprise Resource Planning à l'Internet

étendre les applications de back-office à l'Internet découle de la volonté de nombreuses organisations d'utilisateurs de ne pas réinventer la roue dans leur ruée pour créer des applications e-commerce clé en main. En étendant la planification des ressources d'entreprise existant (ERP) à cette fin, les organisations non seulement tirer parti de leur investissement dans la solution ERP, mais peut aussi accélérer le développement de leurs capacités de commerce électronique .

Cependant, les systèmes d'entreprise traditionnels se sont révélés difficiles à modifier et à étendre. Barricadés derrière des interfaces de programmation complexes, brevetées applications (API), et sur la base, presque indéchiffrables schémas de bases de données relationnelles complexes, les systèmes ERP traditionnels n'ont pas pris facilement à l'e-commerce. Ainsi, les technologies de transport et de communication comme les services Web, le message des courtiers et des files d'attente, Electronic Data Interchange (EDI) et XML obtenir toute l'attention de la fin, mais le problème inhérent à l'ancien code de base et la logique métier duplication sont souvent passées sous silence, ou pas discuté ouvertement (pour plus d'informations, voir intégration de tous les actifs d'information ).

La première étape dans la conquête du Web de ERP était de permettre l'accès au navigateur en appuyant Hypertext Transfer Protocol (HTTP), HTML et Java. Cette étape de l'ajout d'une couche d'accès au Web sur les systèmes client / serveur anciennes existantes a été largement complété par la majorité des fournisseurs de l'entreprise. C'est, cependant, qu'une solution à court terme, puisque seule la partie client a été réécrit pour être accessible sur le Web, et parce que tant la nature de l'interaction et le genre de désinvolture visite utilisateurs basés sur Internet sont différents par rapport à traditionnel -maison des interactions du système d'utilisateur avec pouvoir.

La prochaine étape, qui a commencé assez récemment, est d'étendre les applications d'entreprise eux-mêmes sur le Web, où ils peuvent être consultés et gérés par des partenaires commerciaux extérieurs et des employés mobiles. Ces applications Web sont hybrides en forme, rassemblant des éléments hérités propriétaires, soit hôte-centrique ou client / serveur, avec client léger, basé sur un navigateur interfaces. L'astuce consiste à apporter les fonctionnalités avancées des systèmes ERP pour le Web, mais divisé en composants et sans avoir besoin d'une couche supplémentaire de l'architecture du wrapper. Certains fournisseurs ont également commencé à ajouter des crochets de mobilité dans leurs suites ainsi que des séances d'ERP peuvent être accessibles via des dispositifs sans fil.

Pour que les systèmes ERP traditionnels pour être prêt pour Internet, ils devront être

  1. pleinement navigateur activé (bien que selon le rôle ou la tâche de l'utilisateur, le navigateur, Microsoft Office , ou le Microsoft Windows "client riche" peut être la meilleure interface utilisateur) ;     
  2. repensé pour être accessible à tous les utilisateurs de l'entreprise, et pas seulement quelques-uns spécial;       
  3. repensé pour être disponible pour les partenaires commerciaux (p. ex, les clients, les revendeurs et les fournisseurs), et         
  4. repensé pour utiliser un langage standard de données d'échange (le plus souvent XML), plutôt que des protocoles propriétaires.

Pour ce faire, d'une manière appropriée, les éditeurs d'ERP doivent repenser complètement leurs applications pour un environnement e-business vrai, sur un basée sur les standards Java 2 Enterprise Edition (J2EE ), open source, ou Microsoft. NET serveur d'application compatible, ce qui nécessite des ressources et un engagement. L'application résultante devra alors être conçu à partir de zéro pour être accessible sur Internet par un navigateur Web, et pour être extensible par des composants supplémentaires, et géré par un serveur d'applications avec des fonctionnalités intégrées de sécurité et d'intégration.

Parallèlement à la puissance de traitement d'être transférés de l'ordinateur central et mini-ordinateurs pour le bureau, un effort important a été fait pour rendre les systèmes très riche en fonctionnalités avec une énorme quantité de fonctionnalités intégrées dite «vanille» ou "out of the box" progiciels. Toutefois, lorsque la demande de base a dû être mis à niveau vers une version plus récente, tout le développement autour du système devait être re-testés afin de s'assurer que le boulon sur le système (avec des modifications et des extensions spécifiques à l'industrie) était encore fonctionnel. Dans de nombreux cas, les processus d'affaires ont dû être reverse engineering, et des tables de base de données a dû être mis à jour directement. Souvent, ce type de garanties de logiciels annulés de développement et les risques associés à ce type de verrou sur la situation étaient extrêmement élevés par rapport aux avantages potentiels. En outre, l'intégration entre les systèmes ERP disparates (soit entre différentes divisions d'une entreprise ou entre partenaires commerciaux) se composait de technologies d'intégration point-à-point rigides et complexes, ce qu'on appelle l'intégration d'applications d'entreprise (EAI). À long terme, quelque chose devait être fait de cette situation et les retards de longue durée et les coûts résultant prohibitifs associés à la mise à jour des modifications.

À cette fin, la phase d'architecture n-tier et Internet a ouvert l'ère de la négociation immédiate, des suites d'applications de plus en plus larges (au-delà de base ERP et avec des capacités spécifiques à l'industrie en une seule base de code) résidant sur une seule plate-forme, tandis que la base d'utilisateurs a augmenté dans tous les milieux de vie dans une entreprise étendue (y compris les travailleurs opérationnels dans les ventes, la distribution, le service sur le terrain, et les départements de développement de produits).

serveurs d'applications mènent à une architecture orientée services

facilitateurs crucial pour ces traits étaient des serveurs d'applications, qui se composent du logiciel du système utilisé pour héberger la logique métier des applications (par exemple, en trois niveaux client / applications serveur, le serveur d'applications gère la logique métier et lui permet d'être accessible à partir de la couche utilisateur). Ce sont des programmes qui traitent toutes les opérations d'application entre les utilisateurs et les back-end des applications d'entreprise ou bases de données de l'entreprise utilisatrice. Les serveurs d'applications sont généralement utilisés pour des applications complexes basées sur les transactions, et de soutenir les besoins haut de gamme, un serveur d'application doit avoir une redondance intégrée, moniteurs pour la haute disponibilité, des services d'applications distribuées de haute performance, et le soutien à l'accès aux bases de données complexes .

En outre, après le Web a explosé au milieu des années 1990, les serveurs d'applications est devenu le Web, et le terme web du serveur (application) se réfère le plus souvent à des logiciels dans un environnement intranet ou Internet qui héberge une variété des systèmes de langage utilisé pour les requêtes de base de données du programme ou le traitement des affaires en général. Ces scripts et de services, tels que JavaScript ou DHTML, et pages Java Server (JSP) ou Microsoft Active Server Pages ( ASP ), l'accès général une base de données pour récupérer la mise à jour des données qui sont présentés aux utilisateurs via leurs navigateurs ou des applications clientes.

Il est donc chevauchement entre un serveur d'application et un serveur web, car les deux peuvent effectuer des tâches similaires. Le serveur web (parfois aussi appelé un serveur HTTP) peut invoquer une variété de scripts et de services aux bases de données de requêtes et d'effectuer le traitement des affaires, tandis que les serveurs d'application viennent souvent avec leur propre serveur HTTP, qui fournit des pages Web dans le navigateur. Le serveur d'application peut résider dans le même ordinateur que le serveur Web ou être dans un autre ordinateur, alors que dans les grands sites, plusieurs ordinateurs sont utilisés pour les serveurs d'applications et les serveurs Web. Des exemples de serveurs d'applications Web J2EE commerciaux comprennent BEA Weblogic Enterprise , Sun Java System Application Server (anciennement Sun ONE Application Server ), Borland AppServer , et s ' IBM WebSphere Application Server , tandis que les plus grands fournisseurs de systèmes ERP tels que SAP et Oracle aussi avoir leur propre version des serveurs d'application (voir applications SOA et de l'infrastructure The Next Frontier? ). La plate-forme Microsoft. NET doit être mentionné ici comme une alternative aux J2EE homologues à voir Comprendre J2EE et. NET Environnements Avant de choisir .

En fait, de nombreuses entreprises embarqué (probablement pas s'en rendre compte à l'époque) sur la route de l'architecture orientée services Il ya (SOA) et les services Web depuis plusieurs années quand ils ont fait leurs premiers investissements dans les technologies de logiciels à base de composants et, en particulier, dans les serveurs d'applications. SOA (qui est généralement assimilé à des services Web, bien que ces deux notions ne doivent pas être utilisés de façon interchangeable) est un terme générique pour une interface normalisée entre le logiciel qui permet à un programme d'utiliser des composants fonctionnels (services) d'un autre programme. Anciennement appelé distribué objets architecture, le terme SOA a été inventé au tournant du siècle que les services Web et les normes Internet évoluaient (comme mentionné plus tôt dans cette série, commun Request Broker Architecture d'objet [CORBA] et distribués modèle objet commun [DCOM] sont des exemples des OSS précédentes).

Gartner définit SOA comme «une topologie de l'application dans laquelle la logique métier de l'application est organisée en modules (services) avec identité claire, un but et d'interfaces de programmation d'accès. Les services se comportent comme des "boîtes noires": Leur conception interne est indépendant de la nature et le but du demandeur En SOA, les données et la logique métier sont encapsulés dans des composants métier modulaires avec interfaces documentées Cette conception précise et facilite le développement progressif et extensions futures... Une application SOA peut également être intégré avec hétérogène, héritage externe et applications achetés plus facilement que, d'une application non-SOA monolithique peut ".

L'Organisation pour la promotion de la Structured Information Standards (OASIS) SOA Reference Model Group définit SOA comme un «paradigme de l'organisation et l'utilisation des capacités qui peuvent être distribués sous le contrôle de différents domaines de la propriété. Elle fournit des moyens d'offrir un uniforme, découvrez, interagir avec et utiliser les capacités à produire les effets désirés en conformité avec conditions préalables et des attentes mesurables ".

C'est-à-dire que la SOA identifie toutes les fonctions ou services en utilisant un langage de description d'interfaces qui exécutent des processus d'affaires, de sorte que chaque interaction est indépendante des autres interactions et les protocoles d'interconnexion des appareils communicants. Depuis interfaces sont indépendant de la plateforme, un client doit être en mesure d'utiliser le service à partir de n'importe quel dispositif utilisant n'importe quel système d'exploitation (OS) dans n'importe quel langage de programmation. SOA soutient l'intégration et les activités de consolidation au sein des systèmes d'entreprise complexes et hétérogènes, mais ne précise pas ou fournir une méthodologie ou d'un cadre pour des capacités ou des services documenter. Le concept devrait, en théorie, être en mesure d'aider les entreprises à répondre plus rapidement et efficacement à l'évolution des conditions de marché en reconfigurant les processus d'affaires. Il permet l'agilité, la flexibilité, la visibilité, la collaboration avec les partenaires commerciaux (et entre fonctionnel et les services informatiques), et ainsi de suite, par la promotion de la réutilisation au niveau des services plutôt que des niveaux d'objets, pour autant sortir de manière significative à partir du modèle de orientée objet (OO) programmation, qui lie des données et leur traitement ensemble. En outre, l'architecture SOA (là encore, en théorie) devrait simplifier l'interconnexion et l'utilisation à des actifs informatiques existants, y compris les actifs gérés en extinction, même ce qui donne un nouveau bail sur la vie (sinon à part entière rajeunissement) pour mainframes.

Pourtant, en plus de maturité encore (et parfois même contradictoires) des normes communément admises, défis application SOA comprennent la gestion des métadonnées de services et fournir des niveaux de sécurité appropriés. De diriger et de fournir des informations sur l'interaction des services peut être compliqué, car l'architecture repose sur la messagerie multiple complexe qui ouvre la porte à du code désordre et de la communication brisée, au-dessus du potentiel de non-conformité aux réglementations gouvernementales. La flexibilité de SOA constitue une menace à la sécurité, puisque ces applications services engloutir, en particulier ceux externe aux pare-feu de l'entreprise, et sont plus visibles à des parties externes que les applications traditionnelles, ce qui explique pourquoi les entreprises doivent définir des politiques visant à protéger qui peuvent voir exactement quelle information.

Problèmes de class="articleText">

Inutile de dire que tous les fournisseurs sont soigneusement cherchent des solutions à ces défis. Alors que plus de définitions et des explications sur les SOA peuvent être trouvés dans Comprendre SOA, Web Services, BPM, BPEL, et plus , le fait demeure que la prochaine étape de l'évolution de l'architecture logicielle d'entreprise est l'un des SOA et Web services, ce qui promet un hébergement de changements presque immédiats, les applications assemblés ou composite spécifiques à l'industrie qui utilisent les services communs et cohérents (composants logiciels) à partir des référentiels, et (re) création de processus d'affaires omniprésents et plates-formes spécifiques à l'industrie, au besoin.

 
comments powered by Disqus


©2014 Technology Evaluation Centers Inc. All rights reserved.