Synthèse des concepts

Projet BPMS – Synthèse des concepts
DRAFT VERSION Nicolas Portmann 2007
Synthèse des concepts
1. SOA.....................................................................................................................................2
1.1. INTRODUCTION ...............................................................................................................2
1.2. ORACLE SOA SUITE.......................................................................................................3
1.2.1. Architecture................................................................................................................4
1.2.1.1. Integrated Service Environment.......................................................................................5
1.2.1.2. Oracle BPEL Process Manager (including Human Workflow).........................................5
1.2.1.3. Oracle Enterprise Service Bus (ESB)...............................................................................5
1.2.1.4. Oracle Business Rules.....................................................................................................5
1.2.1.5. OracleAS Integration Business Activity Monitoring..........................................................6
1.2.1.6. Oracle Web Services Manager ........................................................................................6
1.2.1.7. OracleAS UDDI Registry..................................................................................................6
1.2.1.8. Oracle Application Server.................................................................................................6
1.3. DÉFINITION DES SOURCES DE DONNÉES ET POOLS DE CONNEXION DANS LE SERVEUR OAS6
2. SERVICES WEB.................................................................................................................6
2.1. INTRODUCTION ...............................................................................................................6
2.2. CRÉATION DE SERVICES WEB DANS JDEVELOPER............................................................7
2.2.1. Comment les types java primitif sont sérialisé vers XML...........................................7
2.2.2. Outils JDeveloper pour développer des Web services..............................................7
2.2.3. Développement BOTTOM-UP...................................................................................8
2.2.3.1. Comment créer des services bottom-up..........................................................................8
2.2.3.2. [Pratique] : Création d’un service Web à partir d’une classe Java...................................8
2.2.3.3. [Pratique] : Création d’un service Web à partir d’une classe Java et en utilisant des
annotations JSR-181..........................................................................................................................9
2.2.3.4. [Pratique] : Création d’un service Web à partir d’un package PL/SQL............................9
2.2.4. Développement TOP-DOWN.....................................................................................9
2.2.4.1. Comment créer des services top-down............................................................................9
2.2.4.2. [Pratique] : Création de services Web selon l’approche top-down ..................................9
2.2.5. Créer un service Web à partir d’un EJB 3.0 ............................................................10
2.2.6. Déployer un service Web depuis JDeveloper..........................................................10
2.3. UTILISATION DE SERVICES WEB DANS JDEVELOPER.......................................................10
2.4. DEBUGGER, TESTER ET ANALYSER DES SERVICES WEB DANS JDEVELOPER ...................11
3. ORACLE ENTREPRISE SERVICE BUS..........................................................................11
3.1. INTRODUCTION .............................................................................................................11
4. PROCESSUS BPEL .........................................................................................................11
4.1. BPEL, LA PIERRE ANGULAIRE DE SOA...........................................................................11
4.2. ORACLE BPEL PROCESS MANAGER..............................................................................13
4.3. UTILISATION DE ORACLE BPEL PROCESS MANAGER .....................................................14
4.4. PRATIQUE.....................................................................................................................14
4.5. ORACLE BUSINESS RULES ............................................................................................15
5. SOURCES.........................................................................................................................16
5.1. OUVRAGES...................................................................................................................16
5.2. INTERNET .....................................................................................................................16
5.3. SITES DE RÉFÉRENCES .................................................................................................17

