Voici une question jolie théorique et abstraite: comment l'architecture axée sur le service (SOA) diffère de l'approche basée sur les composants? Est le concept de SOA une extension à une approche basée sur des composants?
Quelles sont vos pensées? Peut-être connaissez-vous de bons papiers qui couvrent ce sujet?
4 Réponses :
Les deux concepts sont assez orthogonaux, ni complétant ni ne contredisant mutuellement. Si vous avez menacé de coller une fourche rouillée dans mes yeux et que je me suis obligé à généraliser, je dirais que le développement basé sur des composants était une technique de modélisation et d'assemblage d'un logiciel spécifique, où la SOA est une technique permettant d'organiser des systèmes séparés. ils peuvent se parler.
Comme je l'ai dit, une généralisation crasse, mais tout ce que je vais vous donner sans une question plus précise :)
On pourrait dire que la SOA est une forme de développement basée sur des composants de haut niveau, où des composants ont été transformés en morceaux de fonctionnalité réutilisables appelés services.
dans Cet article le Les auteurs affichent le développement basé sur les composants comme Soa Soa - à la fin de vos besoins en SOA Services à mettre en œuvre et que vous concevez Je pense que cette perspective est une caractérisation raisonnable de la manière dont la SOA est réellement faite aujourd'hui. Pour moi, la clé est que vous concentrez d'abord sur les services, ce que vous devez faire dans un sens de l'entreprise, puis ensuite sur les conceptions de composants. [Voici un article sur l'identification des services. Disclaimer: Je suis une personne IBM, ces articles sont écrits par des collègues.]
Cependant, si vous remontez l'horloge, je pense que vous constaterez que le développement fondé sur les composants était une approche qui prédate la SOA et avait de nombreux objectifs que SOA. J'imagine aussi indûment cynique l'opinion que Soa est juste un battage médiatique marketing, collant de nouvelles étiquettes sur les anciens concepts. Cependant, il y a un chevauchement considérable entre la CBD et la SOA. Je viens de voir Soa comme étant la meilleure sagesse collective que nous devons voir comment faire l'intégration, sans aucun doute que nous apprenons plus de nouvelles techniques émergeront jusqu'à ce que le kitbag global mérite à nouveau un nouveau nom.
Mon point d'affichage personnel est que la SOA a eu de l'élan, car un ensemble de technologies a émergé qui permettait aux équipes techniques disparates au sein d'une organisation (par exemple, une base IBM et Microsoft Base) pour créer des composants pouvant utiliser les services de chacun. En d'autres termes, un niveau de maturité de la manière de faire apparaître des composants, de sorte qu'une nouvelle étiquette (SOA) était attrayante.
Développement basé sur le composant nécessitait un référentiel de fragments de code (parfois des piles d'objets complets) généralement dans une syntaxe de code. Pour être utile sur autre chose, ces fragments devraient être portés ou appelés sur une interface commune (disent que Windows API ou COM, COM + et al) entre VB6 & VC ++, par exemple. Ainsi, les fonctions VC ++ pourraient être utilisées et appelées par VB6. Ainsi, la réutilisation des composants nécessitait parfois beaucoup de refactorisation pour être réutilisée qui était contre-intuitive. Il y avait aussi le problème de la liaison précoce et tardive. Les composants du référentiel doivent encore être construits et déployés comme une partie de fonctionnement de la base de code afin d'être utilisées. Le code aurait dû être testé de l'unité avant d'ajouter au référentiel, mais il est toujours nécessaire de tester l'intégration pour confirmer la fonctionnalité. Vous devrez également construire les paramètres corrects afin de «traverser l'interface d'objet». Encore une fois, ce code d'enveloppe généralement nécessaire.
Ces référentiels de code pourraient ne pas inclure tout pour être vraiment multiplate-forme. L'indépendance de la plate-forme est généralement requise lorsque des problèmes sont segmentés entre les domaines, en particulier dans les systèmes intégrés. L'interface est incluse dans le logiciel construit et déployé, et non le code de fonctionnement réel.
Ce que vous manquez entre les deux est un cadre. SOA n'est pas CBDV2 ni une extension, vous devez suivre le cadre de la mise en œuvre du service. Les cadres ne sont pas un nouveau concept non plus.
Les deux CBD et SOA favorisent finalement la réutilisation du code. La CBD est généralement plus étroite que SOA! La SOA a besoin d'un cadre pour être efficace, CBD ne le fait pas. La CBD est couplée à sa langue de développement et à sa plate-forme cible.