Accueil
 > Rapports de TEC > Blogue de TEC > Comprendre SOA, Web Services, BPM et BPEL Deuxième partie...

Comprendre SOA, Web Services, BPM et BPEL Deuxième partie: BPEL et Recommandations utilisateur

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

Web Services Orchestration

augmentation de la réactivité axée sur la demande vers les besoins des clients nécessite un ensemble bien coordonnée des composants de l'infrastructure informatique, car il n'est plus assez bon pour acheter des morceaux disparates et s'attendre à ce qu'ils simplement interopérer. L'idéal devrait être une sorte d'échange de données indépendant qui miserait sur des métadonnées et des processus communs à créer des fonctionnalités composite découlant de l'application existante et des actifs de services Web, qui sont conservés dans un dépôt pour, presque montage sur la volée dynamique, pour exemple, un portail rôle spécifique, avec des données sensibles au contexte pour tous les types d'utilisateurs et les décideurs de l'entreprise.

Web services orchestration, ce qui rend le travail des services Web, est un processus en deux étapes: 1) publier d'abord, puis 2) orchestrent (c.-à-intégrer ces services Web publiés et de coordonner les messages entre eux pour créer processus d'affaires). En d'autres termes, l'orchestration comporte trois éléments principaux: 1) coordination , y compris les communications asynchrones, le traitement parallèle, la gestion des événements, entreprise transaction protocole (BTP), le regroupement et l'évolutivité; 2) gestion , y compris la gestion administration, d'annulation et de changement, exception ainsi que les délais et le contrôle de version, et 3) le suivi des activités de , qui inclut des rapports d'entreprise, audit de suivi, et non -répudiation. Comme cela devrait être vu à partir de la description ci-dessus, la nature faiblement couplée de composants de services Web peut créer des complications, telles que la nécessité de coordonner la messagerie asynchrone, ce qui n'est pas produit à des intervalles prédéterminés ou régulière.

Le terme asynchrone est généralement utilisé pour décrire les communications dans lesquelles les données peuvent être transmises de façon intermittente plutôt que dans un flux régulier (par exemple, une conversation téléphonique est asynchrone car les deux parties ne peut parler chaque fois qu'ils en ont envie). Sinon, si la communication était synchrone , chaque partie serait nécessaire d'attendre un intervalle spécifié avant de parler. La difficulté avec les communications asynchrones, c'est que le récepteur doit disposer d'un moyen de faire la distinction entre les données valides et le bruit. Dans les communications informatiques, ce qui est habituellement accompli par un bit de départ spécial et bit d'arrêt au début et à la fin de chaque morceau de données, et pour cette raison, la communication asynchrone est parfois appelée transmission start-stop.

Comme certains services doivent être disponibles dans toute l'entreprise, ce qui peut souvent signifier à travers les continents, ils doivent être évocable à travers deux réseaux locaux (LAN) et réseaux étendus (WAN). Les délais impliqués dans cette communication longue distance pourraient logiquement exigent que les services devraient être relativement "gros grain", c'est à dire qu'ils ne seraient pas appelés trop souvent, et devraient le faire d'importantes quantités de travail en réponse à chaque appel.

Ceci est la deuxième partie d'un didacticiel en deux parties.

Part One discuté SAO, les services Web et BPM.

BPEL

Business Process langage d'exécution (BPEL) produits à base de travail en encapsulant les installations d'orchestration nécessaires pour coordonner, gérer et surveiller orientée services processus d'affaires. Pour le camp Java, qui pourrait être atteint par le biais d'exposer ces installations pour les développeurs via une page Java du serveur composant (JSP) et appelé ScenarioBean qui est basé sur des normes industrielles telles que XML, SOAP, WSDL, Java Message Service, BTP et électronique affaires XML (ebXML). En plus de la ScenarioBeans, qui permettent aux développeurs Java de composer plusieurs services Web et les interactions des utilisateurs, les produits se caractérisent typiquement deux autres composantes principales: 1) la console Web orchestration de service du serveur d'orchestration et 2) de l'administration des services.

Dans un langage quelque peu simplifiée, tandis que les services Web permettent aux applications d'échanger facilement et de réutiliser l'information, c'est seulement quand ils sont orchestrés (coordonnée) dans les flux commerciaux de longue durée ou les processus que les entreprises peuvent réaliser leur vrai valeur.

C'est là que BPEL vient en image, qui, également connu sous le nom BPEL4WS est un langage basé sur XML pour la standardisation des processus d'affaires dans un environnement de calcul distribué ou une grille qui permet aux entreprises distinctes pour interconnecter leurs applications et de partager données. Le langage fournit un langage de programmation standard que les entreprises peuvent utiliser pour définir comment combiner des services Web pour accomplir des tâches. La spécification WS-Coordination décrit ainsi comment les services Web individuels dans cette tâche vont interagir, alors que la norme WS-Transaction veillera à ce que toutes les transactions sont terminés avec succès ou l'échec en tant que groupe. Dans le protocole Web Services pile, BPEL est une couche au-dessus de WSDL, qu'il utilise pour spécifier les actions qui devraient avoir lieu dans un processus d'affaires, et de décrire les services Web fournis par un processus d'entreprise.

