Un meilleur job mieux payé ?

Deviens chef de projet, développeur, ingénieur, informaticien

Mets à jour ton profil pro

ça m'intéresse

L'approche SOA passe-t-elle nécessairement par des approches distribuées
Et des communications distantes inter-applicatives ?

Le , par ego, Rédacteur
Contexte : monde de la gestion....

Une petite réflexion sur tout ces moyens d'appel à distance : RMI, IIOP, WebServices, EJB, Corba,....

As-t-on réellement besoin de tout ça ? Pourquoi parle t-on toujours de distribution/appel distant quand on parle de SOA ?

Plus j'y pense et plus je me dis que tout cela ne sert peut-être pas tant que ça.

Bon, ok il faut expliquer un peu...

L'idée est : "quand a t-on vraiment besoin de distribution ?"

1- Ben quand une IHM doit appeler un serveur "métier". Dans des cas simple ou on fait du Web et que tout est sur le même serveur, ce n'est même pas nécessaire. Mais, ok, pour des question de sécurité et donc d'architecture, partons du principe qu'une IHM doit toujours faire appel à des services "distants" pour dialoguer avec le "métier".

Dans ce cas, quelle est la nature des "services" appelés par l'IHM ?
Si on a des règles d'architecture correctes, c'est à dire que l'on a pas de métier côté IHM et que l'on se doit de minimiser les aller/retour entre IHM et métier (pour les perfs !), eh bien ces "services" sont forcément des services dédiés à l'IHM. Ce que je veux dire c'est que ces services ne sont pas fondamentalement "métier" ou tout au moins pas réutilisables dans un autre contexte que cette IHM. Alors ok, comme on fait de la bonne conception, ces "services" font s'appuyer, "derrière", sur des composants de plus bas niveau qui eux seront indépendant de l'IHM et seront plus "métier".
Ces "services IHM" sont-ils alors des services au sens "SOA" ? Est-ce que ce ne seraient pas plutôt les composants de "derrière" qui sont les services au sens SOA ? Mais si oui, alors ces composants n'ont pas besoin de distribution car ils sont sur le serveur.

2- Bon, ok, toujours avec cette idée que les services "SOA" sont les composants de "derrière". Ces composants peuvent avoir besoin d'appeler des services d'autres applications. Ah bon ? Lesquels réellement ? Dans un SI, les applications ont des responsabilités claires et il est rare que le métier "transactionnel" soit beaucoup réparti entre plusieurs applications. Au "pire", on a des référentiels communs ou des "mécanismes généraux" qui sont partagés. Pour ces référentiels ou mécanismes, on peut très bien se passer de distribution en déployant les "librairies" qui les constituent sur les différents serveur métier. On a alors des composants locaux qui doivent simplement être déployés correctement sur plusieurs serveurs.
En dehors de ces "applications particulières", la communication avec d'autres applications est souvent asynchrone. Soit via des évènements temps réel soit via des fichiers et là il n'y a pas besoin de distribution.

Bref, je me demande si on ne devrait pas limiter l'importance des technos de distribution dans nos approches d'architecte et plus réfléchir à la modularité de nos applications et à leur mode de déploiement dans les serveurs d'application en fonction des liens qu'elles peuvent avoir.
Et au final, plus se concentrer sur des problématiques comme celles qui tournent autour d'OSGI (modularité, versioning) et des "nouveaux serveurs d'applications" (où la distribution n'est pas le coeur du discours)

Des avis ?

nb : j'ai mentionner que ces réflexions étaient faites dans le contexte d'un SI "Gestion" mais je me demande si ce n'est pas vrai dans l'absolu.


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de ego ego - Rédacteur https://www.developpez.com
le 11/11/2009 à 20:31
super retour, je te remercie !

Maintenant, je reste très pragmatique. Qu'est ce que cela nous apporte en terme de productivité ?

Là, je te rejoins car j'ai l'impression que la gestion des versions, un peu partout (MANIFEST, scripts Ant/Ivy ou Maven, gestion du/des repositories,...) est pas simple à mettre en place.
Si tu as des "patterns" je suis intéressé.
Sinon, d'accord avec toi sur la conception qui doit A LA BASE être correcte et indépendante des technos. Pour moi, LA règle c'est vraiment de penser POJO et de n'utiliser les technos que pour les "protocoles d'accès". Les composants "techniques" ne devant faire que de la délégation vers les POJO

Concernant ton expérience, quels ont (sont) été les points forts et les points faibles autour d'OSGI ?
Avatar de Alesque Alesque - Membre du Club https://www.developpez.com
le 12/11/2009 à 0:00
Citation Envoyé par ego  Voir le message
Là, je te rejoins car j'ai l'impression que la gestion des versions, un peu partout (MANIFEST, scripts Ant/Ivy ou Maven, gestion du/des repositories,...) est pas simple à mettre en place.

