|
Architecture globale orientée "service"
|
Vos besoins
- Créer une vision "service" pour l'analyse des
architectures fonctionnelles et des processus indépendamment
de la technologie "services"
- Définir une architecture orientées "services" de haut
niveau, découplée des solutions technologiques
- Partager cette vision
Vos problèmes
Les solutions disponibles actuellement ne vous permettent pas
cela, elles sont in timément liées à des solutions
technologiques "Web services". |
Solution
Amarco vous permet de réaliser des architecture globales orientées
services. Il ne s'git pas d'un système pour générer des éléments compatibles WSDL, IDL, SOAP etc. Ceux ci représentent une vision technologique des services,
telle que disponible actuellement et en pleine évolution.
Amarco vous
donne une vue plus globale des services, valable aussi pour d'autres technologies.
Cette vision peut être particularisé dans la technologie actuelle.
Dans ce cas vous disposez d'une architecture fonctionnelle et applicative
orientée service, ce qui vous donnera plus de recul par rapport aux évolutions
technologies.
Du point de vus modélisation, notre représentation (conçue dès 1995)
est similaire avec les orientations actuelles.
Les principes d'analyse promus permettent de définir clairement
les limites de votre systèmes, le type et le sens des services échangés.
Vous pouvez ainsi réaliser l'architecture fonctionnelle et applicative
des vos applications, et donc mettre les bases d'une réalisation technique
conformément à vos vrais besoins.
Vous pouvez ainsi définir des composants orientées services, ce qui vous
permettra de réutiliser des acquis.
 
C'est la direction de la société qui lance et finance un projet
de services Web. Pour le faire, il faut qu'elle comprenne
l'enjeu des nouvelles architectures et leur avantage sans être noyée
avec les détail des protocoles, des formats XML etc. Il faut aussi
être capable de représenter l'architecture générale d'une application
répartie mettant en oeuvre les services Web. Il faut montrer le
déroulement des principaux processus, comment ces services Web seront
utilisés.
Nos outils supportent en natif les services Web. La notion de
point de service, déclinée "demandeur" ou "serveur" correspond
exactement à la situation réelle : une application demande
des services, une autre les exécute et répond avec le résultat.
Exemple d'une application répartie, montrant plusieurs
modules interconnectés, certains appartenant à l'entreprise, certains
à l'extérieur. Un processus est superposé sur cette organisation
:
Ce schéma indique :
Les systèmes extérieurs qui demandent ou réalisent
des services (en jaune)
-
Les modules internes (en bleu) connectés également
à travers des services Web internes
-
Les points blancs sont associés avec les modules
qui demandent les services Web (les stubs !)
-
Les points rouges sont associés aux modules
qui mettent en oeuvre les services Web
-
Les flèches représentent les services Web échangés
pour mettre en oeuvre un scénario
Chaque trait entre un demandeur et un serveur représente
une connexion qui traverse l'Internet ou l'Intranet.
|
|
|
 |
|
