IBM Cast Iron et ESB

Question

J'essaie de définir la feuille de route de l'architecture d'intégration pour mon entreprise et je recherche des conseils sur mon approche.

La plupart (90-95%) de nos applications sont basées sur .NET avec Microsoft SQL Server 2008. Nous avons des ventes cloud dans Salesforce et prévoyons de migrer plus d'applications (vers la plateforme Force.com) Salesforce dans les années à venir. Nous avons acheté IBM Cast Iron pour intégrer nos applications sur site à Salesforce et éventuellement dans nos applications sur site. Maintenant, après avoir analysé les applications existantes et l'intégration existante (travaux SQL ad-hoc, services Windows, ...), j'ai senti que nous avions besoin d'un ESB car je me suis rendu compte que nous avons plusieurs façons de parler avec les applications (FTP, services Web, CSV/Excel, SQL). Bien que Cast Iron puisse prendre n'importe quel type de formats et puisse parler de Web Services, FTP, etc ..., je suis préoccupé par le positionnement de Cast Iron comme plate-forme d'intégration car elle deviendra une architecture de courtier (similaire à Hub and Spoke) cela suit l'approche EAI traditionnelle qui peut souffrir d'un point de défaillance unique et de problèmes de performance au fur et à mesure que les orchestrations augmentent.

En introduisant ESB, je crois que je vais obtenir au moins les avantages suivants:

• Évolutivité
• Fiabilité
• haute performance

Le schéma ci-joint reflète une version simplifiée ce scénario. Cette architecture peut également être étendue à l'avenir en fournissant SOA sur l'ESB.

Maintenant, mes préoccupations/questions sont:

• Depuis fonte est un outil d'orchestration, lequel dois-je utiliser pour orchestrations? Est-ce de la fonte ou de l'ESB?
• Cast Iron ne peut communiquer qu'avec JMS/IBM MQ et ne peut pas communiquer avec Microsoft Messsage Queue. Donc, devrions-nous aller avec ESB basé sur Java comme Mule (avec Active MQ) ou Service Mix? Quelles sont mes options pour ESB basé sur .NET (autre que Microsoft Biztalk et NServiceBus), qui est fiable et le plus largement utilisé?
• Quelle est la meilleure pratique pour le transfert de données en masse? Habituellement, cela peut être fait via SSIS. Dans notre cas, il se peut que nous devions déplacer les données en masse vers le cloud de façon périodique.
• Quelle est la meilleure façon de publier des messages dans un magasin de messages JMS à partir d'applications .NET?

Je sais que j'ai posé beaucoup de questions ici et peut ou non avoir des réponses directes. Je serais heureux d'entendre les points de vue des gourous.

Answer 1

Je pense aussi que, en introduisant un ESB pour votre architecture conduirait à un système extensible et évolutif. Si vous êtes intéressé par les ESB basés sur Java, WSO2 ESB [1] (WSO2 ESB est basé sur la plate-forme WSO2 Carbon basée sur OSGI et sa source 100% gratuite et ouverte) est une bonne option. Cependant, WSO2 n'est pas seulement un ESB mais fournit une plate-forme SOA complète (également disponible en tant que PaaS dans le cloud)). En raison des avantages que vous obtenez lorsque vous utilisez un ESB, vous pouvez l'utiliser comme composant d'orchestration.

[1] http://wso2.com/products/

Answer 2

1) Cela dépend. La fonte est idéale pour les intégrations/orchestrations de prémisses on/off rapides. Les orchestrations concernant les services externes/SaaS seraient naturelles à orchestrer dans CI. Il n'y a pas de réponse claire, "ça dépend". 2-3) Étant donné que vous avez déjà des composants WebSphere, une bonne solution que j'ai essayé d'intégrer avec .NET et Messaging (IBM WebSphere MQ) est WebSphere Message Broker 8. Il intègre la prise en charge de l'exécution du code .NET intégré. Par exemple, vous pouvez lancer Visual Studio, puis importer une référence de service et l'appeler immédiatement, tout en conservant une ESB complète (compatible Java). L'édition express est un peu moins chère, mais un peu limitée. L'utilisation de WebSphere MQ sous-jacent vous offre un support client .NET et une très bonne intégration avec Cast Iron. Vous mentionnez également ServiceMix, qui est essentiellement un conteneur OSGi autour de ActiveMQ et Camel. C'est un puissant ESB open source. Mule ESB CE + ActiveMQ serait plutôt similaire, ce n'est pas vraiment un deal breaker parmi ceux que vous choisissez. ActiveMQ prend également en charge les clients .NET et est souvent sous-estimé en tant que courtier JMS d'entreprise.

4) Données en masse. D'après mon expérience, il s'agit d'un sujet très complexe auquel il n'y a pas de meilleure réponse dans tous les scénarios.

5) Il n'y a pas de solution générique pour la connectivité JMS -> .NET. Cela ne fonctionne pas, sans pontage des composants s'exécutant sur JVM. Cependant, la plupart des implémentations JMS proposent des API similaires, mais non standard, pour les clients .NET. À la fois WebSphere MQ (XMS) et ActiveMQ (NMS), cela vaut également pour la plupart des autres fournisseurs.