Certains de nos partenaires nous disent que notre logiciel a besoin d'interagir avec un Bus de Service d'Entreprise. Après avoir cherché un peu, mon instinct est-à-dire que c'est juste du buzz parler pour dire que nous avons besoin d'une plate-forme indpendent façon de transmettre les messages d'avant en arrière. J'essaie juste d'avoir une idée de ce que font nos partenaires de nous le dire. Ai-je raison en rejetant nos partenaires demande juste essayer d'obtenir notre logiciel afin d'être plus mot à la mode-conformes, ou sont-ils de nous dire quelque chose que nous devrions écouter (même si encodés dans buzzspeak)?
Réponses
Trop de publicités?Bien que l'ESB est basée sur la messagerie, il n'est pas "juste" de la messagerie et pas seulement un mot à la mode.
Donc si vous commencez avec un bon vieux asynchrone de messagerie, les premiers réseaux ont tendance à être très point-à-point. Vous a de fil de haut (à savoir le configurer par le biais de certains de l'interface d'administration) chaque connexion, et chaque paire de destinations et si vous avez osé déplacer quoi que ce soit autour invariablement quelque chose s'est cassé. Parce que les points de connexion ont été câblés à la main, ces réseaux n'a jamais atteint une connexion haute densité. Le différentiel du coût était trop élevé et n'a pas à l'échelle. Il y avait aussi beaucoup de contrôle de l'accès et de la politique incorporé dans la topologie. Le manque de connexion densité favorise en fait cette approche de la sécurité, même si elle inhibe la flexibilité.
L'ESB tente de répondre à ces questions avec...
- Au moment de l'exécution de la résolution de destinations/services/ressources
- Transparence de l'emplacement
- Tout-à-tout de la connectivité et de connexion maximale de la densité
- Conçu pour la redondance, évolutivité horizontale, le basculement
- Politique de contrôle d'accès, règles de externalisés de topologie
- Logique de messagerie de la couche réseau mises en œuvre au sommet de la physique de messagerie de la couche réseau
- Commune de l'espace de noms
Ainsi, lorsque votre client demande de l'ESB de compatibilité, ils veulent des choses comme ci-dessus. À partir d'une application point de vue, ce qui implique aussi...
- En évitant message affinités telles que les exigences à traiter dans un ordre strict ou pour répondre à des demandes seulement aux nœuds spécifiques au lieu d'un générique de réseau de destination
- Capacité à résoudre les destinations de manière dynamique au moment de l'exécution (c'est à dire ajouter un autre exemple d'une file d'attente et il commence automatiquement à obtenir du trafic, d'en supprimer un et voies de circulation pour les nœuds restants)
- Demandeur et fournisseur d'applications découplée de savoir où les uns des autres "vies". Demandeur fait une connexion, indépendamment de la façon dont de nombreux services dont elle a besoin pour appeler
- Autoriser par la politique plutôt que par la topologie
- Service de fournisseur d'applications de mesure de reconnaître et de gérer des dupes (comme par JMS spec, voir "fonctionnelle double" en raison de session de manutention)
- Capacité à exécuter plusieurs instances actives d'un fournisseur de service d'application
- Instrument les demandes des fournisseurs de services de sorte que vous pouvez vous renseigner sur l'état du réseau ou d'effectuer un test sans l'envoi d'une transaction
D'autre part, si votre client ne peut pas articuler ces choses, alors il se pourrait qu'ils veulent être en mesure de cocher une case qui dit "travaille avec l'ESB."
Je vais essayer de garder ce mot à la mode gratuit (mais un buzz acronyme peut se glisser dans).
Lorsque les services/applications/mainframes/etc... souhaitez intégrer (donc envoyer des messages les uns aux autres), vous pouvez vous retrouver avec tout un gâchis. Un ESB se cache, ce désordre à l'intérieur de lui-même (ou itselves) afin que l'organisation puisse prétendre qu'il n'y a pas de gâchis et qu'il a quelque chose de gérable. Il enroule alors un tas de fonctionnalités autour de cela pour faire de cette zone encore plus alléchante pour les personnes âgées au sein d'une organisation qui va prendre la décision d'acheter un produit cher. Ces gens en général veulent introduire une grande initiative qui coûte beaucoup d'argent pour prouver qu'ils sont "faire quelque chose" et de savoir comment dépenser de grosses sommes d'argent. Si c'est un SOA de l'initiative de fournisseurs différents auront leur a dit qu'un ESB est nécessaire pour apporter les vendeurs vision de ce que SOA est un travail (en général, une fois le nombre de services dont ils pourraient vouloir passe trivial nombre).
Donc un ESB est:
- Un véhicule pour les vendeurs de faire beaucoup d'argent;
- Un véhicule pour les consultants à faire beaucoup d'argent;
- Une façon pour les cadres supérieurs (Directeurs des systèmes d' & autres) pour montrer qu'ils peuvent dépenser beaucoup d'argent;
- Une boîte pour cacher un désordre;
- Un total de PITA pour une équipe technique pour travailler avec.
Après avoir cherché un peu, mon l'instinct est-à-dire que c'est juste buzz parler pour dire que nous devons avoir une plate-forme indpendent moyen de passer messages d'avant en arrière
Vous avez raison, en partie parce que le terme ESB est toujours le mot gentil qui s'adapte bien avec un autre mot à la mode, légitime ou non - ce qui est la gouvernance (c'est à dire vous aide à gérer qui est de l'accès à vos systèmes d'extrémité et les rapports métriques Métriques - btw est ce que tous les costumes, comme de voir, de sorte que peut être un contributeur)
Une autre raison, ils pourraient vouloir une plate-forme neutre de l'appareil est ainsi que tous les services qu'ils consomment sont toujours exposés que les ordinateurs d'extrémité à partir d'un emplacement central, à la place d'une machine spécifique de ressources. L'ESB fait de la physique des points de terminaison de vos services non pertinents, qu'ils ne se préoccupent pas beaucoup de toute façon, mais qui permet de vous déplacer services autour, cependant ils ne consomment que de l'ESB point de Terminaison.
En dehors d'un référentiel centralisé pour la Découverte, un ESB rend également à côté de la gestion des versions des services de plus facile. Si j'avais le choix et que mon entreprise avait le budget, nous avons acheté IBM x150 de l'appareil :(
Troisièmement, beaucoup plus avancés, les bus, comme SoftwareAG du produit si je me souviens bien, est nativement en mesure d'exposer des données existantes, comme à partir des données assis sur les principaux cadres que des services sans avoir besoin de codage via des adaptateurs
Je ne sais pas si leur but est de tirer parti de tous les avantages d'un ESB fournit, ou, comme vous l'a dit, mot à la mode compatible.
Après avoir cherché un peu, mon instinct est-à-dire que c'est juste du buzz parler pour dire que nous avons besoin d'une plate-forme indpendent façon de transmettre les messages d'avant en arrière
C'est sur la droite. Parfois, une GDE vais aller un peu plus loin et inclure des fonctionnalités supplémentaires comme message garanties de livraison, confirmation/d'accusé de réception des messages, et ainsi de suite. La présence de l'ESB aussi, généralement, explicitement ou implicitement crée un nouveau protocole où n'en existait pas auparavant, ce qui est une autre considération importante. (C'est une sorte de standard ou de l'interface doit être faite en ce qui concerne le format des messages.)
Ai-je raison en rejetant nos partenaires demande juste essayer d'obtenir notre logiciel afin d'être plus mot à la mode-conformes, ou sont-ils de nous dire quelque chose que nous devrions écouter (même si encodés dans buzzspeak)?
Vous devez toujours être à l'écoute de vos clients, même si au départ, il est ridicule. Il est généralement en vaut au moins des dépenses de l'effort de décider de ce qui se passe. Lire entre les lignes, ce que vos partenaires sans doute dire, c'est qu'ils veulent à votre service afin de s'intégrer plus facilement avec leurs propres produits et services.
Un bus de service d'entreprise gère la messagerie entre les systèmes de manière standard. Cela vous permet de communiquer avec le bus de la même manière sur toutes vos plates-formes et le bus gère la traduction réelle vers le mécanisme de communication individuel nécessaire pour le point de terminaison spécifique. Cela signifie que vous écrivez tout votre code pour qu'il communique avec le bus à l'aide d'un schéma de messagerie commun. Le bus se charge de prendre votre schéma commun et de le traduire afin que le terminal le comprenne.