Dilemme SOA/ESB

Question

Désolé pour la question très complexe, mais c'est quelque chose que je recherche depuis un moment et c'est vraiment frustrant pour moi. Je me sens comme dans l'âge d'aujourd'hui, nous avons un million et une façons de mettre en œuvre des services qui sont multi-plateforme (SOAP) et facile à construire (grâce à .NET, java, et d'autres cadres). Cependant, ces technologies ont été dans la communauté pour les 5-10 ans, mais nous sommes (ou tout au moins je suis) constamment aux prises avec les mêmes problèmes:

1. Identification (services de suivi) - UDDI; Par exemple, il a fallu rappeler à un collègue les 3 fois ce mois où un service est présent, malgré le fait qu'il existe un wiki qui traite du service et une version PDF de la même documentation qui se trouve dans un référentiel où nous conservons nos documents de service. .
2. Évolutivité - Mise en grappe prête à l'emploi; En tant qu'organisations, nous dépensons beaucoup d'argent pour payer nos administrateurs juste pour regarder l'utilisation de nos services et prendre des décisions comme, est-ce que ce service a besoin de plus de RAM, plus de CPU, plus d'interfaces? Comment puis-je équilibrer la charge?
3. Surveillance - enregistrement des erreurs, etc; Je ne peux pas compter combien de fois je dois configurer le traçage sur les services afin de voir pourquoi un bogue se produit qui semble affecter seulement un client, ou doit coder la logique dans le service pour sérialiser des exceptions, enregistrer des exceptions à dbs, échoue gracieusement, etc.
4. Déploiement - facile à déployer; aucun de ce déploiement de DLL pour charger 5 serveurs équilibrés

Chacun de ces problèmes nécessite un certain type de solution personnalisée implémentée par l'organisation. Documentation et UDDI pour # 1. Matériel de virtualisation et d'équilibrage de charge/logiciel pour # 2. Traçage, écriture d'exceptions aux bases de données/journaux, etc. pour # 3. Logiciel de déploiement personnalisé pour # 4. Je travaille pour une organisation de taille moyenne. Je ne peux même pas imaginer comment une entreprise de la taille de Sun, Google ou Microsoft pourrait s'attaquer à ces dilemmes. Peut-être que ma vision est irréaliste, mais je rêve d'avoir un cadre en soi qui vit au sommet d'un cluster de serveurs qui gère tout ce qui précède. J'étais ravi de lire sur AppFabric de Microsoft, car il semble vraiment étendre certaines fonctionnalités de BizTalk aux implémenteurs de service WCF: Caching, Hosting, Monitoring, etc. Cependant, d'après ce que j'ai vu, je ne pense toujours pas qu'il vit jusqu'à mon rêve pour une solution tout-en-un qui aide le développeur et l'organisation à écrire des services qui sont facilement mis à l'échelle des clusters, déployées dans le cluster facilement et identifiables, éventuellement même versionnables. Donc, je ne veux pas dire que ce post concerne mon rêve. J'ai effectivement une question. Pour commencer, mon rêve/vouloir est-il complètement irréaliste? En outre, quelles sont les solutions disponibles qui tentent de résoudre ces problèmes sans nous confiner à une nouvelle manière plus exclusive (BizTalk) de développer des services? Enfin, en ce qui concerne une solution SOA/ESB complète, où voyons-nous le plus de potentiel sur le marché, maintenant ou dans le futur?

Answer 1

Je pense que vous parlez de différents types de problèmes ici.

1). Les développeurs qui ne lisent pas la documentation. Ceci est un problème endémique, non limité à SOA - il suffit de regarder quelques questions sur StackOverflow. Au moins, le développeur vous demande s'il existe un service, plutôt que de simplement dupliquer la logique dans son propre code. Je ne vois pas de solution technique à ce genre de problèmes, vous avez déjà fourni de bons registres et de la documentation, mais certains développeurs préfèrent parler aux gens. Peut-être, même, c'est en fait une bonne chose - l'interaction humaine a une valeur supérieure au contenu technique de l'interaction. Ou peut-être, vous êtes trop gentil: "Non, je ne vais pas répondre à cette question, le chercher."

