Question

Je suis curieux de savoir comment différentes personnes résolvent l'intégration des systèmes.J'ai le sentiment que ces dernières années, de plus en plus de travail a été consacré à l'intégration de systèmes et que ce type de travail va également augmenter.

Je me demande si vous le résolvez en développant vos propres petits services qui sont ensuite connectés ou si vous utilisez une sorte de produit (WebSphere, BizTalk, Mule etc).Je pense également qu'il serait intéressant de savoir comment ce type de solutions est géré et maintenu (comment résolvez-vous la sécurité, l'instrumentation, etc.), quel type de problèmes avez-vous rencontré avec votre solution, etc.

Était-ce utile?

La solution

wow - Ok - je recevrai un article à ce sujet mais ce sera gros.

L'intégration doit être appuyée par une grande compréhension de la part de l'entreprise des avantages - Organisez un modèle opérationnel - car l'entreprise peut avoir réellement besoin de standardiser au lieu d'intégrer, car cela peut être coûteux - c'est pourquoi la plupart des SOA échouent ! L'architecture d'entreprise:La conduite des avantages commerciaux de l'informatique auteur (s):Jeanne W.Ross

Si une intégration est nécessaire, vous devez alors décider du type d'intégration.

Quelles sont les mesures de vitesse et de performances ?

Nous disposons d'une SOA .NET avec une application composite qui utilise BizTalk 2006 et des services Web avec des applications métier.Les performances de l'application du côté composite (consommateur) - sont limitées à la vitesse des webservices (et de leur implémentation) dans l'application métier !Nous avons besoin d'un retour sur les résultats inférieur à 3 secondes - liste de cas.Cela n'a pas pu être réalisé dans les services Web, nous devons donc accéder directement à la base de données pour la recherche initiale.Puis via les services Web pour la création de cas.Les implications financières et la maintenance deviennent ici un problème.

Le point ici est d'examiner les critères de performance dans les spécifications et les exigences commerciales, cela vous aidera à déterminer le type d'intégration que vous devez effectuer - WebServices (HTTP), File Drop/EDI, etc.

Fonctionnellement, pour l'intégration, vous devez ensuite examiner les points de défaillance de l'architecture proposée - car cela conduira à une chaîne de responsabilité dans SLA/OLA.Vous devrez peut-être regrouper les points d'intégration/d'échec dans des éléments que vous contrôlez.

Un point similaire concernant l'intégration avec le secteur d'activité est la suivante : que devez-vous savoir sur l'autre produit avant de pouvoir l'intégrer ?Oui, les services Web sont censés être conçus par contrat, mais la mise en œuvre est souvent fuiteuse et vous devez comprendre beaucoup de choses sur ce qui se passe - et s'il s'agit d'un produit dont vous ne contrôlez pas l'abstraction, même avec des fuites de services Web dans votre technologie d'intergation, alias BizTalk.

Associez ces deux points ensemble et le meilleur conseil est d'obtenir un type de hub d'intégration comme BizTalk - encapsulez la ligne d'applications métier dans les services Web que vous créez - afin que le côté BizTalk puisse être exempt d'abstractions qui fuient, vous pouvez également réduire les points de défaillance. car vous avez découplé l'application métier du hub d'intégration et le point de défaillance vers une source unique plutôt qu'à l'intérieur d'une orchestration.

L'instrumentation et les diagnostics dans les projets SOA et d'intergation sont difficiles à réaliser !- Ne laissez aucun vendeur brillant essayer de vous dire le contraire !Ouais, MOM avec MOM Ent peut faire ça. UniCenter peut faire du blabla.

Le principal problème est de comprendre ce que signifient les erreurs, c'est-à-dire les rots lors de l'intergation, et comment s'en remettre...Vous vous retrouvez avec des messages bloqués et vous devez comprendre ce que cela signifie pour ce processus commercial.Vous pouvez recevoir une alerte indiquant que les processeurs sont à 100 % Ram et que les orchestrations à 100 % ont échoué, mais cela n'a aucune signification réelle.Vous devez intégrer ces éléments à la solution dès le départ - et, espérons-le, dans vos points d'échec.

Les types de modèles d’intégration et la manière de les mettre en œuvre doivent également être pris en compte.

Ce qui précède est une vue réelle d'une SOA .NET avec BizTalk dans une implémentation LIVE.Mais cela est également dû aux limites architecturales de celui-ci : BizTalk est principalement un modèle HUB and SPOKE.

Vérifier Modèles d'applications d'entreprise par Martin Fowler

Il existe de nombreuses façons de réaliser la tâche !

Autres considérations...Langages de plateforme/développeur, etc.

L’un des facteurs importants pour nous était les compétences nécessaires pour démarrer ce projet.Nous avions des développeurs OO avec une compréhension de Java et C#, mais principalement C#.Nous avons donc opté pour la pile MS.Mais lorsque vous choisirez le type d’intégration et le produit pour gérer cela, ils auront besoin de plus de compétences pour comprendre cette technologie.Mais bon, c'est normal pour nous, les développeurs, n'est-ce pas ?Faux, de nombreux développeurs, quelle que soit leur expérience, peuvent se retrouver bloqués avec BizTalk !Grand changement de paradigme - qui est en partie dû au changement de messagerie plutôt qu'au code.