Projet BPMS – Synthèse des concepts
Auteur : Page 2 sur 17 15.11.2007
Nicolas Portmann
1. SOA
1.1. Introduction
[JDN-01] Mieux développer, et surtout mieux maintenir les fonctionnalités conçues : voici deux
objectifs de l'architecture orientée services
Cette nouvelle couche d'abstraction fait suite à d'autres abstractions créé au fur et à mesure
des besoins et des avancées technologiques : la création des fonctions et procédures, la
programmation orientée Objet, les logiciels à base de composants
L'architecture orientée services ambitionne d'aider les développeurs à gérer l'hétérogénéité des
"milieux applicatifs" : l'objectif est d'autoriser les applications ou service à communiquer et de
travail ensemble, quel que soit leur plate-forme respective.
La SOA promet donc l'interopérabilité des applications par le biais de services. Un service qui
n'est rien d'autre qu'un composant dont les interfaces et contrats d'utilisation sont connus, et qui
est indépendant de tout système. Pour ce faire, XML est utilisé dans lors des échange
d'informations, enrobé le plus souvent d'une enveloppe SOAP
Plus généralement, une architecture SOA peut être construire sans utiliser XML ni les services
Web, mais avec des formats de type CVS, ou des technologies comme Corba ou COM/DCOM,
mais XML offre certainement une plus grande ouverture.
L'architecture en elle-même se représente en faisant intervenir trois acteurs : le
consommateur, le service, et le répertoire de services. Le consommateur correspond à
l'application cliente (ou à un autre service), qui fait appel au service pour une tâche précise. Ce
consommateur trouvera les informations à propos du client au sein du répertoire de services,
où sont enregistrés et triés un grand nombre de ceux-ci. Un répertoire peut être privé, c'est-à-
dire interne à l'entreprise, ou public.
Le service répond à trois fonctionnalités caractéristiques : il est indépendant, il peut être
découvert et appelé de manière dynamique, et il fonctionne seul.
Le répertoire de services a un rôle primordial dans la SOA. C'est lui qui reçoit la requête du
consommateur, lui qui découvrira le service idoine, et lui qui agira en tant que proxy
(intermédiaire) entre consommateur et service. En s'assurant que les fournisseurs de services
informent régulièrement les répertoires de leurs nouveautés, le consommateur peut
constamment profiter de celles-ci sans pour autant devoir mettre à jour ses méthodes.
Ainsi, une banque pourra mettre à jour son service de calcul d'intérêt, et si celui-ci est
enregistré correctement sur un répertoire (public ou privé), l'utilisateur pourra sans rien changer
profiter des évolutions.
Le tout enfin, enfin, repose fondamentalement sur les services Web. La SOA utilise tous les
standards dédiés aux services Web (XML, HTTP, WSDL, UDDI, SOAP...) pour s'assurer de
l'interopérabilité de son fonctionnement. Ce n'est pas pour autant qu'ils sont synonymes : une
SOA n'est pas en soi une technologie, mais un principe de conception, tandis que les services
Web en sont une implémentation technologique.
Deux schémas pour clore cette introduction :