2). Mise à l'échelle. Il existe des technologies pour résoudre ce problème. (Disclaimer Je travaille pour IBM, qui en vend, donc je vais les mentionner - je ne prétends pas qu'IBM soit le seul fournisseur avec des solutions dans cet espace.) Il existe des produits tels que this qui peuvent provisionner une nouvelle machine , installez une pile logicielle et ajoutez-la à un cluster pour gérer les modifications de la charge de travail. Ensuite, à un niveau de contrôle plus fin dans le monde Java EE, Application Server peut façonner dynamiquement le trafic et ajuster les clusters. Voir WebSphere Virtual Enterprise

3). Surveillance. Je ne "comprends" pas ce que vous attendez ici. Dans tous les cas, de tels bogues complexes nécessiteront une trace au niveau de l'application. Pour certains problèmes tels que la recherche de fuites de mémoire et les goulets d'étranglement de performances, il existe de très bons outils, du moins dans le monde Java EE.

4). Je ne peux pas parler du monde .Net, mais je dirais que les serveurs d'applications Java EE font un travail raisonnable de déploiement des applications sur les clusters, et dans les cas où nous utilisons JNI et que nous avons besoin de déployer des DLL, nous pouvons utiliser des produits comme la pile Tivoli que je mentionne pour gérer cela. Donc, en résumé, je pense que les fournisseurs essaient de résoudre ces problèmes. Et je ne pense pas que votre vie serait plus simple sans SOA. Imaginez plutôt les mêmes problèmes appliqués à une myriade d'applications indépendantes et indépendantes.

Answer 2

Voici mes deux cents.

J'ai été développeur dans une entreprise qui utilisait SOA de façon incorrecte. La pire solution qu'ils ont mise en œuvre était la validation au niveau du terrain des éléments de formulaire sur une application de bureau utilisant la SOA. Pour fonctionner de manière acceptable, ils nécessitent une latence très faible. Une attente de 2-4 secondes pour passer à un nouveau champ vieillit rapidement. Le service a couru sur le réseau sur un serveur biztalk. Tout le monde détestait ça. Si vous faites cela, vous devez passer beaucoup de temps à gérer les problèmes de latence du réseau, de panne de service, de synchronisation et d'expiration. Ne vous laissez pas emporter et pensez que SOA est la solution à tous les problèmes. Utilisé à un niveau élevé, il est génial, utilisé à un niveau bas, il rend vos applications fragiles, lentes et impossibles à déboguer.

Answer 3

Si vous parlez à IBM ou à l'un des grands fournisseurs SOA, ils ont un produit qui couvre chaque scénario.

Identification (Tracking services) - UDDI; e.g., had to remind a co-worker the 3 times this month where a service is at, despite the fact there is a wiki that discusses the service and a PDF version of the same documentation that lives in a repository where we keep our service docs. 

Serveur de registre et de référentiel. Ce qu'il y a de bien, c'est qu'il fait de la gouvernance (promotion, rétrogradation, gestion des versions, approbation) et votre ESB effectue généralement une «recherche» des plus récents et des plus importants par rapport au serveur de registre.

Scalability - Out of the box clustering; As organizations, we spend a lot of money on paying our admins just to watch the utilization of our services and make decisions like, does this service need more RAM, more CPU, more interfaces? How do I load balance this? 

Logiciel de surveillance des transactions comme IBM Tivoli Composite Application Manager pour SOA. Fondamentalement, il suit les choses d'un point de vue horizontal et de voir s'il y a une interruption de service d'un point de vue de l'utilisateur final/application finale.

En ce qui concerne votre clustering .... vous devez choisir le bon middleware et l'architecture. Personnellement parlant, préparez des produits "cloud" prêts. App Servers avec NoSQL connecté par MOM.

Monitoring - error logging, etc; I can't count how many times I have to set up tracing on services in order to see why a bug is happening that only seems to affect one customer, or have to code logic into the service to serialize exceptions, log exceptions to dbs, fail gracefully, etc. 

Normes d'entreprise pour vos développeurs et pour vos fournisseurs. Intégration de tous les événements métier et système dans un tableau de bord unique (La plupart des entreprises les ont déversées). C'est déjà fait dans la plupart des magasins d'entreprise.

Deployment - easy to deploy; none of this deploying DLLs to 5 load balanced servers 

Ahh .. Outil de déploiement Web Microsoft IIS 2.0. Vous pouvez synchroniser 100 serveurs MS en mettant à jour le maître. C'est vraiment facile.