Le meilleur pour la fin !

Le nombre de transactions susceptibles d’être traitées dans le cadre de l’intégration est probablement le facteur le plus important dans tout cela.Car cela guidera le modèle, les points d’échec et la tolérance pour de telles choses.

Vous devez sélectionner le meilleur volume prévu, le bon.Quelque chose qui peut évoluer et évoluer !Nous avons sélectionné BizTalk car il peut évoluer et évoluer correctement et avec une meilleure compréhension que certains autres.

Si vous n'avez pas de volumes, évitez de trouver quelque chose pour les gérer et optez pour un style de type service Web à service Web sans gestion - la compréhension des performances et des échecs devra y être codée.

Si votre plate-forme Windows avec .net 3, jetez un œil à WWF/WCF car cela peut vous aider dans le service Web à service Web - beaucoup plus dans la plate-forme réelle maintenant pour toutes ces préoccupations sans la surcharge de BizTalk et autres.

J'espère que cela t'aides.

Autres conseils

D'après mon expérience, cela dépend du type de problème auquel vous vous attaquez.

D'après mon expérience, il est difficile de battre BizTalk 2006 R2 pour son argent, mais cela implique l'utilisation d'une pile technologique Microsoft.

Websphere MQ semble être plus facile à vendre aux grandes entreprises et il est probablement plus utilisé au niveau de l'entreprise.

Les deux fournissent une bonne instrumentation, mais c'est vraiment à vous, en tant que développeur, de la personnaliser en fonction des exigences de votre client.

Dans certains cas, j'ai constaté qu'une solution sur mesure était la plus appropriée ou qu'elle exploitait des technologies telles que MSMQ pour réduire les coûts.

Vous avez mentionné WebSphere, BizTalk, Mule.Chacun d’eux présente des caractéristiques très différentes avec ses bons et ses mauvais points.Si vous recherchez uniquement l'intégration, je recommanderai Mule.J'en ai eu une très bonne expérience et, plus important encore, l'architecte n'est pas invasif, vous pouvez donc toujours migrer vers un autre ESB ou une autre solution de réclamation Buzz Word.L'un des points forts de Mule est qu'il peut être intégré à votre application et que votre artefact final peut être déployé sur Webshpere, WLS, Glassfish, etc.sans même vous montrer intégré un ESB.Cet ESB peut ensuite effectuer toute la plomberie d’intégration (gestion des types de connexion et des protocoles).Alors que certains des points finaux pourraient être une autre solution d'intégration que vous avez mentionnée.

Nous utilisons Mule depuis un certain temps (étudiez maintenant la migration de la version 1.4 vers la version 2.1.x).

Eh bien, c'est l'un des meilleurs ESB avec une communauté en direct et une réaction rapide du côté du fournisseur, mais la version IMO 2.1.x est encore un peu brute (ou nous ne sommes que la société qui l'utilise pour appeler CXF Web :) voir aussi mon message pour plus de détails http://www.nabble.com/Migration-from-XFire-to-CXF:-Is-Web-Service-Client-in-Mule-2.x-broken--to19969320.html#a19969320)

nous avons un contrat Oracle.Nous utilisons donc Oracle Stack.Suite SOA 10.1.3.4.Principalement des solutions BPEL et pour des transformations simples, nous essayons d'utiliser ESB.

L'ESB dispose d'un mauvais mécanisme de gestion des pannes.Pour le BPEL, il existe de nombreuses façons de gérer les erreurs.Nous essayons de développer des webservices Java pour nous connecter à la Suite SOA et nos principaux systèmes sont des systèmes Oracle EBS.Ils communiquent avec les systèmes existants ou d'autres environnements EBS via les adaptateurs EBS par défaut fournis avec la suite SOA.

Les problèmes que nous avons rencontrés sont le manque de connaissances sur les adaptateurs EBS.Nous avons rencontré quelques problèmes avec une solution BPEL qui recevait des informations des systèmes EBS.Ce fut un sacré travail de préparer la production de la solution.

Sécuriser nos services Web n'est pas un gros problème.La pile Oracle est accompagnée d'Oracle Web Service Manager.Avec cela, nous pouvons sécuriser, enregistrer, etc.tous les webservices.

Le plus gros problème que nous rencontrons est le manque de nos propres normes.Faire sentir à l’entreprise qu’elle peut également créer des solutions SOA.Nous ne pouvons pas expliquer les avantages qu'ils obtiennent avec une solution SOA.Plus rapide?Non !Moins cher?Sûrement pas!Des solutions plus simples ?Eh bien, peut-être que lorsque nous aurons de bons services réutilisables...eh bien, cette partie la plus simple contient un problème :comment savoir quelles applications utilisent les webservices réutilisables ?

Nous avons besoin d'un registre qui puisse afficher ce genre d'informations.Parce que nous ne trouvons pas de bonne solution open source, nous essayons de créer notre propre registre.Solution APEX simple, toujours issue de la pile Oracle.;)

Alors quelqu'un connaît un bon produit pour enregistrer ce genre d'informations ?

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top