Au niveau repository que ce soit pour Maven 2 ou les bundles OSGi :

Avatar de TheNOHDirector TheNOHDirector - Membre du Club https://www.developpez.com
le 13/11/2009 à 11:45
Je suis d'accord avec toi ego, SOA ne veut pas nécessairement dire distribué! Je travaille sur une application composée de services métier, techniquement les services sont dans des EJB-JAR et l'ensemble est packagé dans un EAR, cet ensemble est découpée en strate. Les services de haut niveau ou à valeur ajoutée sont composés de service de plus bas niveau. Je pense que cette application est typiquement une très bonne représentation d'une architecture orientée service.

Ici l'application n'est pas distribuée, car elle tourne sur une même JVM. Celà dit il y a bien du RMI pour que les EJB-JAR communiquent entre eux. Mais il s'agit plus là de câblage interne que le container fait pour nous.

Par rapport à ce que tu disais sur les responsabilités, notre application a plusieures responsabilités réparties entre les services qu'elle expose. Chaque service exposé se compose de services ayant un périmètre plus fin de responsabilité.

Il y a longtemps pour des raisons techniques mais aussi pour des raisons business, nous avons fait un découpage de notre application depuis une application encore plus grosse. Du coup nous avons aujourd'hui un découpage dans le SI, avec des appels distants.

N'oublions pas non plus que le SOA, ce n'est pas seulement des services au sens composant, mais aussi des clients, des batchs, des systèmes legacy qui doivent s'interconnecter. Par exemple notre application fait appel a des systèmes legacy et à un mainframe, des batchs sont lancés régulièrement, et des clients internes et externes se connectent à notre application.

Donc oui je pense que de faire une architecture distribuée - techniquement du code qui n'est pas sur la même JVM - a un sens. Ce sens doit bien entendu être soutenu par le business et par les besoins techniques.

En ce qui concerne la modularité et le versionning nous avons travaillé dessus, mais ce n'est clairement pas pas optimal. Techniquement OSGI et CXF pourrait bien ouvrir la voie sur ces deux sujets. En parlant de ça un livre vient de sortir sur le versionning des contrats de WebServices, évidement il faut avoir choisi une approche Contract First pour en profiter.

[ame="http://www.amazon.fr/Web-Service-Contract-Design-Versioning/dp/013613517X/ref=sr_1_1?ie=UTF8&s=english-books&qid=1258108838&sr=8-1"]Web Service Contract Design and Versioning for SOA[/ame]
Avatar de zortar zortar - Futur Membre du Club https://www.developpez.com
le 13/11/2009 à 13:00
Ce thread est très intéressant et pose de bonnes questions.

