Middleware et SOA par exemple
Je suis un développeur Java expérimenté qui tente de comprendre certains concepts et technologies fondamentaux de middleware/SOA, notamment:
- Architecture orientée services (SOA)
- Middleware orienté message (MOM)
- Message Queue
- Apache Camel
- Mule
- EJB
- Points de terminaison et itinéraires
- Service Bus/ESB
- JMS
Après avoir examiné chacune d’elles en ligne/sur Wikipedia, j’ai pu obtenir (pour la plupart) des définitions décentes pour chacune d’elles. Ce que je ne comprends pas, c’est comment toutes ces technologies/concepts fonctionnent ensemble sur l’arrière-plan pour fournir une solution de niveau 2/métier.
Quelqu'un peut-il donner s'il vous plaît un exemple d'architecture qui utiliserait toutes ces technologies/concepts et expliquer quel rôle chacun d'entre eux joue dans la solution globale? Une fois que je vois un exemple qui fonctionne, je suis sûr que cela va m'aider à relier la plupart des points.
Edit : Depuis que j'ai ajouté la prime, j'ai eu plusieurs réponses qui suggèrent de lire des livres. Bien que j'apprécie tous les commentaires ici, je ne peux tout simplement pas me séparer de 300 points de réputation pour une réponse qui se résume, pour l’essentiel, à "RTM" (en particulier lorsque je suis à plat et que je ne peux pas me permettre le manuel !) Pour répéter, la récompense et la réponse définitive iront à quelqu'un qui peut frapper toutes ces balles dans un exemple significatif et pratique. Cela ne doit pas nécessairement être un compendium de middleware !!! Juste un paragraphe ou deux qui montre comment tous ces éléments peuvent être utilisés ensemble pour créer une solution de niveau métier Java. Merci encore.
Modèles d'intégration d'entreprise peuvent vous aider à comprendre comment tout s'emboîte.
[mise à jour:] Votre question suivante sur une autre réponse m'a fait comprendre que vous êtes confus au sujet de produits spécifiques. Cela s'explique en partie par le fait que les logiciels tendent, dans la pratique, à s’appliquer à plus d’un concept et en partie parce que différentes entreprises affirment qu’elles fournissent «tout», alors qu’elles ne le font pas.
Les ESB sont des boîtes à outils/bibliothèques qui vous permettent de tout connecter ensemble. Ce ne sont ni les services eux-mêmes, ni les implémentations de messagerie, mais les goo qui comblent les petites lacunes entre les deux. Si vous écrivez tout à partir de zéro, vous n’en aurez peut-être même pas besoin, car ce qu’ils font de mieux, c’est de réparer l’écart entre tout un tas de technologies différentes. Si vous partez de zéro, vous pouvez éviter ce désastre.
Les services sont bien les services. Vous pouvez utiliser certains EJB lorsque vous en implémentez un (je ne le mentionne que parce que, pour une raison quelconque, vous les incluez dans votre question).
Le middleware de messagerie est un logiciel qui permet de transmettre les messages de A à B. C'est extrêmement utile, mais aussi complexe, et chacun, ainsi que son frère, a inventé le leur. Vous avez donc besoin d'une abstraction qui vous permette d'éviter le blocage. Cela peut être un ESB ou, si vous êtes entièrement Java, ce peut être JMS. Mais même lorsque vous utilisez Java entièrement JMS, vous pouvez toujours utiliser un ESB car ce sont des bibliothèques de tous les éléments de code Java que vous devez encore écrire (éléments aléatoires de la logique de routage, reformatage des messages, etc.).
J'espère que cela pourra aider. Ma réponse initiale porte davantage sur les modèles abstraits que vous construisez avec ces outils: lorsque vous assemblez des objets, les mêmes problèmes se posent encore et encore.
Noeuds finaux et routes: d'où proviennent les informations et qui vont à . Message Queue est un type de noeud final. L'autre type est un sujet de message.
Un noeud final est un "nom logique pour une chose", par exemple. PRICE.MSFT, utilisé par un éditeur ou une application grand public pour obtenir des éléments ou pour envoyer des éléments. Les sujets fournissent des informations à tous les abonnés (un à un ou un à plusieurs), les files d'attente délivrent des messages au premier destinataire (généralement un à un). Oubliez les files d'attente, vous pouvez également tout faire avec les sujets et les sujets présentent plusieurs avantages.
Middleware Orienté Message (MOM): infrastructure logicielle qui fournit des informations entre les sujets ou queus. Il est "orienté message" et non "orienté paquet" comme TCP. Ainsi, chaque blob d’information est livré dans un message auto-descriptif, espérons-le. L'implémentation de votre MOM vous donne alors une API où vous pouvez faire des choses comme msg.get ("enchère")
JMS et AMQP sont des exemples de spécifications MOM. Les implémentations MOM sont les produits réels qui implémentent ces spécifications: TIBCO EMS, Websphere MQ, MSMQ, Solace et bien d’autres
Apache Camel - approche très intéressante sur la façon de configurer les flux de travail dans ce monde MOM. Mais un concept plus avancé.
L'architecture SOA (Service-Oriented Architecture), Service Bus/ESB ne sont que de nouveaux mots à la mode pour ce qui s'appelait auparavant EAI (Enterprise Application Integration). Ce sont des recommandations sur la façon d'utiliser "MOM" et un moyen de payer des consultants très onéreux . Ce que ESB ajoute à une MOM, c'est l'idée de considérer vos éditeurs comme des "services" fournissant un service. En d'autres termes: ne pensez pas trop à ce qu'un consommateur veut en ce moment. Il pourrait y avoir 5 consommateurs dans le futur et cet éditeur devrait fournir un service et non «créer les informations souhaitées par le consommateur A». (Cela deviendra plus clair une fois que votre architecture aura plus de 5 applications). De plus, vous devriez avoir un modèle d'objet commun, peut-être en XML, pour simplifier les choses entre les applications.
Mule - une forme d'ESB, mais ce n'est pas exactement le flux principal. Dans 5 ans, la plupart des actions de middleware pourraient avoir été transférées entièrement vers AMQP ou autre chose.
EJB: idée de Sun selon laquelle des classes Java sophistiquées s'exécutent dans un conteneur. Censé faciliter le développement d'applications. Mais dans de nombreux cas, cela a rendu les choses plus complexes. Une meilleure alternative serait 'Spring' - mais les EJB concernent autre chose (pas seulement MOM). Son plus sur la façon de développer de plus grandes applications (voir le modèle IoC).
Si vous cherchez par où commencer: je recommanderais de vous familiariser avec JMS (tous les autres MOM sont similaires et JMS est la base des EJB/Mule, ...) et, sauf si vous avez des exigences de performances très élevées, considérez les messages comme un TextMessage contenant XML. La plupart des outils sont disponibles dans cette zone. Ou même plus simple mais moins sophistiqué, un MapMessage avec des paires clé/valeur.
En prenant toutes vos exigences et en les transformant en une requête, je suis tombé sur une étude de cas excellent qui devrait répondre à vos besoins:
Je suis allé de l'avant et le texte intégral a recherché le livre en utilisant la fonction "Rechercher dans ce livre" d'Amazon. Il couvre tous les cas d'intégration dont vous avez parlé, semble être complet et vous guide tout au long du processus de conception et de mise en œuvre.
Je suis gêné de dire que je n’ai pas lu ceci moi-même, mais je recommande fortement d’utiliser les mêmes outils que moi pour voir si cela répond à vos besoins avant d’investir dans une copie. Cela semble plus complet, plus complet et plus utile que de vous exposer à une documentation incomplète ou de résumer le contenu en une réponse.
Vous mélangez de nombreux concepts et technologies avec différents niveaux d'abstraction. Mais tous vos concepts ont quelque chose à voir avec l'intégration d'applications (d'entreprise). Je vais essayer de commenter vos définitions:
- Architecture orientée services (SOA)
SOA fournit un ensemble de principes et de méthodologies pour intégrer les applications existantes en tant qu’appareils faiblement couplés. A partir des modèles d'intégration d'entreprise (voir ci-dessous): "SOA estompe la ligne de démarcation entre l'intégration et les applications distribuées". - Service Bus/ESB
L’ESB est un concept principal de SOA pour réduire les dépendances au sein des applications d’une SOA. Au lieu de nombreuses dépendances entre les applications, chaque application est connectée au ESB. - Middleware orienté message (MOM)
MOM est une infrastructure d’envoi et de réception de messages entre systèmes distribués. Ceci est utilisé pour intégrer des applications. MOM était le marteau d'or avant que le battage médiatique de SOA ne se manifeste. Comme ces deux solutions sont utiles, les grandes suites d'intégration fournissent à la fois ESB et MOM (ou utilisent MOM dans leur ESB). - Message Queue
Une file de messages n’est qu’un aspect de détail technique dans l’architecture MOM. Lorsque l'envoi/la réception de message est découplé, les messages sont stockés dans des files d'attente jusqu'à ce que le destinataire soit prêt. - Apache Camel
Lorsque le livre Modèles d'intégration d'entreprise: conception, création et déploiement de solutions de messagerie est arrivé sur le marché, certaines solutions logicielles ont été créées. Apache Camel est l'un d'entre eux. Camel fait également partie d'Apache ServiceMix, également un ESB open source. FuseSource et Talend associent Apache ServiceMix, Apache Camel et Apache Active MQ (MOM) à des offres groupées avec support technique. - Mule
Mule est également une plate-forme d’intégration et d’ESB open source. - EJB
De Wikipedia: Enterprise JavaBeans (EJB) est une architecture de composant côté serveur gérée pour la construction modulaire d'applications d'entreprise. Cela signifie que EJB est un composant dans une application et n'a rien à voir avec l'intégration d'applications. - Points de terminaison et itinéraires
Lorsque vous travaillez avec Apache Camel, vous concevez des itinéraires entre des points de terminaison, consultez un didacticiel . En bref, les messages entrent/sortent de votre système via des noeuds finaux et sont traités dans un flux défini par une route. - JMS
JMS ou Java Message Service est un MOM (Message Oriented Middleware) avec une API Java normalisée.
Enterprise Application Integration (EAI) est essentiel pour connecter des applications métier à des systèmes hétérogènes. Au fil des ans, les architectes de solutions d'intégration ont inventé leur propre mélange de motifs de différentes manières. Mais la plupart de ces architectures présentent des similitudes, initiant un ensemble de normes largement acceptées dans l’architecture des modèles d’intégration. La plupart de ces normes sont décrites dans le catalogue de modèles d'intégration d'entreprise disponible à l'adresse: http://www.eaipatterns.com/toc.html .
WSO2 ESB
Documentation WSO2 Enterprise Service Bus (ESB) 4.7.0! WSO2 ESB est un ESB rapide, léger, 100% open source et convivial, distribué sous la licence logicielle Apache v2.0. WSO2 ESB permet aux administrateurs système et aux développeurs de configurer facilement le routage, la médiation, la transformation, la journalisation, la planification des tâches, le basculement, l’équilibrage de la charge, etc. Il prend en charge les modèles EIP (Enterprise Integration Pattern) les plus couramment utilisés et permet la commutation de transport, les événements, la médiation basée sur des règles et la médiation basée sur les priorités pour les besoins d'intégration avancés. Le moteur d'exécution ESB est conçu pour être complètement asynchrone, non bloquant et diffuser en continu sur la base du moteur de médiation Apache Synapse.