Conçu comme une combinaison de services Web flux de Langue propriétaire IBM ( WSFL ) et XML Business Process langue de Microsoft BizTalk Server ( XLANG ) cahier des charges, BPEL indépendant de la plateforme permet aux entreprises de garder protocoles opérationnels internes distincts des protocoles inter-entreprises afin que les processus internes peuvent être modifiés sans affecter l'échange de données d'entreprise à entreprise. Un document BPEL, par exemple, conserve la trace de tous les processus d'affaires qui sont reliés à une transaction et garantit que les processus sont exécutés dans l'ordre correct grâce à l'automatisation des messages.

Etre un format basé sur des normes pour le transfert de processus entre les plates-formes tout en restant indépendant de la plateforme, BPEL est maintenant à la recherche comme un élément important dans la taxonomie des services Web et de BPM, compte tenu de BEA et SAP sont également partisans. Ancien Collaxa a depuis longtemps déclaré son soutien pour BPEL et Oracle dispose maintenant par conséquent mentionnés ci-dessus, l'utilisateur de grande envergure de son moteur.

Par exemple, les clients peuvent désormais utiliser soi-disant récemment publié ou re-marque Oracle BPEL Process Manager pour orchestrer les processus déployés à travers soit une infrastructure NET Java ou Microsoft.. Oracle peut légitimement affirmer que son produit est le seul serveur BPEL natif sur le marché. Cependant, plusieurs produits de BPEL nominalement non-native des concurrents de serveur d'applications Oracle, y compris BEA et webMethods , permet l'importation et l'exportation entre BPEL et leurs propres formats propriétaires, notamment par le biais de partenariats Le Middleware Company . Bien qu'ayant bailleurs puissants, BPEL reste l'un des un certain nombre de normes émergentes dans le domaine général de la BPM. D'autres seraient interface chorégraphie de service Web (WSCI), qui est toujours aussi soutenue par BEA, Intalio , SAP , et Sun Microsystems , et un certain nombre d'autres caractéristiques comme Business Process Modeling Language (BPML) ou traitement XML langage de description (XPDL). Il ya aussi quelques aspects que BPEL ne dispose pas actuellement adresse, comme des transformations complexes, la conversion des données, les accords avec les partenaires commerciaux, les processus manuels (humaines) et les connecteurs vers des systèmes de back-office spécifiques.

Pour cette raison, les grandes entreprises sera toujours tendance à se tourner vers d'autres solutions plus complètes ou même à la BPM indiqué ci-dessus, SOA et les services Web des fournisseurs spécialisés pour créer, gérer et orchestrer complexe, haute processus de volume qui incluent des personnes, des données structurées, non structurées contenu et la gestion des exceptions.

Recommandations de l'utilisateur

Bien que l'acceptation généralisée de services implémentations inter-entreprises Web n'arrivera pas de sitôt, l'implication des acteurs majeurs dans la mobilisation de ces devrait inciter les grandes entreprises mondiales pour commencer à apprendre les nouveaux protocoles, normes et technologies afin de saisir l'avantage de l'entreprise sous-jacente potentiel de ralentissement des problèmes d'intégration traditionnelles, tout en se concentrant davantage sur les processus qui sous-tendent les systèmes informatiques que la technologie actuelle. Ils devraient essayer de comprendre comment les développeurs vont des services Web de levier, SOA et BPM, quels sont leurs besoins continus sont, et ce complexités peuvent découler de leur utilisation, telles que les questions culturelles et les normes, en plus de nombreuses fonctionnalités essentielles telles que la fiabilité, la sécurité , l'évolutivité, les performances et de gérabilité.

Pour les utilisateurs occasionnels et la puissance d'applications d'affaires sur un bureau, la conversion à SOA devrait être assez transparent, ce qui n'est pas le cas avec l'armée de l'IT membres du personnel si, pour qui le mouvement va représenter un remaniement significatif de l'infrastructure informatique qui est généralement un méli-mélo complexe de technologies disparates.

D'autre part, les principaux fournisseurs d'ERP devrait s'associer avec les services Web entreprises de logiciels mentionnés ci-dessus sur les registres UDDI, les plateformes de gestion, la sécurité et les fonctionnalités ESB, et renforcer le soutien des services Web dans leurs produits, à donner à leurs clients des raisons impérieuses de garder leur exemple ERP actuel comme une partie essentielle de leur avenir plan SOA. Par exemple, les vendeurs doivent explorer en utilisant la messagerie SOAP pour la communication et l'intégration à d'autres applications au sein de l'entreprise utilisatrice ou enveloppez WSDL autour du produit existant pour exposer les fonctionnalités pour une utilisation dans l'évolution des processus d'affaires des utilisateurs. Pour plus d'informations, voir Rewrite ou Wrap-Around ancien logiciel? .