Avant de répondre sur certains points (je suis architecte dans l'équipe JOnAS),
est-ce qu'on peut partager un vocabulaire commun sur la SOA et l'architecture du système d'information ?

La SOA est un paradigme architectural.

Les gens utilisent le terme SOA pour désigner* différentes choses :
- SOBA (Service Oriented Business Architecture)
- SOA integration (par exemple utiliser un ESB pour intégrer des applications)
- SOA modernization (par exemple donner un accès Web Service à une application existante, ou mettre en place un serveur déchange qui permet de gérer des flux hétérogènes entre applications)

Seul le SOBA relève «*véritablement*» de la SOA.
Dans ce cas, il s'agit d'écrire de nouvelles applications avec une architecture SOA. A partir de l'analyse des processus de l'entreprise, sont déterminés successivement :
- les services fonctionnels correspondants aux activités
- les services applicatifs
- les services techniques

Pour développer l'architecture adaptée dans une organisation, un cadre architectural comme le TOGAF identifie bien* les niveaux suivants :
Business architecture (Process)
Information Systems ( data and application architecture)
Technology Architecture

OSGi (la SOA dans* une VM) apporte la modularité à Java
au même titre que la SOA apporte la modularité à l'Enterprise Architecture.

Celà étant dit, je suis d'accord avec ego, une chose importante c'est bien la capacité à réaliser les "services de derrières" sous forme d'applications (services ) composites.
Même si les problèmes de distributions font dépenser beaucoup d'énergie, il ne faut pas perdre de vue que ce n'est pas une finalité et que l'important c'est bien ces fameux services qui doivent bien tourner quelque part, et le serveur d'application de nouvelle génération est une place de choix.
Et c'est bien là tout l'enjeu de nos travaux, la modularité, le versioning, et la composition. Nous le faisons avec iPOJO mais notre obsession est bien de le faire de manière la plus* standard possible (dans une approche best of breed), le meilleur des deux mondes Java EE et OSGi (et pas l'inverse).
Nous regardons aussi avec attention la distribution OSGi qui va dans le sens d'une simplification de toute cette couche protocolaire "legacy".
OSGi permet de gérer correctement dynamisme (mise à jour à chaud, substitution, lazy loading) et l'aggrégation de briques open source. Dans JOnAS sont intégrés "facilement" CXF (pile Web service et routage), la médiation Camel, la gestion des règles avec Drools, et tout autre composant OSGi.

Je suis d'accord que tout ça ne concerne pas que le SI Gestion mais tout système (industriel, embarqué, etc).

Pour revenir à la distribution, la distribution vient de l'architecture. Quand on répond à certaines questions d'EA on arrive à de la distribution.
Si on prend les questions du Framework Zachmann
What ? How ? When ? Who ? bien souvent elles conduisent à une architecture distribuée mais effectivement SOA ne veut pas forcément dire distribution (OSGi en est le premier exemple). Ensuite comment est faite cette distribution et à quel niveau, c'est une autre question.
Il y a eu dans le passé une vision homogène de la distribution, et je pense que c'est cette vision là de la distribution qui n'est pas la bonne.

Il y a donc des besoins de distribution, cela va encore s'accentuer avec le cloud. JavaEE ou D-OSGi permettent de masquer cette distribution à l'application.
SCA offre aussi un modèle de programmation qui permet de masquer cette distribution.
Comment va évoluer SCA par rapport à Java EE et D-OSGi, pour l'instant on ne sait pas trop.

Pour revenir aux objectifs de la SOA, même si aujourd'hui, la tendance est plus à la flexibilité du système d'information plutôt qu'à la réutilisation des services, dans les deux cas le repository de bundle OSGi apporte une vraie valeur.
Avatar de ego ego - Rédacteur https://www.developpez.com
le 13/11/2009 à 20:48
@zortar
Merci pour ce retour précieux, sans vouloir offancer les autres, d'une personne qui travail au coeur d'un serveur d'appli comme Jonas.

Je me demande par contre pourquoi on a DOSGI d'un côté et JEE de l'autre. Une convergeance tout au moins côté Java me semblerait totalement nécessaire. Et c'est d'ailleurs ce que Jonas tente de faire pour le moment en permettant de publier un EJB comme service OSGI et aussi avec l'injection de services OSGI dans un EJB.

Erik_qui_croit_dur_à_OSGI
Avatar de acerodon acerodon - Nouveau Candidat au Club https://www.developpez.com
le 24/11/2009 à 12:44
Effectivement il s'agit avant tout d'une architecture Business qu'elle soit distribuée ou pas - la question d'architectures non-distribuées se pose cependant de moins en moins...

J'ai fait du Corba en 1998 et c'était un grand pas en avant pour faire communiquer des applications hétérogènes. C'était de la programmation 'ouverte' où l'on partait de 0 et on construisait l'application. Cependant ce n'était pas une architecture mais un bus.

10 ans plus tard, il ne s'agit plus de faire du code comme dans le temps mais plutôt de la tuyauterie entre des composants architecturaux prédéfinis - ceci est valable quand on utilise des solutions d'entreprise - selon des standards ou référentiels qui font partie de la IT Governance et Compliance. Oracle, SAP, Cognos, SAS implémentent tous (avec plus ou moins de facilités offertes) cette couche SOA.

J'ai assisté le 19 Novembre 09 au workshop Oracle Fusion Middleware pour la version 11gR1 et la couche SOA prend en input les SGBDR ou ERP hétérogènes et propose en output des services homogènes.

De plus, Oracle ont sorti au dessus de la couche Fusion Middleware (SOA) la couche AIA (Application Integration Architecture) qui propose des composants afin de structurer encore plus les services pour faciliter les liens avec le frontend.

SOA et AIA sont l'homogénéisation de l'EAI (Enterprise Application Integration) qui était/est classique mais propriétaire - l'implémentation même du bus était/est propriétaire.

Avant de se focaliser sur les aspects techniques, il faut considérer ce que l'on vise comme résultat à l'échelle nécessaire (celle de l'entreprise autant que possible) mais aussi dans le temps (scalabilité, etc.)
Avatar de ego ego - Rédacteur https://www.developpez.com
le 24/11/2009 à 19:02
Mais justement, je pense que l'utilisation de Java à grande échelle sur l'ensemble des applis d'un SI n'existe pas encore et on ne se rend pas compte que si quelques services distribués ça fonctionne bien à "petite" échelle, à grande échelle, je reste très dubitatif.
Pour la petite histoire, les EAI n'ont jamais vraiment percés et je ne vois pas pourquoi les ESB changeraient quelque chose d'autant plus que beaucoup d'ESB sont centrés au Java et les WebServices uniquement (plus transferts de fichiers). Et c'est un comble d'être à ce point "mono-techno/langage" quand on veut faire de l'intégration. Quid des applications existantes écrites dans d'autres langages ?

Bref, je pense que l'omniprésence de la notion de distribution quand on parle de "services" ne me parait pas adéquate par rapport à la problématique même de "services".
Le "vrai" problème pas encore totalement résolu c'est la notion de versioning de services et toute la gestion qui va autour. ça c'est un vrai vrai problème qui ne commance à être vraiment traité que depuis que l'on a OSGI
Avatar de B.AF B.AF - Membre chevronné https://www.developpez.com
le 16/12/2009 à 10:14
zortar léve un concept intéressant :

il faut décorréler le service rendu du moyen de rendre le service.

Globalement, la partie conception doit définir les services à rendre, la façon de les rendre étant une problématique purement technique.

En outre, je contredis la plateforme Java EE sur les aspects techniques. C'est trop confus, trop de choses, trop de plomberie.

La plateforme .Net, avec en plus WCF, les Web Services (très très simples à mettre en oeuvre), le messaging et bien plus simple à mettre en oeuvre.
Avatar de Hephaistos007 Hephaistos007 - Membre expert https://www.developpez.com
le 16/12/2009 à 16:52
Citation Envoyé par zortar  Voir le message
La SOA est un paradigme architectural.

C'est exact, mais malheureusement il n'est pas traité en tant que tel.

Soit on voit le service comme un paradigme (c'est mon cas), soit on voit le service comme un synonyme de composant (qui par définition, rend un service). Avec la seconde vision (la plus répondu, y compris dans ce fil de discussion), il est difficile de ne pas se dire qu'il s'agit d'un concept marketing pour redonner un coup de jeune à une autre paradigme, celui des composants. Ce qui est vrai, c'est que les problématiques liées à la communication d'un ensemble de composants distribués et hétérogènes ont fait d'énormes progrès. Malgrè tout, cela reste fondamentalement le paradigme composant, qui a toujours insisté sur l'aspect communication (sans avoir les solutions techniques à l'époque) pour pouvoir assembler (certains dirons intégrer) des briques logicielles en un tout cohérent. Par exemple, OSGi est un framework composant par excellence, pourvu de mécanismes d'assemblage de composants (les bundles), réalisé à chaud, de surcroit. Il n'y a pas l'ombre du paradigme SOA la dedans.

Pour changer de paradigme, il faut plus que des améliorations techniques (si bonnes soient-elles), il faut changer l'approche avec laquelle le développement est traditionnellement considéré. Justement, le paradigme des services prévoit la découverte dynamiques des composants, qui deviennent ainsi des "services" dans le jargon : ils sont là, quelque-part, disponibles, et attendent le "client". Tout comme j'organise ma journée autour d'un ensemble de services (bus, cantine, la poste, coiffeur), il doit être possible (cas idéal) de construire un SI par orchestration de services réalisés par d'autres. Cela requière de savoir ce que l'on veut (poster une lettre, se faire une nouvelle coupe de cheveux), reléguant sa réalisation concrète au second plan. C'est un peu la remarque de B.AF il me semble. C'est ainsi que le notion d'annuaire de services a naturellement fait son apparition. Sans annuaire, vous ne faites pas du SOA, vous faites un SI dont les composants applicatifs sont répartis. Point barre.
Avatar de B.AF B.AF - Membre chevronné https://www.developpez.com
le 16/12/2009 à 18:04
Oui je te confirme.

Ca ne sert à rien d'avoir la plateforme technique si l'on ne maitrise pas les services attendus. Ou alors ça fini dans des frameworks tellement technique qu'il n'apporte plus grand chose à cause d'une courbe d'apprentissage monstrueuse.
Avatar de 09765493 09765493 - Candidat au Club https://www.developpez.com
le 20/03/2013 à 14:09
poucez vous m'aider à Commentez la citation suivante " SOA n’a pas nécessairement besoin de web services. Tous les web services ne sont pas basés sur SOA"
Offres d'emploi IT
Ingénieur conception en électronique de puissance H/F
Safran - Ile de France - Moissy-Cramayel (77550)
Responsable transverse - engagement métiers H/F
Safran - Ile de France - Corbeil-Essonnes (91100)
Responsable protection des données H/F
Safran - Ile de France - Magny-les-Hameaux (78114)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique ALM