Projet BPMS – Synthèse des concepts
Auteur : Page 3 sur 17 15.11.2007
Nicolas Portmann
Le schéma ci-dessous montre une évolution historique de sites Web statiques à des
applications connectées SOA :
Le schéma ci-dessous montre la gestion de l’hétérogénéité des applications d’une entreprise
via la programmation d’adapters maison ou l’utilisation d’EAI (en français Intégration
d'applications d'entreprise ou IAE) (before) ou alors, via l’architecture SOA (Services Web
orchestré par BPEL).
1.2. Oracle SOA Suite
(http://www.oracle.com/lang/fr/technologies/soa/index.html)
L'architecture orientée services (SOA) est conçue pour simplifier le développement de services
de gestion modulaires (les services web) faciles à intégrer et à réutiliser, créant ainsi une
infrastructure informatique véritablement flexible et adaptable.
Avantages SOA :
 Réduction des coûts de développement
Les services SOA sont aisément réutilisables et peuvent être rapidement assemblés,
tels des composants, sous la forme de nouvelles applications composites sans
nécessiter aucune programmation manuelle coûteuse
 Allégement des coûts de maintenance
Les services réutilisables diminuent le nombre et la complexité interne des services
informatiques, réduisant ainsi la charge de travail de maintenance requise pour
l'intégralité de la gamme de services.

Projet BPMS – Synthèse des concepts
Auteur : Page 4 sur 17 15.11.2007
Nicolas Portmann
 Optimisation de la qualité des services
La technologie SOA favorise considérablement la réutilisation accrue des services,
laquelle se traduit par une amélioration de la fiabilité et de la qualité des services par le
biais de multiples cycles de test effectués par différents utilisateurs.
 Diminution des coûts d'intégration
Les services normalisés fonctionnent parfaitement les uns avec les autres, garantissant
ainsi la connexion rapide et aisée d'applications disparates.
 Minimisation des risques
Des services moins nombreux et réutilisables contribuent à améliorer le contrôle des
stratégies de gouvernance d'entreprise et des tâches informatiques et à diminuer les
risques globaux de non-conformité des opérations.
1.2.1. Architecture
Oracle SOA Suite est un set complet de composants permettant de créer, déployer et gérer des
services.
Voici ses composants :
 Un « ISE » permettant de développer nos services
 « Oracle BPEL Process Manager », le premier moteur natif BPEL (Business Process
Execution Language) conçu pour l'orchestration des services Web et permettant aux
entreprises de concevoir, définir et exécuter leurs processus métiers.
 « Oracle Enterprise Service Bus (ESB) », un produit basé sur les standards assurant la
connexion des systèmes informatiques existants et des partenaires de l'entreprise pour
constituer un ensemble de services.
 « Oracle Business Rules » pour définir et administrer les règles de gestion.
 « OracleAS Integration Business Activity Monitoring » pour une visibilité en temps réel
sur l'exécution des processus et la performance des activités métiers.
 « Oracle Web Services Manager » permettant de sécuriser nos services
(authentification, autorisations, encryptage).
 « UDDI registry », registre de service Web
 « Oracle Application Server 10g Release 3 (10.1.3) » fournissant un environnement
complet pour nos applications J2EE.

Projet BPMS – Synthèse des concepts
Auteur : Page 5 sur 17 15.11.2007
Nicolas Portmann
1.2.1.1.Integrated Service Environment
Oracle JDeveloper est l’environnement de développement de la Suite SOA d’Oracle. Il permet
de développer, composer et orchestrer les services dans des processus métiers. Les processus
métiers peuvent être déployés, enregistrés et « consommés » par plusieurs types d’interface
utilisateur (clients lourds, browsers, mobiles, telnet).
JDeveloper permet au développeur de modéliser, créer, découvrir, assembler, orchestrer,
tester, déployer et maintenir des applications hétérogènes basées sur des services.
JDevelopper supporte les principes de l’architecture orientés services (SOA), les standards
XML services Web, les applications Java (J2EE) et les mécanismes de modularité et de
composants PL/SQL.
ADF est un framework de développement d’application.
Oracle TopLink est un outil de persistance objet/relationnel édité par Oracle, référence de
l'implémentation de JPA (Java Persistence API). Il permet de stocker des objets Java et des
EJB (Entreprise Java Been) dans des bases de données relationnelles mais aussi, en
implémentant l’API Java JAXB (Java Architecture for XML Binding) de convertir des objets java
en document XML.
Les frameworks TopLink et ADF simplifie la création de services qui peuvent être invoqué
depuis des interfaces Web d’applications orientées services.
1.2.1.2.Oracle BPEL Process Manager (including Human Workflow)
Oracle BPEL Process Manager fournit un framework permettant de modéliser et exécuter nos
processus métier basés sur les standards BPEL.
1.2.1.3.Oracle Enterprise Service Bus (ESB)
ESB permet à des applications hétérogènes d'interagir au travers de services standards
qu'elles mettent à disposition. L'ESB en tant que médiateur entre les clients et les fournisseurs
de services s’appuie sur des standards ouverts afin de se connecter, transformer et router des
documents métiers. Il permet de surveiller et de gérer les données métiers avec un minimum
d’impacte sur les applications existantes.
1.2.1.4.Oracle Business Rules
Oracle Business Rules permet de définir et administrer les règles métiers. Les règles sont
séparées du code de l’application, ainsi, l’analyste métier peut créer et modifier les règles