Alors que les services Web SOA et peuvent faciliter l'intégration à travers une certaine interopérabilité imposée, ils ne seront pas éliminer le besoin d'intégration d'applications vénérable via des adaptateurs, connecteurs, ou plus, car ils ne sont pas n'importe quel genre de panacée. La SOA n'est pas une réponse à tout, car il est encore souvent possible et plus viable pour synchroniser les systèmes disparates en utilisant l'intégration de données qui est généralement plus grossière et avec moins de logique métier de SOA (par exemple, ce serait céder l'intégralité des bons de commande, plutôt de modifier la description d'une seule ligne dans un seul bon de commande comme cela peut arriver avec une interface humaine).

Aussi, bien que ces nouveaux concepts peuvent offrir de nouvelles possibilités d'affaires et de créer un certain dynamisme et efficacité, ils ne vont pas à transformer les entreprises elles-mêmes, étant donné qu'ils sont seulement un morceau de nouvelles technologies. Même si les grandes entreprises sont les premiers à barboter avec le déploiement de services Web, leur impact sera finalement également ressenti par les entreprises qui fournissent des produits et services aux consommateurs, indépendamment de leur taille. Les entreprises doivent examiner les demandes qu'ils ont déjà et ensuite définir quels services il est qu'ils ont vraiment besoin. Même les nombreuses nouvelles applications qui sont déjà SOA peut-être encore à un bas niveau d'abstraction de l'entreprise, alors que paradoxalement, certaines applications héritées pourrait être plus facile à intégrer et à s'intégrer.

peuvent déjà créer et d'utiliser des services Web qui peuvent être réutilisés par d'autres applications, comme les services à autoriser carte de crédit ou d'authentifier l'identité d'une personne lors de la connexion sur plusieurs systèmes. Cependant, pour profiter pleinement des services Web et SOA, les entreprises devraient soigneusement et laborieusement réexaminer leurs processus d'affaires et des meilleures pratiques et rechercher l'efficacité d'une infrastructure remanié pourrait apporter. Le point de départ pour la construction d'un modèle SOA serait d'identifier et de créer des services Web autour d'objets communs de référence d'affaires pour l'ensemble de l'organisation, qui sera largement tributaire de l'alignement stratégique de l'organisation et de l'industrie au cas où.

même avec un Internet comparaison des échanges publics et privés, les services Web semblent avoir plus de potentiel dans un environnement de confiance de partenaires d'affaires. Ainsi, en plus de la question de savoir si BPEL sera la norme en vigueur, il ya la question de savoir si les entreprises seront disposés à partager leurs modèles de processus métier avec l'autre. Organisations évaluation des services Web et SOA peuvent bénéficier de la poursuite des activités de consortiums pertinents, tandis que ceux qui ont des services Web déjà endettée peut bénéficier d'joignant afin de partager les expériences avec leurs pairs et de s'assurer que le consortium se concentre sur les questions commerciales. Cependant, comme le consortium ne peut pas imposer d'autorité sur les vendeurs et comme il n'est pas performant tests de conformité à ce stade, les utilisateurs doivent interroger directement les fournisseurs sur la conformité aux normes.

avant que les clients font toute tentative de choisir des produits ou des suites de produits pour d'autres solutions logicielles qui nécessitent une interopérabilité transparente EAI, middleware, serveurs d'application Web, ou ils doivent s'assurer qu'ils comprennent la différence dans les approches utilisées par J2EE et. NET. Pour plus d'informations voir Comprendre J2EE et. NET Environnements Avant de choisir . Alors que l'un des objectifs principaux de services Web est de faire le choix de la plate-forme moins importante que la réalité est encore loin. Malgré plate-forme la préférence de tout le monde et la liste des programmeurs avec certains ensembles de compétences, il est donc prudent de rassembler autant d'informations que possible des deux camps, que les deux auront leurs avantages et inconvénients.

Bien que la concurrence se traduit généralement dans les deux camps se tenir mutuellement sur leurs conseils d'orteil d'être plus créatif, il n'aide pas les utilisateurs et les perspectives maintenant. Ils doivent donc interroger les vendeurs étroitement sur l'approche qui ils sont (ou seront) en prenant dans leurs versions actuelles et futures, et pourquoi. Une fois le choix effectué, il sera difficile, mais pas impossible, de changer ou d'abréger. Depuis efforts d'intégration d'applications sont coûteux, complexe et chronophage, la décision peut revenir vous hanter si vous ne choisissez pas à bon escient. Les utilisateurs doivent reconnaître que faire un choix pour un serveur d'application doit englober l'ensemble de la pile (portail, la personnalisation, répertoire, etc.)

Les services Web spécialisés de niche et les fournisseurs de BPM doit être envisagée, bien que dans un état d'esprit tactique et avec un retour raisonnablement rapide et justifiable. En général, le marché devrait rester très proche des normes communément acceptées, et méfiez-vous de tout fournisseur qui est enclin à créer grande dépendance à sa technologie propriétaire, car elle conduit à des hausses de prix injustifiées, et une ouverture en baisse à l'avenir.

 
comments powered by Disqus

Recherches récentes :
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others

©2014 Technology Evaluation Centers Inc. All rights reserved.